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. |
Capabilities
Features and capabilities supported by this server
| 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 | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/anuoua/swagger-doc-explorer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server