mcpify

mcpify

English | Türkçe

あらゆる OpenAPI REST API を MCP サーバーに変換します — Claude Code、Cursor、その他すべての MCP クライアントが API を直接呼び出せるようになります。コマンドは 1 つ、実行時の依存関係はゼロです。

mcpify serve https://your-company.com/openapi.json

# try it right now, nothing installed (uvx pulls from PyPI on demand)
uvx --from mcpify-openapi mcpify list examples/petstore.json --cost

特化型で、本番環境に対応し、CLI を最優先に設計しています。役割は 1 つ（OpenAPI → MCP）です。それ以外のガバナンス、認証情報、トークンエコノミクス、運用などはオプトイン方式で、必要になるまで邪魔になりません。

• エージェント向けにデフォルトで安全 — 遅延コンテキスト予算（--lazy）、シークレットのマスキング（--redact）、影響範囲の制限（--read-only、トークンごとの RBAC）
• 実際のデプロイに対応 — stdio + HTTP/SSE、OAuth2、読み取り／書き込み認証情報の分離、ヘルスプローブ、監査証跡、メトリクス、複数 API の提供、ホットリロード
• 約束ではなく、実証済み — 28 個のスイートにわたる 520 件のテスト、悪意のある仕様を集めたコーパス、ライブ CI チェック、実行時の依存関係ゼロ

気に入っていただける理由

仕様からサーバーへ

• 60 秒で動作可能 — あらゆる OpenAPI 3.x 仕様（ファイルまたは URL）を指定するだけです
• すべてのオペレーションが一級の MCP ツールになります — 入力スキーマは parameters と requestBody から生成され、内部の $ref は解決されます
• 仕様バージョンの差分をツールの視点から表示 — mcpify diff old.yaml new.yaml は、追加／削除／変更されたオペレーションと、変更ごとの破壊的変更の判定、および移行ガイドを報告します。--fail-on-breaking は CI のゲートとして使えます
• mcpify doctor — リリース前に、仕様がエージェントに適しているかを確認できます。operationId の不足、summary の不足、指示のようなツールテキスト、長すぎる説明を検出します。--probe は API に 1 回接続します。認証をエンドツーエンドで確認したい場合は実際の認証情報（--auth-env）を使用でき、厳格な CI ゲートには --fail-on-http-error を指定できます
• mcpify try / mcpify mock / mcpify output-server — エージェントクライアントなしでツールを呼び出したり、CI 向けにスキーマに沿った偽の API を提供したり、共有可能なスクリプトにサーバー起動コマンドを組み込んだりできます

認証情報とポリシー

• 認証情報が仕様書やモデルに渡ることはありません — 呼び出し時に環境から取得します。仕様書独自のセキュリティ宣言に基づいてフラグ（bearer、basic、header、query）が選択されます
• OAuth2 クライアント認証情報フローを組み込み — トークンの取得、キャッシュ、更新に加え、処理中に 401 が返された場合の再取得にも対応します（RFC 6749、標準ライブラリのみ）。--write-oauth2-* を使うと、GET 以外の呼び出しに2つ目のクライアント IDを指定できるため、読み取りと書き込みを別のクライアントとして認証できます
• デフォルトで最小権限 — --write-auth-env で静的認証情報を分割し（読み取りには読み取り用キー、書き込みには専用キーを使用）、--read-only で公開範囲を絞り、--deny/--allow で変更を伴う GET を非表示にします。トークンごとの RBAC により、各 bearer トークンに独自の許可／拒否スコープを設定できます
• --redact password,token — キー名にシークレットを含む値は、すべてのレスポンスのあらゆる階層で *** に置き換えられます（エラーボディーを含み、大文字と小文字を区別しません）。モデルに値が渡ることはありません
• 内容を漏らさない監査証跡 — 呼び出しごとに JSON を1行記録します。ツール、API、ステータス、レイテンシー、引数のフィンガープリント（生の引数は記録しません）が含まれます。--plugin で認証／リクエスト／結果のフックに使う Python モジュールを読み込みます

トークンコスト

• 提供前にコストを確認 — mcpify list --cost で公開範囲の料金を算出します（約4文字／トークン）。すべてのエージェントが tools/list を呼び出すたびにかかる料金を確認できます。複数の API を設定している場合は、1回の実行で API ごとの料金と合計料金を表示します
• --fields id,event — すべての階層で選択するレスポンス投影機能です。選択したキーは値を保持し、選択されていないコンテナーは透過的に残り、空になったコンテナーは削除されます。実際の weather.gov では、以前は約189件で切り詰められていた予算内に、全350件のアラートを収められます
• 有効な形式での切り詰め — 大きすぎるレスポンスは JSON 構造に沿って切り詰められ、明示的な "truncated": true マーカーが付加されます。ドキュメントの途中で切れることはありません
• --lazy による検索後の呼び出し — api.weather.gov の一覧を95.5%削減します。検索結果に各スキーマ全体を取得するコストが表示されるため、エージェントは必要なものだけを取得できます
• [tool-text] による上書き — doctor がモデル向けの、指示のような説明文にフラグを立てます。設定ファイルでツールごとに置き換えられます

運用

• 2つのトランスポート、1つのツール公開範囲 — ローカルエージェントには stdio を使用します。serve --http 8080 は MCP Streamable HTTP に対応し（SSE を要求するクライアントには SSE、それ以外には JSON で応答）、チーム全体で1つのサーバーを共有できます。bearer トークンも任意で設定できます
• 複数の API、1つの MCP サーバー — .mcpify.toml の [apis.NAME] セクションで、API ごとの認証、キャッシュ、再試行、フィルター、レート制限を設定できます。名前の衝突を防ぐ名前変更にも対応し、ヘルス情報を集約します。mcpify status はすべての API を並列で確認します
• 上流サーバーへの配慮を組み込み — ETag 対応キャッシュ、冪等な操作に限定した再試行（502/503/504）、Retry-After を尊重する --wait-on-429、リクエスト数／秒を制限する --rate-limit RPS に対応します（複数 API の場合は上流ごとに適用し、再試行も含みます）
• オプトインのオブザーバビリティ — Prometheus の --metrics（呼び出し回数、レイテンシー、キャッシュ、ヘルス情報。投影／マスキングの実行時にはそのカウンターも含みます）、--otel によるスパン、--reload によるホットスワップ、ローカルダッシュボードの mcpify ui を利用できます
• 無料でセルフホスト — HTTPS を自動設定する Caddy を含む docker-compose と、セキュリティ強化済みの systemd ユニットを利用できます：セルフホスティングガイド
• 実行時依存関係なし — コードツリー全体を監査できる標準ライブラリのみの Python で構成しています。YAML 形式の仕様書には、オプションの pip install 'mcpify[yaml]' が必要です

クイックスタート

# install (installs the `mcpify` command)
pipx install mcpify-openapi

# run without installing (uvx — pulls from PyPI on demand)
uvx --from mcpify-openapi mcpify list ./openapi.json --read-only

# first time? the wizard writes a config for you
uvx --from mcpify-openapi mcpify init

# ...as a container (GHCR, published on every release)
docker run -i ghcr.io/furkan708/mcpify:latest serve ./openapi.json --read-only

# ...or from source
git clone https://github.com/furkan708/mcpify.git
cd mcpify && pip install .

# 1. preview the tools that will be generated (add --cost for the context price)
mcpify list examples/petstore.json

# 2. validate the spec is agent-friendly (+ --probe for a live pre-flight)
mcpify doctor examples/petstore.json

# 3. serve it over MCP
mcpify serve examples/petstore.json --base-url https://petstore.example.com/v1

# 4. no agent client at hand? try the tools in your terminal
mcpify try examples/petstore.json --base-url https://petstore.example.com/v1

# 5. or share it over HTTP with the whole team
mcpify serve examples/petstore.json --http 8080 --http-token $SHARED_TOKEN

認証を使用する場合

# Bearer token read from the environment (never hardcoded)
export PETSTORE_KEY="sk-..."
mcpify serve petstore.json \
  --base-url https://petstore.example.com/v1 \
  --auth-env PETSTORE_KEY \
  --auth-style bearer \            # optional: auto-detected from the spec
  --read-only

一般的なケースでは、スタイルを明示する必要はありません。仕様書のセキュリティ宣言に基づき、適切な名前で bearer／basic／header／query が自動的に選択されます。HTTP Basic の場合、環境変数には username:password を指定します。 --auth-style basic --auth-env CREDS。

フラグ	意味
--auth-env VAR	認証情報を保持する環境変数
--auth-style bearer|basic|header|query	認証情報の送信方法（デフォルト：仕様書から自動検出）
--auth-name NAME	bearer 以外のスタイルで使用するヘッダー名／クエリ名（例：X-API-Key）

OAuth2（クライアントクレデンシャル）を使用する場合

OAuth2 ID プロバイダーの背後にある API の場合（RFC 6749 §4.4）。クレデンシャルは環境変数に保存されます。アクセストークンは取得され、expires_in で指定された期限までキャッシュされます。トークンは透過的に更新され、API が処理中に 401 を返した場合は一度だけ自動的に再取得されます。

export OAUTH2_CLIENT_ID="..."
export OAUTH2_CLIENT_SECRET="..."
mcpify serve api.json \
  --oauth2-token-url https://idp.example.com/oauth2/token \
  --oauth2-client-id-env OAUTH2_CLIENT_ID \
  --oauth2-client-secret-env OAUTH2_CLIENT_SECRET \
  --oauth2-scope "read write"        # optional; --oauth2-client-auth body for token endpoints that reject Basic

書き込み用の ID も分けられます： --write-oauth2-token-url（およびクライアント／スコープのフラグ）を使用すると、GET 以外の呼び出し用に、別のクライアントクレデンシャルフローが実行されます。読み取りは読み取りクライアントで認証され、書き込みは書き込みクライアントで認証されます。それぞれが独自のトークンキャッシュを持ち、同じ 401 自動修復機能を備えています。--write-auth-env とは併用できません（書き込みにはどちらか一方のクレデンシャル種別を選択してください）。

1 つのサーバーで複数の API を扱う

複数の OpenAPI ドキュメントを 1 つの設定にまとめ、ゲートウェイも API ごとのプロセスも使わずに、単一のツールサーフェスとして提供できます。

# .mcpify.toml
[apis.catalog]
spec = "https://shop.example.com/openapi.json"
auth-env = "CATALOG_TOKEN"          # per-API credential
cache-ttl = 60
rate-limit = 5                      # per-API courtesy throttle (req/s)
redact = "password,client_secret"   # per-API response masking

[apis.crm]
spec = "./crm.yaml"
read-only = true                    # per-API policy
base-url = "https://crm.internal/v2"
fields = "id,name"                  # per-API response projection

[apis.weather]
spec = "https://api.weather.gov/openapi.json"
timeout = 10

サーフェスの切り替え（--lazy、--enable-preview、--http、--format）はサーバー全体に適用されるフラグです。クレデンシャル、ポリシー、キャッシュ、再試行は API ごとに設定します。

mcpify list --cost      # preview every API and price each surface
mcpify serve            # stdio, all three APIs, prefixed on collisions
mcpify serve --http 8080
mcpify try              # REPL across every API
mcpify status           # probes each API concurrently

mcpify status は API ごとの状態（[catalog] reachable (status 200, 0.03s) — https://shop.example.com — 31 tools）を報告し、到達不能な API が 1 つでもある場合はゼロ以外で終了します。2 つの API が同じツール名（list_pets）を公開している場合は、どちらにもラベルを付けて名前を変更します（catalog_list_pets、crm_list_pets）。そのため、気付かないうちに一方が優先されることはありません。名前が重複しないツールはそのままです。mcpify_health ツールは、すべての API を対象とする 1 つのレポートを返します。キーの優先順位は、CLI フラグ > [apis.NAME] > [serve] です。位置引数の仕様ファイルか [apis.*] セクションのどちらか一方を指定してください。両方は指定できません。

エージェントに接続する

Claude Code：

claude mcp add my-api -- mcpify serve openapi.json --read-only

Claude Desktop／Cursor／その他の MCP クライアント（claude_desktop_config.json）：

{
  "mcpServers": {
    "petstore": {
      "command": "mcpify",
      "args": ["serve", "~/specs/petstore.json", "--auth-env", "PETSTORE_KEY"]
    }
  }
}

HTTP トランスポート（チーム共有サーバー） — mcpify serve api.json --http 0.0.0.0:8080 --http-token $TOKEN を一度実行し、HTTP 対応クライアントから接続します。

{
  "mcpServers": {
    "petstore": {
      "type": "http",
      "url": "http://your-host:8080",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

エージェントに「ペットの一覧を表示してから、Milo という名前のペットを作成して」と尋ねてみましょう。エージェントは list_pets と create_pet を検出し、引数を設定して、実際の HTTP 呼び出しを行います。

操作がツールになる仕組み

OpenAPI	mcpify
operationId	ツール名（サニタイズされます。なければ method_path にフォールバックします）
summary / description	エージェントが参照するツールの説明
deprecated: true	古いエンドポイントを公開する前に mcpify list で表示されます
parameters（path/query/header）	enum を含む、個別に型指定された引数
requestBody（JSON）	body オブジェクトの引数
$ref ポインター	インラインで解決されます（components → 実際のスキーマ）
servers[0].url	デフォルトのベース URL（上書きする場合：--base-url）

エージェントに表示されるのはツール一覧と API の JSON レスポンスだけです。mcpify はミドルウェアを追加せず、要求されていないものをキャッシュせず、クレデンシャルを API 以外に送信しません。

Doctor

$ mcpify doctor my-api.json
openapi: 3.0.3
title:   Acme API
paths:   23
tools:   41 operations
servers: https://api.acme.com
warning: 12/41 operations have no operationId (names fall back to method_path)
warning: 30/41 operations have no summary (agents see no description)

実際の事前チェックを行うには --probe を追加します。静的レポートの後に、引数のない GET（またはベース URL）へ接続して到達可能性を報告します。接続に失敗するとゼロ以外で終了するため、CI やシェルスクリプトで、サーバーを起動する前に処理を停止できます。

$ mcpify doctor https://api.weather.gov/openapi.json --probe
...
probe:    GET /alerts → 200 reachable (2.80s)

CLI リファレンス

mcpify list <spec> [--tag T] [--include P] [--exclude P] [--read-only] [--json]
mcpify list --cost                        # price the surface (~4 chars/token)
mcpify list --cost --lazy                 # ...and the 3-meta-tool lazy surface
mcpify list --config .mcpify.toml --cost  # multi-API: every surface priced
mcpify serve <spec> [--base-url URL] [--server INDEX|NAME] [--name N] [--auth-env VAR]
                    [--auth-style bearer|header|query] [--auth-name NAME]
                    [--oauth2-token-url URL --oauth2-client-id-env VAR
                     --oauth2-client-secret-env VAR] [--timeout S]
                    [--read-only] [--tag T] [--include P] [--exclude P]
                    [--http [HOST:]PORT] [--http-token TOKEN] [--wait-on-429 SEC]
mcpify try <spec> [same serve flags]        # interactive REPL, no agent needed
mcpify output-server <spec> -o FILE [-- <any serve flags>]
mcpify ui <spec> [same serve flags]         # local dashboard (tool explorer, health, config)
mcpify mock <spec> [--http 8000] [--delay-ms N]
mcpify diff OLD NEW [--json] [--fail-on-breaking]        # upgrade report + CI gate
mcpify diff OLD NEW --probe [--auth-env V]               # ...+ live check of the NEW API + cost delta
mcpify config-schema                        # JSON Schema for .mcpify.toml (editor wiring)
mcpify doctor <spec> [--probe --auth-env V --fail-on-http-error]   # static audit + live pre-flight / CI gate

# token economics: --fields id,name (projection), --redact password,token (masking),
#   --rate-limit RPS (upstream courtesy, retries included)
# credential split: --write-auth-env WRITE_KEY_ENV or --write-oauth2-token-url (reads keep --auth-env)
# tool-text overrides: [tool-text.TOOL] description = "..." in .mcpify.toml

# multi-API: define [apis.NAME] sections in .mcpify.toml, then run
#   mcpify list|serve|try|status|ui (no positional spec) — one process, every API
# ops add-ons for serve/ui: --metrics [HOST:]PORT   --reload   --cache-warm
#   --audit-log FILE   --http-token-file FILE   --plugin FILE (repeatable)   --otel [ENDPOINT]

注意事項と制限

• JSON 仕様はそのまま使用できます。YAML 仕様には pip install 'mcpify[yaml]' が必要です
• 外部の $ref の参照先（ファイルまたは URL）は、読み込み時に自動的に同梱されます。ファイル間で循環する参照は展開せず、そのまま残します（解決できないものは surface がスキップします）
• サイズ超過の JSON レスポンスは、有効な JSON のまま切り詰められます（先頭の項目と切り詰めを示すマーカーが残ります）。JSON 以外の本文は文字境界で切り詰められます
• --fields は、文書化されたルールに従って各階層で項目を選択します（選択されたキーはそのまま保持され、選択されていないコンテナーは透過的に扱われます）。これは射影であり、セキュリティ境界ではありません。フィールドをモデルに絶対に渡してはならない場合は、--redact を使用してください
• リクエスト本文は、単一の body オブジェクト引数として公開されます。巧妙さより予測しやすさを重視しています
• HTTP トランスポートは、リクエストごとに 1 つの JSON-RPC レスポンスを返します（バッチ処理は MCP 仕様から削除されました）。Accept: text/event-stream を送信するクライアントには、単一の SSE message イベントとしてフレーム化して返します。サーバー起点のストリーム（セッションを伴う GET ストリーム）は、ステートレスサーバーの対象外として意図的に扱いません
• 仕様のバージョン：OpenAPI 3.x と Swagger 2.x のルートを受け付けます。最も適しているのは 3.x です

実環境に備えた堅牢性

mcpify は、独自の例だけでなく、MCP のベストプラクティスと公開されている本番環境での障害事例に関する 10 カテゴリーのチェックリストに基づいて、リリースごとに監査されています。

• 敵対的な仕様のコーパス（12/12）： 循環する $ref、マルチパートアップロード、allOf スキーマ、サーバー URL 変数、相対ベース URL、サイズ超過のレスポンスなど、文書化された実環境での障害から導き出したすべてのシナリオを修正し、回帰テストで再発を防止しています。情報源には、実際の API 18 件を対象とした REST→MCP 生成に関する arXiv の研究が含まれます
• ライブ統合： 実際の api.weather.gov 仕様を CI で読み込みます。さらに、ライブチェックによって、実際にユーザーが遭遇する前に、最後に残っていた 2 件のバグ（ネストされた切り詰めによるエンベロープの分割と、最上位のみの射影）が見つかりました
• MCP ライフサイクルを強制： クライアントが initialize ハンドシェイクを完了するまで、ツールにはアクセスできません
• 上流の障害が発生してもセッションを維持： 上流の応答が遅い場合（読み取りタイムアウト）、レスポンスの途中で接続が切れた場合、あるいは 1 つのツール内で予期しない例外が発生した場合でも、修復方法を含むクリーンな isError ツール結果に変換されます。stdio 接続が切断されることはありません（他の OpenAPI-to-MCP サーバーで報告された障害モードをここで再現し、回帰テストで再発を防止しています）
• 影響範囲の制御： 読み取り専用モード、拒否／許可ポリシーレイヤー、トークン単位の RBAC、レスポンスの射影と秘密情報のマスキング、レート制限、有効な JSON を保つ 40k 文字の切り詰め、--timeout、認証情報のログへの記録なし

項目ごとの状況を含むチェックリスト全文：docs/AUDIT-CHECKLIST.md

テスト

520 件のテストに合格しています。さらに、実際の api.weather.gov ドキュメントを読み込むライブ統合テスト 1 件（オフライン時は自動的にスキップ）と、オプションのトレーシング用 extra がインストールされている環境で実行される OTel の正常系テストがあります。すべてのテストスイートは Linux と Windows で Python 3.10～3.12 を対象に実行されます。ruff、厳格な mypy、CodeQL がすべての push をチェックします。

スイート	テスト数	検証内容
仕様の解析と解決	13	OpenAPI 3.x と YAML の読み込み、$ref チェーン、allOf のマージ、サーバー変数、不正な入力
ツールへの変換	19	衝突時のサフィックス付与を含む operationId の命名、入力スキーマ、列挙型、本文の処理、アノテーションと出力スキーマの導出
エージェントのインターフェース	32	HTTP から導出されるアノテーション、構造化出力の契約、修正方法を示すエラー、--lazy 検索、ドライランのプレビュー
CLI	15	list ／ doctor ／ serve のフラグ、--json 出力、非推奨バッジ
悪意ある入力コーパス	11	循環する $ref、マルチパート本文、相対ベース URL、300 KB での切り詰め、500 オペレーション時のパフォーマンス — それぞれ、実際に発生した障害として文書化された事例を追跡
ライフサイクルと衛生管理	8	初期化ハンドシェイク（-32002）、バイト単位で純粋な stdio、認証情報がログに記録されないこと
プロトコルのエンドツーエンドテスト	9	稼働中のローカル HTTP API に対する、stdio 経由の実際の JSON-RPC とワイヤーレベルのアサーション
ポリシーレイヤー	7	--read-only、--allow ／ --deny の優先順位、変更を伴う GET の保護
$ref パラメーター	4	仕様全体を基準とするパラメータースキーマの解決 — weather.gov のバグの種類（1 件のテストでは実際のドキュメントにアクセス）
運用と設定	47	設定ファイルと環境変数の優先順位、初期化ウィザード、キャッシュの TTL と上限、再試行の安全性、XML 変換、検出、バッチ処理、ステータス／ヘルス
プロトコルバージョンの互換性	5	同じワイヤー上での、2026-07-28 のステートレスな _meta リクエストと、従来の 2025-06-18 ハンドシェイク
HTTP トランスポート	19	ストリーム可能な HTTP：POST 経由のライフサイクル、405／411／413／415 のエラー段階、解析／バッチ処理の拒否、ベアラー認証の強制、バインド文字列パーサー
OAuth2 クライアントクレデンシャル	18	フェイククロックによるトークン取得／キャッシュ／更新、Basic と本文によるクライアント認証、パブリッククライアント、あらゆる失敗モード、401 のエンドツーエンドでの自己修復
try REPL	26	stdin パイプ入力のセッション：番号／名前による選択、型指定プロンプト、不正入力時の再プロンプト、:raw ／ :info、EOF／Ctrl+C での正常終了、読み取り専用のインターフェース
output-server	11	埋め込み仕様の整合性、ガードレール（既存ファイル、不正な仕様、不明なフラグ）、シークレットに関する警告、実際のサブプロセスによる E2E ハンドシェイク
サーバーの選択	17	`--server INDEX
認証の自動検出と Basic	22	securitySchemes からのスタイル／名前の解決（OpenAPI + Swagger 2.0）、要件の順序による優先順位、オペレーションレベルのセキュリティ、ヒントの正確な文言、HTTP Basic ヘッダーのエンコード、CLI／try／doctor との連携、明示的なスタイル指定による上書き
レート制限への配慮（--wait-on-429）	9	上限内で一度だけ Retry-After を尊重、上限超過時は 429 を変更せず返す、ヘッダーがない場合は再試行遅延にフォールバック、HTTP-date 形式では待機しない、POST は自動待機しない、CLI との連携
複数 API の集約	26	[apis.*] のマージ時に両側の衝突プレフィックスと _2 サフィックスを適用、API ごとのルーティング／認証／キャッシュの分離、集約されたヘルスの同時確認（ヒント内で停止中の API 名を表示）、ラベル照合を含む API 横断の遅延検索、プレビューのルーティング、ステータスの終了コード、--env の継承、両方が拒否するフラグの組み合わせ
運用：ダッシュボード、メトリクス、モック、再読み込み	25	/metrics のテキスト形式（カウンター／ヒストグラム／キャッシュのヒット・ミス／ヘルスゲージ）、トークン保護された UI ルート、マスクされたプレビュー API、設定フォームの書き込み（+ 不明なキーは 400）、テンプレートルーティングを備えたスキーマ準拠のモック応答、破損した仕様からの復旧を含むホットリロードの再構築
CLI の接続処理	10	--http の連携、MCPIFY_HTTP_TOKEN へのフォールバック、OAuth2 フラグのルール、設定ファイルのキー、ウィザードのオプション 5、try のスモークテスト
仕様の差分（mcpify diff）	14	追加／削除／変更されたオペレーション、破壊的変更の判定（必須パラメーターの追加／必須化、本文の必須化、オペレーションの削除）、非推奨化と operationId の警告、移行ガイド、ドキュメントレベルの差分、CLI の終了契約 0／1／2、--json
v1.11 サービング：監査、キャッシュ、RBAC、プラグイン	17	引数フィンガープリントを含む JSONL 監査証跡と、書き込み不可ファイルでのフェイルセーフ、古いエントリーに対する ETag 304 再検証、mcpify_cache_invalidate（スコープ指定 + 全体）、--cache-warm は引数なしの GET のみ事前呼び出し、エンドツーエンドのトークンファイルによるスコープ制御（401 ／ フィルタリングされたリスト ／ 拒否された呼び出し、deny が優先、重複トークンの拒否）、実際のリクエストでのプラグインフック、mcpify ui のディスパッチ（存在しないコマンドの回帰）、config-schema と設定モジュールの一致、OTel ガード
外部 $ref のバンドル	6	ファイルおよび URL ベースの参照先をインライン化、コンポーネントのみの参照先ファイル、各ファイルを基準にしたネストされた参照の解決、参照先がない場合はスキップ、循環参照が維持されること、同一ドキュメント内の参照は変更しないこと
ガバナンス：キーの分割、ツールのテキスト、有効な切り詰め	21	稼働中の上流サービスで、メソッドごとの読み取りキー／書き込みキーを使用（共有 ID のデフォルトは変更なし）、スタイル／名前の継承と明示的な上書き、serve／envs／apis の設定 write-auth-* キー、list --json を介した [tool-text] の上書き、不明なツールの警告、バリデーターエラー、スキーマ／キーの整合性、doctor による指示文風の記述と過剰に長い説明の件数、巨大な配列をマーカー付きの有効な JSON に変換、オブジェクトのキー保持、非 JSON のフォールバック、エラープレフィックスの保持
v1.13：コスト、射影、SSE、OAuth2 書き込み	20	JSON と人間向け出力でのサーフェス料金表示、透過的なエンベロープを使った再帰的な射影（両ルールを検証：最上位のみを対象とする最初のルールは実環境で失敗）、選択したキーの配列を保持、JSON クライアントと SSE フレーミングの使い分け、--write-auth-env との相互排他を含む書き込みフローの解決
v1.16：ステータスポリシー、REPL セッション制御、差分プローブ + コスト差分	12	マルチ API の JSON／人間向けステータスと単一仕様の policy: 行におけるポリシー（fields／redact／rate-limit）、稼働中の上流サービスに対する :redact ／ :fields のセッション設定／表示／解除（ワイヤー上でマスキングを検証）、JSON／人間向け出力での差分サーフェスコスト、到達可能／到達不能時の --probe の終了契約（プローブ失敗時は 2）、フォームの再試行遅延の浮動小数点数
v1.15：auth-probe、strict ゲート、メトリクス、遅延料金	16	実際の認証情報を使ったプローブ（稼働中のローカル上流サービスに対する、認証情報なしでは 401、認証情報ありでは 200）、strict モードの判定、doctor CLI の終了契約、射影／リダクションの Prometheus カウンター（値のカウント、新しいセッションで有効化）、count_redact_targets、遅延サーフェスの料金行、到達可能／到達不能時の init --probe、ダッシュボードフォームのトークンキー（浮動小数点数への強制変換、不明なキーの拒否）
v1.14：redact、rate-limit、probe、複数 API の list	29	エラー本文や選択キーの重複部分を含むあらゆるレベルでのマスキング、配列内でのマスキング、フェイククロックによるレート制限枠、再試行のスロットリング、プローブ対象の選択と到達可能性の終了契約、serve／apis／envs での redact ／ rate-limit 設定、上流サービスごとのリミッター、複数 API の list + 料金表示
障害への対応方針：実環境で見つかったバグは、修正をリリースする前に必ず固定の
回帰テストとして追加します。テストスイートは増え続けます。

ローカルで実行するには：

pip install pytest pyyaml
pytest -v

ロードマップ

v1.6～v1.16 のロードマップはすべてリリース済みです。今後の作業候補（予定ではありません）：サーバー開始型 SSE（セッションを使った GET ストリーム。ステートレスなトランスポートを採用するため、意図的に対象外としています）。

• status によるポリシーの可視化、REPL の :redact／:fields、diff --probe とコスト差分、フォームの例 — v1.16.0 でリリース済み
• 認証済みの doctor --probe と CI ゲートの --fail-on-http-error、init --probe、プロジェクション／リダクションのメトリクス、遅延サーフェスの料金設定 — v1.15.0 でリリース済み
• --redact、--rate-limit、doctor --probe、遅延検索のコスト、複数 API の list — v1.14.0 でリリース済み
• OAuth2 書き込みフロー（--write-oauth2-*）、list --cost、--fields プロジェクション、SSE POST レスポンス — v1.13.0 でリリース済み
• 読み取り／書き込みの認証情報の分離、ツールテキストのオーバーライド、doctor によるプロンプト衛生監査、構造を考慮した切り詰め — v1.12.0 でリリース済み
• 仕様の差分 + 監査ログ + トークン単位の RBAC + プラグインフック + 設定用 JSON Schema + 外部 $ref のバンドル + OTel の追加機能 — v1.11.0 でリリース済み
• Web ダッシュボード、Prometheus メトリクス、モックサーバー、ホットリロード — v1.10.0 でリリース済み
• 複数 API の集約：複数の OpenAPI ドキュメントを 1 つの serve プロセスで提供 — v1.9.0 でリリース済み
• HTTP トランスポート、OAuth2 クライアントクレデンシャル、mcpify try REPL、--output-server — v1.6.0 でリリース済み

ライセンス

MIT — 詳細は LICENSE ファイルをご覧ください。