swagger-api-mcp-server

Load Swagger/OpenAPI Spec

swagger_load_spec

Read-onlyIdempotent

Load and parse Swagger 2.0 or OpenAPI 3.x specs from a URL. Supports JSON and YAML formats, caching locally for use by other tools.

Instructions

Load and parse a Swagger 2.0 or OpenAPI 3.x specification from a URL. Supports both JSON and YAML formats. The loaded spec is parsed, cached to local JSON files, and used by all subsequent tools. Must be called first before using other tools (unless SWAGGER_URL env var is set).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "swagger_load_spec"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	URL of the Swagger/OpenAPI spec (JSON or YAML)
`headers`	No	Optional HTTP headers for fetching the spec (e.g. authorization)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.6Aug 9, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds valuable context beyond annotations: it caches to local JSON files, is used by all subsequent tools, and must be called first. It doesn't disclose all details (e.g., overwrite behavior, error handling), but the added context satisfies the need for behavioral transparency beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: purpose and formats, caching behavior, and required ordering. It is front-loaded and free of redundant or vague wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a moderately complex setup tool, the description covers purpose, accepted formats, caching, subsequent tool dependencies, and invocation order. Given the high schema coverage and suitable annotations, the description is complete enough for an agent to select and use this tool correctly. It even notes an environment-variable shortcut, which is valuable operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both 'url' and 'headers' already have clear descriptions. The tool description mentions JSON/YAML support, but that is already embedded in the url parameter description. No additional parameter-level meaning is provided beyond what the schema already gives, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Load and parse'), names the resource ('Swagger 2.0 or OpenAPI 3.x specification from a URL'), and distinguishes this tool from siblings by framing it as the initialization step for all subsequent tools. It also specifies supported formats (JSON/YAML), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Must be called first before using other tools' and notes the exception when SWAGGER_URL env var is set. This clearly tells the agent when to invoke this tool versus alternatives (the sibling tools that operate on the loaded spec).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server