Skip to main content
Glama
gulbaki

Swagger/OpenAPI MCP Server

by gulbaki

Swagger/OpenAPI MCP Server

A Model Context Protocol (MCP) server that allows LLMs to explore and interact with Swagger/OpenAPI specifications. This server provides tools and resources for loading API specifications, browsing endpoints, and getting detailed information about API operations.

Installation

  1. Clone or create the project directory

  2. Install dependencies:

npm install
  1. Build the TypeScript code:

npm run build

Related MCP server: OpenAPI MCP Server

Usage

Available Tools

load_api

Load an OpenAPI/Swagger specification into the server.

Parameters:

  • apiId (string): Unique identifier for this API

  • source (string): URL or file path to the OpenAPI/Swagger specification

Example:

{
  "name": "load_api",
  "arguments": {
    "apiId": "petstore",
    "source": "https://petstore.swagger.io/v2/swagger.json"
  }
}

get_endpoint_details

Get detailed information about a specific API endpoint.

Parameters:

  • apiId (string): ID of the loaded API

  • method (string): HTTP method (GET, POST, etc.)

  • path (string): API endpoint path

  • natural (boolean, optional): If true, returns a human-readable summary

Example:

{
  "name": "get_endpoint_details",
  "arguments": {
    "apiId": "petstore",
    "method": "GET",
    "path": "/pet/{petId}",
    "natural": true
  }
}

list_apis

List all currently loaded API specifications.

Parameters: None

search_endpoints

Search for endpoints matching a specific pattern.

Parameters:

  • apiId (string): ID of the loaded API

  • pattern (string): Search pattern for endpoint paths or descriptions

Example:

{
  "name": "search_endpoints",
  "arguments": {
    "apiId": "petstore",
    "pattern": "pet"
  }
}

Available Resources

swagger://{apiId}/load

Get overview information about a loaded API specification.

swagger://{apiId}/endpoints

Get a list of all available endpoints for an API.

swagger://{apiId}/endpoint/{method}/{path}

Get detailed information about a specific endpoint.

Configuration with Claude Desktop

To use this server with Claude Desktop, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "swagger-explorer": {
      "command": "node",
      "args": ["/path/to/your/swagger-mcp-server/build/index.js"]
    }
  }
}

Replace /path/to/your/swagger-mcp-server with the actual path to your project directory.

License

MIT License

Available Tools

4 tools
get_endpoint_detailsD
ParametersJSON Schema
NameRequiredDescriptionDefault
apiIdYesID of the loaded API
methodYesHTTP method (GET, POST, etc.)
pathYesAPI endpoint path
naturalNoIf true, returns a human-readable summary

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_apisD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

load_apiD
ParametersJSON Schema
NameRequiredDescriptionDefault
apiIdYesUnique identifier for this API
sourceYesURL or file path to the OpenAPI/Swagger specification

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_endpointsD
ParametersJSON Schema
NameRequiredDescriptionDefault
apiIdYesID of the loaded API
patternYesSearch pattern for endpoint paths or descriptions

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • Changedlist_apis1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 4 tool updates
    • First observedget_endpoint_details
    • First observedlist_apis
    • First observedload_api
    • First observedsearch_endpoints

TDQS

D1.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_endpoint_details retrieves specific endpoint information, list_apis enumerates available APIs, load_api loads an API specification, and search_endpoints searches across endpoints. There is no overlap or ambiguity in their functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_endpoint_details, list_apis, load_api, search_endpoints). The naming is uniform and predictable, using snake_case throughout with clear action-object pairs.

Tool Count3/5

With only 4 tools, the set feels thin for a Swagger/OpenAPI server, which typically involves operations like validating, updating, or testing APIs. While the core functions are covered, the scope could benefit from additional tools for a more comprehensive API management surface.

Completeness3/5

The tools cover basic operations (list, load, get, search), but there are notable gaps for a full API lifecycle, such as creating, updating, or deleting APIs/endpoints, and validating specifications. Agents can perform read and search tasks but may hit dead ends for modification workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    A server that enables Large Language Models to discover and interact with REST APIs defined by OpenAPI specifications through the Model Context Protocol.
    3,501
    289
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol Server that enables LLMs to interact with and execute REST API calls through natural language prompts, supporting GET/PUT/POST/PATCH operations on configured APIs.
    6
    Apache 2.0
  • A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that loads multiple OpenAPI specifications and exposes them to LLM-powered IDE integrations, enabling AI to understand and work with your APIs directly in development tools like Cursor.
    7
    83
    90
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol server that generates and runs mock API servers from API documentation like OpenAPI/Swagger specs, enabling developers and AI assistants to quickly spin up mock backends for development and testing.
    17
    MIT

Latest Blog Posts

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/gulbaki/swagger-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server