swagger-doc-explorer-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SWAGGER_HTTP_PORT | No | Set to enable HTTP mode (e.g. '3000'). Omit for stdio mode. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| swagger_load_specA | Load and parse an OpenAPI (Swagger) specification document from a URL. This tool fetches a JSON OpenAPI/Swagger spec from the given URL and stores it in memory for subsequent exploration. You must load a spec before using any other tools. Each loaded spec is assigned a unique name (title + version). If a spec with the same name already exists, a numeric suffix is appended. Args:
Returns: { "spec_name": string, // The assigned spec name for subsequent tools "title": string, // API title from the spec "version": string, // API version from the spec "description": string, // API description (if available) "endpoints": number, // Total number of API endpoints found "schemas": number, // Total number of schemas/components found "tags": number, // Total number of unique tags found "server_url": string // Base server URL from the spec } Examples:
Error Handling:
|
| swagger_load_local_specA | Load and parse an OpenAPI (Swagger) specification document from a local JSON file. This tool reads a JSON OpenAPI/Swagger spec from a local file path and stores it in memory for subsequent exploration. The file path can be absolute or relative to the current working directory. Each loaded spec is assigned a unique name (title + version). If a spec with the same name already exists, a numeric suffix is appended. Args:
Returns: { "spec_name": string, // The assigned spec name for subsequent tools "title": string, // API title from the spec "version": string, // API version from the spec "description": string, // API description (if available) "endpoints": number, // Total number of API endpoints found "schemas": number, // Total number of schemas/components found "tags": number, // Total number of unique tags found "server_url": string // Base server URL from the spec } Examples:
Error Handling:
|
| swagger_list_loadedA | List all currently loaded OpenAPI/Swagger specifications in memory. Use this tool to see which specs have been loaded and are available for exploration. Args: None Returns: { "loaded": [ // Array of loaded specs { "name": string, "title": string, "version": string, "source": string, "loaded_at": string } ] } Examples:
|
| swagger_remove_specA | Remove a loaded OpenAPI/Swagger specification from memory. Use this tool to free up memory or reload a spec that has changed. Args:
Returns: Confirmation message. Examples:
Error Handling:
|
| swagger_list_pathsA | List all API endpoints (paths and HTTP methods) from a loaded OpenAPI spec, optionally filtered by tag. Use this tool to get a high-level overview of all available API operations. Results can be filtered by tag for progressive exploration. Args:
Returns: { "total": number, // Total number of matching endpoints "count": number, // Number of results in this response "offset": number, // Current pagination offset "endpoints": [...], "has_more": boolean, "next_offset": number } Examples:
Error Handling:
|
| swagger_get_endpointA | Get detailed information about a specific API endpoint, including parameters, request body, responses, and security requirements. Use this tool after swagger_list_paths to drill down into a specific endpoint's complete details. Args:
Returns: Full endpoint details with parameters, request body, responses, and security. Examples:
Error Handling:
|
| swagger_get_endpoint_fullA | Get detailed information about a specific API endpoint with all schema references ($ref) recursively resolved. Unlike swagger_get_endpoint, this tool resolves every $ref into its full schema definition. Parameters, request body schemas, and response schemas are expanded inline with no external references. Circular references are detected and marked. Use this when you need the complete endpoint definition in a single call, without needing to follow $ref links manually. Args:
Returns: Full endpoint details with all $ref resolved recursively. Examples:
Error Handling:
|
| swagger_list_schemasA | List all component schemas (data models) defined in the loaded OpenAPI spec. Use this tool to get an overview of all data models used by the API, including their types and number of properties. Args:
Returns: { "total": number, // Total number of schemas "count": number, // Number of results in this response "offset": number, // Current pagination offset "schemas": [{ "name", "type", "description", "properties" }], "has_more": boolean, "next_offset": number } Examples:
Error Handling:
|
| swagger_get_schemaA | Get detailed information about a specific component schema (data model), including all properties, types, constraints, and examples. Use this tool to drill down into a specific data model after using swagger_list_schemas. Args:
Returns: Formatted output with the full schema definition including type, properties, required fields, enums, constraints, and examples. Examples:
Error Handling:
|
| swagger_get_infoA | Get general information about a loaded OpenAPI/Swagger specification, including title, version, description, server URL, contact info, and license. Use this tool to get a high-level summary of an API spec. Args:
Returns: { "title": string, // API title "version": string, // API version "description": string, // API description "server_url": string, // Base server URL "endpoints": number, // Total endpoint count "schemas": number, // Total schema count "tags": number, // Total tag count "openapi_version": string // OpenAPI spec version } Examples:
Error Handling:
|
| swagger_list_tagsA | List all API tags/groups and their associated endpoint counts from a loaded OpenAPI spec. Tags are used to group related endpoints. This tool helps with progressive exploration by showing available filter categories. Args:
Returns: { "tags": [{ "name": string, "count": number }] } Examples:
Error Handling:
|
| swagger_searchA | Search across all endpoints and schemas in a loaded OpenAPI spec for a given query string. Searches through endpoint paths, operation summaries, operationIds, descriptions, tags, schema names, and property names. Args:
Returns: { "total": number, // Total number of matches "results": [ { "type": "endpoint" | "schema" | "property", "path": string, // URL path (for endpoints) "method": string, // HTTP method (for endpoints) "schemaName": string, // Schema name (for schemas/properties) "propertyName": string, // Property name (for properties) "match": string, // Human-readable match description "summary": string // Brief description } ] } Examples:
Error Handling:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool has a clearly distinct purpose: loading (URL vs local file), managing loaded specs, listing tags/paths/schemas, getting details, and searching. The two endpoint-detail tools differ explicitly in whether schema references are resolved, and their descriptions make this clear.
All tools follow a consistent snake_case pattern with the 'swagger_' prefix and a verb-object structure (load_spec, list_tags, get_endpoint, etc.). Exceptions like load_local_spec and get_endpoint_full are systematic and readable.
12 tools is well-scoped for a Swagger/OpenAPI explorer. The count covers the full exploration lifecycle—loading, listing, retrieving, searching, and managing specs—without unnecessary bloat or missing essentials.
The tool surface is complete for the stated exploration purpose. It supports loading (URL + local), inspecting info/tags/paths/schemas, drilling into endpoints (with optional full $ref resolution), searching, and removing specs. No obvious dead ends or missing operations.