Update to Postman

{
  "description": "Use when working through Postman MCP tools to inspect or change workspace resources, choose a targeted operation, or handle MCP limitations. Supports hosted workflows when the CLI is unavailable and distinguishes tool completion from a usable result. Use for requests such as \"use Postman MCP to inspect this collection\".",
  "included_files": [
    {
      "relative_path": "references/docs.md",
      "size_in_bytes": 3449
    },
    {
      "relative_path": "references/learn.md",
      "size_in_bytes": 3862
    },
    {
      "relative_path": "references/mcp-limitations.md",
      "size_in_bytes": 1691
    },
    {
      "relative_path": "references/mock.md",
      "size_in_bytes": 3689
    },
    {
      "relative_path": "references/search.md",
      "size_in_bytes": 3656
    },
    {
      "relative_path": "references/security.md",
      "size_in_bytes": 4644
    },
    {
      "relative_path": "references/setup.md",
      "size_in_bytes": 5535
    },
    {
      "relative_path": "references/sync.md",
      "size_in_bytes": 3932
    },
    {
      "relative_path": "references/test.md",
      "size_in_bytes": 3031
    }
  ],
  "name": "postman-mcp-server",
  "skill_md_contents": "---\nname: postman-mcp-server\ndescription: Use when working through Postman MCP tools to inspect or change workspace resources, choose a targeted operation, or handle MCP limitations. Supports hosted workflows when the CLI is unavailable and distinguishes tool completion from a usable result. Use for requests such as \"use Postman MCP to inspect this collection\".\n---\n\n# Postman MCP Server\n\nMCP exposes workspace resources directly to an agent. Existing collections,\nspecs, examples, and environments provide maintained API knowledge; fetching\nthe relevant entity preserves that context when a local CLI workflow is not\navailable. For repository edits and Git review, prefer the local workflows in\n**api-engineer** when available.\n\nEach tool definition exposed to the model consumes context whenever it is\nincluded in a request. Prefer the smallest available toolset that covers the\ntask; expanding to every tool can crowd out the API evidence needed to reason.\nWhen exposed, call `getEnabledTools` to inspect the active toolset before\ndiagnosing a missing operation. Otherwise use the host's discovered tools and\nreport that limitation. Do not infer availability from reference tool names or\nassume a client can switch a route pinned to a specific MCP endpoint.\n\n1. Select tools from the connected server's actual surface. Tool availability\n   varies by mode; a name listed in a reference is not proof it is exposed.\n   Use [setup](references/setup.md) for connection/auth failures and\n   [limitations](references/mcp-limitations.md) when an operation is missing\n   or behaves differently from the CLI.\n2. Search to locate an entity, then fetch enough detail to work on it.\n   `searchPostmanElements` finds candidates; collection, spec, and workspace\n   detail tools establish IDs, ownership, and content. A search preview is\n   insufficient evidence for replacing a collection or declaring an API absent.\n3. Match the mutation to the intended scope. Request-level updates preserve\n   unrelated collection content; whole-collection replacement requires the\n   current complete object. A workspace is a container and access boundary,\n   not a reason to create duplicate resources whenever a new task begins.\n4. Preserve the source of truth when synchronizing. Spec-to-collection\n   generation reuses the interface, while collection-to-spec sync carries\n   changes in the other direction. Choose from the intended contract rather\n   than overwriting whichever artifact is easiest to reach. An asynchronous\n   acceptance response needs a completed task result before claiming sync.\n5. Treat publication separately from editing. A collection example can feed\n   docs and a classic mock, but neither becomes publicly accessible merely\n   because it exists. Apply the user's intended audience and authorization\n   before publishing docs or mocks, or changing shared resources.\n\nRead the reference for the branch being used:\n\n| Task | Reference and decision it supports |\n| --- | --- |\n| Locate an API | [Search](references/search.md): narrow candidates to the intended resource |\n| Generate or synchronize artifacts | [Sync](references/sync.md): choose source and track completion |\n| Serve saved examples | [Mock](references/mock.md): classic collection mocks; for CLI Code Mocks use **api-mocking** |\n| Execute saved assertions | [Test](references/test.md): distinguish run completion from failures |\n| Improve or publish docs | [Docs](references/docs.md): fill contract gaps and verify reader access |\n| Requested security review | [Security](references/security.md): assess concrete API risks |\n| Product how-to questions | [Learning Center](references/learn.md): product documentation search when exposed |\n\n## Verification\n\nState the active toolset as observed through `getEnabledTools`, or identify the\nhost discovery evidence used when that tool is unavailable. Report any operation\nthe connected surface could not perform instead of claiming it succeeded.\n\nReport the resource and observed result: assertions for a run, completed sync\nfor a generated artifact, or the reachable URL and visibility for publication.\nTool success alone does not establish any of those outcomes.\n"
}