postman

Postman エージェントスキル

Postman MCP サーバーを通じて、API のライフサイクル全体を管理します。仕様を同期し、コードを生成し、テストを実行し、モックを作成し、ドキュメントを公開し、セキュリティを監査します。

バージョン: 2.0.1 必要なもの: Postman MCP Server

前提条件

このスキルを使用するには、Postman MCP Server が設定されている必要があります。MCP サーバーは、Postman のワークスペース、コレクション、仕様、環境、モック、モニターなどを操作するための 111 個以上のツールを公開します。

セットアップの確認: MCP 経由で getAuthenticatedUser を呼び出します。成功すれば接続されています。失敗した場合は、以下のセットアップ手順に進んでください。

重要：MCP ツールの動作

以下のワークフローを使用する前に、次の動作に注意してください。

• getWorkspaces はすべてのワークスペースを返します。 大規模な組織では 300 KB を超える場合があります。すでにワークスペース ID がある場合は、代わりに getWorkspace(workspaceId) を直接使用してください。
• getCollection のデフォルトの応答は、itemRefs（フォルダー／リクエストのツリー）を含む軽量なマップです。 これは情報の取得に効率的です。完全なリクエスト／レスポンス本文が必要な場合に限り model=full を使用してください。大規模なコレクションでは 300 KB を超える場合があることに注意してください。特定のエンドポイントには、getCollectionRequest と getCollectionResponse を個別に呼び出す方法を優先してください。
• getTaggedEntities は、タグが見つからない場合に空の配列ではなく 404 を返します。 適切に処理してください。タグ機能の利用には Enterprise プランが必要な場合があります。
• runCollection が返すのは集計結果のみです（リクエストの合計数、成功数、失敗数、所要時間）。リクエストごとの詳細やエラーメッセージは返しません。特定の失敗をデバッグするには、実行後に getCollectionRequest と getCollectionResponse を使って個別のリクエストを調べてください。
• searchPostmanElements が検索するのは、公開されている Postman ネットワークのみです。 プライベートワークスペースは検索しません。必ず最初に getCollections を使ってプライベートワークスペースを検索してください。

セットアップ

MCP ツールが利用できない場合、または getAuthenticatedUser が失敗した場合：

1. Postman API キーを取得します。

   • https://postman.postman.co/settings/me/api-keys にアクセスします
   • 「Generate API Key」をクリックし、名前を「Claude Code」にします
   • キーをコピーします（PMAK- で始まります）

2. 環境変数を設定します：

   export POSTMAN_API_KEY=PMAK-your-key-here
   

   永続化するには、~/.zshrc または ~/.bashrc に追加します。

3. 確認します：getAuthenticatedUser を呼び出します。成功したら、getWorkspaces を呼び出してワークスペースを一覧表示し、次にワークスペース ID を指定して getCollections を呼び出し、リソース数を確認します。

以下を提示します：

Connected as: <user name>

Your workspaces:
  - My Workspace (personal) - 12 collections, 3 specs
  - Team APIs (team) - 8 collections, 5 specs

You're all set.

ルーティング

ユーザーのリクエストに Postman または API が関係する場合は、その意図に合った以下のワークフローを選択してください。未加工の MCP ツール呼び出しより、常にこれらの構造化されたワークフローを優先してください。

ユーザーの意図	ワークフロー
仕様をインポートする、仕様を Postman に送信する、仕様からコレクションを作成する、同期する、変更を送信する	コレクションを同期する
クライアントコード、SDK、ラッパー、型付きクライアントを生成する、API を利用する	クライアントコードを生成する
API を見つける、エンドポイントを検索する、利用可能なものを確認する、API を発見する	API を発見する
テストを実行する、テストが成功するか確認する、API を検証する、コレクションをテストする	コレクションテストを実行する
モックサーバーを作成する、偽の API、フロントエンド用のモック、モック URL	モックサーバーを作成する
ドキュメントを生成する、ドキュメントを改善する、ドキュメントを公開する、API ドキュメント	API ドキュメント
セキュリティ監査、脆弱性、OWASP、セキュリティチェック	API セキュリティ監査
自分の API はエージェント対応か、API をスキャンする、AI 向けに仕様を分析する	postman-api-readiness スキルを使用します

ルーティングルール：

1. 具体的なワークフローを優先します。意図が明確にいずれかに当てはまる場合は、それを使用してください。
2. リクエストが曖昧な場合：ユーザーに必要なことを尋ねてください。
3. 複数段階のリクエストではワークフローを連続して実行します。「仕様をインポートしてテストを実行する」＝同期してからテストします。
4. 単一の対象を更新する場合、またはユーザーから明示的に依頼された場合に限り、mcp__postman__* ツールを直接使用してください。

---

ワークフロー：コレクションを同期する

API コードと Postman コレクションを同期した状態に保ちます。OpenAPI 仕様から新しいコレクションを作成したり、既存のコレクションを更新したり、エンドポイントの変更を送信したりできます。

ステップ 1：変更内容を把握する

検出するか、ユーザーに確認します。

• ローカルに OpenAPI 仕様がありますか？**/openapi.{json,yaml,yml}、**/swagger.{json,yaml,yml} を検索します。
• ユーザーはエンドポイントを追加、削除、または変更しましたか？
• 更新する既存の Postman コレクションがありますか？それとも新規作成が必要ですか？

ステップ 2：ワークスペースを解決する

ユーザーがワークスペース ID を指定した場合は、getWorkspace(workspaceId) を直接呼び出します。それ以外の場合は、ワークスペース ID がわかっていれば指定して getCollections を呼び出し、わからなければ使用するワークスペースをユーザーに確認します。大規模な組織アカウントでは、すべてのワークスペース（300KB 以上）が返されるため、フィルターなしで getWorkspaces を呼び出すのは避けます。

ステップ 3：コレクションを見つけるか作成する

既存のコレクションを更新する場合：

1. workspace パラメーターを指定して getCollections を呼び出します
2. 名前で照合するか、どのコレクションかユーザーに確認します
3. getCollection を呼び出して現在の状態を取得します

仕様から作成する場合：

1. ローカルの OpenAPI 仕様を読み込みます
2. workspaceId、name、type（OPENAPI:2.0、OPENAPI:3.0、OPENAPI:3.1、ASYNCAPI:2.0 のいずれか）、および files（{path, content} の配列）を指定して createSpec を呼び出します
3. 仕様から generateCollection を呼び出します。**これは非同期処理（HTTP 202）です。**完了するまで getGeneratedCollectionSpecs または getSpecCollections をポーリングします。
4. 仕様の変数を指定して createEnvironment を呼び出します。
   • servers[0].url から base_url を設定します
   • securitySchemes から認証変数を設定します（secret としてマークします）
   • 一般的なパスパラメーターを設定します

ステップ 4：同期する

仕様からコレクションへ（最も一般的）：

1. ローカルの仕様の内容を使って createSpec または updateSpecFile を呼び出します
2. syncCollectionWithSpec を呼び出してコレクションを更新します。**非同期処理（HTTP 202）です。**完了するまで getCollectionUpdatesTasks をポーリングします。
3. 注意：syncCollectionWithSpec がサポートするのは OpenAPI 3.0 のみです。Swagger 2.0 または OpenAPI 3.1 の場合は、updateSpecFile を使用してから generateCollection で再生成します。
4. 変更内容を報告します

コレクションから仕様へ（逆方向の同期）：

1. syncSpecWithCollection を呼び出して、コレクションの変更内容から仕様を更新します
2. 更新した仕様をローカルファイルに書き戻します

手動で更新する場合（仕様なし）：

1. createCollectionRequest で新しいエンドポイントを追加します
2. updateCollectionRequest で既存のエンドポイントを変更します
3. createCollectionFolder でリソースごとに整理します
4. createCollectionResponse でレスポンス例を追加します

ステップ 5：確認する

Collection synced: "Pet Store API" (15 requests)
  Added:    POST /pets/{id}/vaccinations
  Updated:  GET /pets - added 'breed' filter parameter
  Removed:  (none)

  Environment: "Pet Store - Development" updated
  Spec Hub: petstore-v3.1.0 pushed

---

ワークフロー：クライアントコードを生成する

Postman コレクションから型付きクライアントコードを生成します。非公開の API 定義を読み込み、プロジェクトの規約に沿った本番環境向けのコードを書き出します。

ステップ 1：API を見つける

1. ワークスペース ID がわかっている場合は、getWorkspace(workspaceId) を呼び出して、コレクション、仕様、環境の全インベントリを一度に取得します。それ以外の場合は、使用するワークスペースをユーザーに確認します。
2. workspace パラメーターを指定して getCollections を呼び出します。指定があれば name フィルターを使用します。
3. 非公開のワークスペースで結果が見つからない場合は、searchPostmanElements に切り替えます（公開ネットワークのみ）。
4. getCollection を呼び出して、軽量マップを取得します（デフォルトでは model パラメーターなし）。
5. 紐づく仕様がある場合は、getSpecDefinition を呼び出します（より詳細な型情報を取得できます）。

ステップ 2：API の構造を把握する

関連するエンドポイントごとに、次を実行します。

1. getCollectionFolder を呼び出して、リソースごとのグループ分けを確認します
2. getCollectionRequest を呼び出して、メソッド、URL、ヘッダー、認証、リクエスト本文のスキーマ、パラメーターを取得します
3. getCollectionResponse を呼び出して、ステータスコード、レスポンスの構造、エラー形式を取得します
4. getEnvironment を呼び出して、ベース URL と変数を取得します
5. getCodeGenerationInstructions を呼び出して、Postman 固有のコード生成ガイダンスを取得します

ステップ 3：プロジェクトの言語を検出する

指定されていない場合は、プロジェクトから検出します。

• package.json または tsconfig.json -> TypeScript/JavaScript
• requirements.txt または pyproject.toml -> Python
• go.mod -> Go
• Cargo.toml -> Rust
• pom.xml または build.gradle -> Java
• Gemfile -> Ruby

ステップ 3b：変数の不一致を確認する

コレクションの変数と環境変数を比較します。よくある問題は、コレクションで {{baseUrl}} を使用しているのに、環境では base_url が定義されている（またはその逆）ことです。実行時に気づかないまま失敗する原因となるため、コードを生成する前に、名前の不一致をユーザーに知らせます。

ステップ 4：コードを生成する

型付きクライアントを生成します。以下を含めます。

• エンドポイントごとのメソッドと適切なパラメーター
• コレクションスキーマに基づくリクエスト／レスポンスタイプ
• コレクションの認証設定に基づく認証処理
• ドキュメントに記載されたエラーレスポンスに基づくエラー処理
• 環境変数に基づく設定（ベース URL は環境変数から取得）
• API で使用されている場合はページネーションのサポート

コード規約：

• プロジェクトの既存のスタイル（インポート、フォーマット、命名）に合わせます
• コレクションの説明から JSDoc／docstring を含めます
• プロジェクトに HTTP ライブラリ（axios、fetch、requests など）がある場合は、それを使用します
• 適切なパスに書き込みます（例：src/clients/<api-name>.ts）

ステップ 5：提示する

Generated: src/clients/users-api.ts

  Endpoints covered:
    GET    /users         -> getUsers(filters)
    POST   /users         -> createUser(data)
    GET    /users/{id}    -> getUser(id)
    PUT    /users/{id}    -> updateUser(id, data)
    DELETE /users/{id}    -> deleteUser(id)

  Types generated: User, CreateUserRequest, UpdateUserRequest, UserListResponse, ApiError
  Auth: Bearer token (from USERS_API_TOKEN env var)
  Base URL: from USERS_API_BASE_URL env var

---

ワークフロー：API を見つける

Postman ワークスペース全体で利用可能な API について、自然言語の質問に回答します。エンドポイントを見つけ、レスポンスの形式を確認し、利用可能な内容を把握します。

ステップ 1：検索する

1. ワークスペース ID が分かっている場合は、getWorkspace(workspaceId) を直接呼び出します。それ以外の場合は、ユーザーに尋ねます。
2. workspace パラメーターを指定して getCollections を呼び出します。対象を絞るには name フィルターを使用します。
3. 結果が少ない場合は、検索範囲を広げます。
   • フォールバックとして searchPostmanElements を使用します（パブリックネットワークのみ。プライベートワークスペースでは使用できません）。
   • 注：Enterprise プラン以外では、getTaggedEntities と getCollectionTags が 404／403 を返す場合があります。これらを発見の手段として当てにしないでください。

ステップ 2：結果を詳しく調べる

関連する結果ごとに、以下を行います。

1. 概要を確認するために getCollection を呼び出します（デフォルトでは、完全なペイロードではなく itemRefs を含む軽量なマップが返されます）。
2. マップからエンドポイント名を確認し、関連するフォルダー／リクエストを特定します。
3. 関連する特定のエンドポイントについて getCollectionRequest を呼び出します（対象を絞り、一括取得はしません）。
4. 特定のレスポンスデータについて getCollectionResponse を呼び出します。
5. リンクされた仕様がある場合は getSpecDefinition を呼び出します。

ステップ 3：提示する

見つかった場合：

Yes, you can get a user's email via the API.

  Endpoint: GET /users/{id}
  Collection: "User Management API"
  Auth: Bearer token required

  Response includes:
    { "id": "usr_123", "email": "[email protected]", "name": "Jane Smith" }

  Want me to generate a client for this API?

見つからない場合： 最も近い候補を示し、一致しない理由を説明します。

複数の結果がある場合： エンドポイント数とともにコレクションを一覧表示し、どれを詳しく調べるかユーザーに尋ねます。

---

ワークフロー：コレクションのテストを実行する

Postman コレクションのテストを実行し、結果を分析し、失敗の原因を特定して、修正方法を提案します。

ステップ 1：コレクションを見つける

1. ワークスペース ID が分かっている場合は、getWorkspace(workspaceId) を直接呼び出します。それ以外の場合は、ユーザーに尋ねます。
2. workspace パラメーターを指定して getCollections を呼び出します。指定があれば name フィルターを使用します。

ステップ 2：テストを実行する

getCollection のレスポンスにある uid フィールドから取得した OWNER_ID-UUID 形式のコレクション UID を指定して、runCollection を呼び出します。

環境変数が必要な場合：

1. 利用可能な環境を一覧表示するために getEnvironments を呼び出します。
2. 使用する環境をユーザーに尋ねるか、命名規則から判断します。
3. 環境 ID を runCollection に渡します。

ステップ 3：結果を解析する

注： runCollection が返すのは集計結果のみです（リクエストの合計数、成功／失敗数、所要時間）。リクエストごとの詳細は含まれません。利用可能な情報を提示します。

Test Results: Pet Store API
  Requests:  15 executed
  Failed:    3
  Assertions: 24 total, 21 passed
  Duration:  12.4s

テストが失敗し、リクエストごとの詳細が必要な場合は、getCollectionRequest でコレクションのテストスクリプトとリクエスト定義を調べ、原因の特定に役立てます。詳細な失敗ログを確認するには、ユーザーが Postman アプリまたはモニターの実行結果を確認する必要がある場合もあります。

ステップ 4：失敗の原因を特定する

失敗ごとに、以下を行います。

1. 完全なリクエスト定義を取得するために getCollectionRequest を呼び出します。
2. 期待されるレスポンスを確認するために getCollectionResponse を呼び出します。
3. API のソースコードが現在のプロジェクト内にあるか確認します。
4. 期待値と実際の値を説明します。
5. コードがローカルにある場合は、ハンドラーを見つけて修正方法を提案します。

ステップ 5：修正して再実行する

修正後、再実行を提案し、修正前後を比較して示します。

ステップ 6：コレクションを更新する（必要な場合）

テスト自体の更新が必要な場合：

• updateCollectionRequest でリクエストボディ、ヘッダー、またはテストスクリプトを修正します
• updateCollectionResponse で期待されるレスポンスを更新します

---

ワークフロー：モックサーバーを作成する

コレクションまたは仕様から Postman モックサーバーを起動します。フロントエンド開発、統合テスト、デモに使えるモック URL を取得します。

ステップ 1：ソースを探す

ワークスペース ID がわかっている場合は、getWorkspace(workspaceId) を直接呼び出します。それ以外の場合は、ユーザーに確認します。

既存のコレクションから： ワークスペース ID を指定して getCollections を呼び出す → 対象のコレクションを選択

ローカルの仕様から： まずインポートします。

1. ワークスペース、名前、種類、ファイルを指定して createSpec を呼び出す
2. generateCollection を呼び出す。非同期（HTTP 202）です。 完了するまで getGeneratedCollectionSpecs または getSpecCollections をポーリングします。

ステップ 2：例を確認する

モックサーバーは例のレスポンスを提供します。getCollection を呼び出し、リクエストに保存済みのレスポンスがあるか確認します。

ない場合は、現実的な例を生成します。

1. 各リクエストのスキーマを取得するために getCollectionRequest を呼び出す
2. スキーマから現実的な例のレスポンスを生成する
3. 例を保存するために createCollectionResponse を呼び出す

ステップ 3：既存のモックを確認する

getMocks を呼び出して、このコレクション用のモックがすでに存在するか確認します。見つかった場合は、その URL を提示します。新規作成するのは、モックが存在しない場合、または明示的に依頼された場合のみです。

ステップ 4：モックサーバーを作成する

次の情報を指定して createMock を呼び出します。

• ワークスペース ID
• ownerId-collectionId 形式のコレクション UID（getCollection のレスポンスの uid フィールドから取得）
• 環境 ID（該当する場合）
• 名前：<api-name> Mock
• プライベート：false（または希望する場合は true）

ステップ 5：提示する

Mock server created: "Pet Store API Mock"
  URL: https://<mock-id>.mock.pstmn.io
  Status: Active

  Try it:
    curl https://<mock-id>.mock.pstmn.io/pets
    curl https://<mock-id>.mock.pstmn.io/pets/1
    curl -X POST https://<mock-id>.mock.pstmn.io/pets -d '{"name":"Buddy"}'

  The mock serves example responses from your collection.
  Update examples in Postman to change mock behavior.

ステップ 6：統合する

Quick integration:
  # Add to your project .env
  API_BASE_URL=https://<mock-id>.mock.pstmn.io

  # Or in your frontend config
  const API_URL = process.env.API_BASE_URL || 'https://<mock-id>.mock.pstmn.io';

ステップ 7：公開する（任意）

ユーザーが一般公開を希望する場合：

• 認証なしでアクセスできるようにするには publishMock を呼び出します（デモ、ハッカソン、公開ドキュメント向け）
• 再びプライベートにするには unpublishMock を呼び出します

---

ワークフロー：API ドキュメント

OpenAPI 仕様と Postman コレクションから API ドキュメントを分析、改善、公開します。

ステップ 1：ソースを探す

次の順に API 定義を確認します。

ローカルの仕様： **/openapi.{json,yaml,yml}、**/swagger.{json,yaml,yml} を検索

Postman の仕様： ワークスペース ID を指定して getAllSpecs を呼び出し、続けて getSpecDefinition を呼び出して仕様全体を取得

Postman コレクション： getCollections を呼び出し、続けて getCollection を呼び出して詳細全体を取得

ステップ 2：完全性を分析する

Documentation Coverage: 60%
  Endpoints with descriptions:     8/15
  Parameters with descriptions:    22/45
  Endpoints with examples:         3/15
  Error responses documented:      2/15
  Authentication documented:       Yes
  Rate limits documented:          No

ステップ 3：生成または改善する

情報が少ない仕様： 各エンドポイントのドキュメント（概要、パラメーターテーブル、リクエスト／レスポンスのスキーマ、例、エラーの説明、認証要件）を生成します。

一部のみ記載された仕様： 不足を補います（名前やスキーマから推測できる説明の追加、現実的な例の生成、エラーレスポンスの追加、認証とレート制限の記載）。

ステップ 4：変更を適用する

出力先をユーザーに確認します。

1. 仕様ファイルを更新する - 改善したドキュメントを OpenAPI 仕様に書き戻します
2. Postman を更新する - updateCollectionRequest を呼び出して説明と例を追加します
3. 公開ドキュメントを公開する - コレクション ID を指定して publishDocumentation を呼び出すと、公開 URL が返されます。公開を取り下げるには unpublishDocumentation を呼び出します。
4. Markdown を生成する - プロジェクト用に docs/api-reference.md を作成します

ステップ 5：同期する

仕様とコレクションの両方が存在する場合は、同期状態を維持します。

• syncCollectionWithSpec を呼び出して仕様からコレクションを更新します（非同期、OpenAPI 3.0 のみ）
• syncSpecWithCollection を呼び出してコレクションの変更から仕様を更新します

---

ワークフロー：API セキュリティ監査

OWASP API Security Top 10 に照らして、API のセキュリティ上の問題を監査します。ローカルの OpenAPI 仕様と Postman コレクションに対応しています。

ステップ 1：ソースを探す

ローカルの仕様： プロジェクト内で OpenAPI／Swagger ファイルを検索

Postman の仕様： getAllSpecs を呼び出し、続けて getSpecDefinition を呼び出す

Postman コレクション： 認証設定を含めて getCollections を呼び出し、続けて getCollection を呼び出します。また、公開されたシークレットを確認するために getEnvironment も呼び出します。

Step 2: セキュリティチェックを実行する

認証と認可：

• セキュリティスキームが定義されている（OAuth2、API Key、Bearer など）
• セキュリティがグローバルまたはエンドポイントごとに適用されている
• 誤って保護されていないエンドポイントがない
• OAuth2 スコープが定義され、適切である
• 管理者用エンドポイントに、より高い認証レベルが設定されている

トランスポートセキュリティ：

• すべてのサーバー URL が HTTPS を使用している
• HTTP と HTTPS が混在していない

機密データの露出：

• サンプル値に API キー、トークン、パスワードが含まれていない
• クエリパラメーターにシークレットが含まれていない（ヘッダーまたは本文に含める必要があります）
• パスワードフィールドに format: password が指定されている
• PII フィールドが特定されている
• Postman 環境変数に漏えいしたシークレットがないか確認されている（getEnvironment を使用）

入力の検証：

• すべてのパラメーターに型が定義されている
• 文字列パラメーターに maxLength が設定されている
• 数値パラメーターに minimum／maximum が設定されている
• 配列パラメーターに maxItems が設定されている
• 該当する場合、列挙値が使用されている
• リクエスト本文に必須フィールドの検証が設定されている

レート制限：

• レート制限が文書化されている
• レート制限ヘッダーが定義されている（X-RateLimit-Limit、X-RateLimit-Remaining）
• 429 レスポンスが定義されている

エラー処理：

• エラーレスポンスからスタックトレースが漏えいしない
• エラースキーマから内部フィールド名が露出しない
• 401 および 403 レスポンスが適切に定義されている

OWASP API Top 10：

• API1: オブジェクトレベル認可の不備
• API2: 認証の不備
• API3: オブジェクトプロパティレベル認可の不備
• API4: リソース消費の制限不足
• API5: 関数レベル認可の不備
• API6: 機密性の高いビジネスフローへのアクセス制限不足
• API7: サーバーサイドリクエストフォージェリ
• API8: セキュリティ設定の不備
• API9: 不適切なインベントリ管理
• API10: API の安全でない利用

Step 3: 結果を提示する

API Security Audit: pet-store-api.yaml

  CRITICAL (2):
    SEC-001: 3 endpoints have no security scheme applied
      - GET /admin/users
      - DELETE /admin/users/{id}
      - PUT /admin/config
    SEC-002: Server URL uses HTTP (http://api.example.com)

  HIGH (3):
    SEC-003: No rate limiting documentation or 429 response
    SEC-004: API key sent as query parameter (use header instead)
    SEC-005: No maxLength on 8 string inputs (injection risk)

  MEDIUM (2):
    SEC-006: Password field visible in GET /users/{id} response
    SEC-007: Environment variable 'db_password' not marked secret

  Score: 48/100 - Significant Issues

Step 4: 修正する

検出事項ごとに、次の操作を行います。

1. セキュリティリスクをわかりやすく説明します
2. 必要な仕様変更を正確に示します
3. ユーザーの承認を得て修正を適用します

Postman 固有の問題の場合：

• putEnvironment を使用してシークレットを適切に指定します
• updateCollectionRequest を使用して認証設定を修正します
• updateCollectionResponse を使用してサンプルから機密データを削除します

Step 5: 再監査する

修正後、再実行して改善状況を示します。

---

エラー処理

これらのパターンは、すべてのワークフローに適用されます。

エラー	対応
MCP ツールを利用できない	「Postman MCP Server が設定されていません。POSTMAN_API_KEY 環境変数を設定し、エディターを再起動してください。」
401 Unauthorized	「Postman API キーが拒否されました。https://postman.postman.co/settings/me/api-keys で新しいキーを生成してください。」
ネットワークタイムアウト	1 回再試行します。障害については https://status.postman.com を確認してください。
非同期操作が停止している	ポーリングで 30 秒経過しても進展がない場合は、ユーザーに伝え、Postman アプリを直接確認するよう案内します。
コレクションが見つからない	「その名前に一致するコレクションはありません。ワークスペース全体で API を検出してみてください。」
空のコレクション	「このコレクションにはリクエストがありません。Postman でエンドポイントを追加するか、ローカルの仕様から同期してください。」
仕様が無効	行番号を含めて具体的な解析エラーを報告します。一般的な YAML／JSON 構文の問題の修正を提案します。
プランの制限	「一部の機能には、有料の Postman プランが必要な場合があります。基本的な操作はすべてのプランで利用できます。」

MCP ツールリファレンス

ツールの完全なカタログについては references/mcp-tools.md を、既知の制限事項と回避策については references/mcp-limitations.md を参照してください。