What can you do with this server?

This server discovers, analyzes, and executes OpenAPI/Swagger APIs through a set of intelligent tools: * Detect OpenAPI specs (detect_openapi): Auto-discover and parse OpenAPI/Swagger documents from docs pages or direct URLs, including protected specs (Basic, Bearer, API Key) * Summarize API info: Provides metadata summaries including servers, tags, and endpoint counts * List endpoints (list_endpoints): Browse all endpoints with filters by HTTP method, tag, path fragment, or deprecation status * Search endpoints (search_endpoints): Server-side semantic/keyword search across cached endpoint metadata (paths, summaries, tags, parameters, schema fields) * Get endpoint details (get_endpoint_details): Retrieve full request/response schema details for a specific endpoint * Trace parameter usage (trace_parameter_usage): Track where a field or identifier (e.g., userId) appears across path params, query params, request bodies, and response bodies * Find related endpoints (find_related_endpoints): Discover structurally related endpoints via shared resources, identifiers, tags, and URL patterns * Suggest call sequences (suggest_call_sequence): Get multi-step workflow suggestions (e.g., login → create category → create product) based on a target endpoint or natural-language goal * Execute real HTTP requests (call_endpoint): Make actual API calls with path/query/header parameters, JSON/form-urlencoded/multipart/raw payloads, and authentication via Basic, Bearer, API Key, or OAuth 2.0 (password/client credentials) * Persistent caching: Discovered specs are cached to disk, enabling specId-based tools to work across process restarts

Which integrations are available for this server?

Provides specialized support for Laravel projects utilizing L5 Swagger, allowing for the discovery and summarization of API endpoints within Laravel-based applications. Enables the discovery, inspection, and execution of API endpoints from Swagger UI deployments and OpenAPI specifications, including support for tracing parameter usage and making authenticated requests.

How do I use MCP OpenAPI Discovery?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP OpenAPI Discovery detect the API spec at https://petstore.swagger.io and list all available endpoints" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

MCP OpenAPI Discovery

by Rekl0w

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@rekl0w/mcp-openapi-discovery

@rekl0w/mcp-openapi-discovery is a TypeScript MCP server that can:

detect OpenAPI / Swagger documents from a URL,
inspect and summarize endpoints,
trace field and identifier usage across the API,
and execute real HTTP requests against those endpoints with auth and payload support.

It is designed for documentation-first API workflows where you want an MCP client to move from "find the spec" to "understand the endpoint" to "call the endpoint".

Published package:

npm: @rekl0w/mcp-openapi-discovery

Release resources:

GitHub Releases: Rekl0w/mcp-openapi-discovery releases

Why this project exists

Many APIs expose documentation pages, but not always the raw spec URL directly. This server helps bridge that gap by discovering the OpenAPI document behind a docs page and turning it into callable MCP tools.

It is especially useful for:

Swagger UI deployments
ReDoc documentation pages
Laravel + L5 Swagger projects
APIs exposing openapi.json, swagger.json, openapi.yaml, or swagger.yaml
docs pages that reference the spec indirectly through HTML or JS config

Related MCP server: swagger-doc-explorer-mcp

Features

Detect OpenAPI / Swagger specs from docs pages or direct spec URLs
Detect protected docs/spec pages by sending Basic auth, Bearer tokens, API keys, or custom discovery headers
Assign a stable in-memory specId for each detected spec so later tools can work without re-exposing the full document
Persist discovered specs on disk so specId-based tools can survive process restarts
Summarize API metadata, servers, tags, and endpoint counts
List endpoints with filtering by method, tag, or path fragment
Search endpoints server-side with weighted matching across methods, paths, tags, summaries, parameters, schema field names, synonyms, and operation intent
Inspect request / response details for a specific endpoint
Trace where identifiers like userId, accountId, or teamId appear across parameters and schemas
Find endpoints that are structurally related to another endpoint
Suggest likely multi-step API workflows such as login → create category → create attribute → create product
Bundle external $ref files and remote schema references into a local in-memory document before analysis
Execute endpoints with:
- path params
- query params
- custom headers
- JSON payloads
- form-urlencoded payloads
- basic multipart form data
Apply authentication with:
- Basic auth
- Bearer tokens
- API keys
- OAuth 2.0 password flow
- OAuth 2.0 client credentials flow
- automatic auth selection based on the OpenAPI security scheme

Available MCP tools

detect_openapi: detects the OpenAPI document behind a docs page or spec URL and returns a summary
list_endpoints: lists endpoints with optional filtering
search_endpoints: searches cached endpoints for a detected spec using server-side weighted scoring
suggest_call_sequence: suggests a likely prerequisite call chain for a target endpoint or a natural-language goal
get_endpoint_details: returns request / response details for a single endpoint
trace_parameter_usage: traces where a parameter or field is used across parameters, request bodies, and response bodies
find_related_endpoints: finds endpoints related to a source endpoint through shared resources, identifiers, and path structure
call_endpoint: executes a real request against an endpoint discovered from the OpenAPI document

Requirements

Node.js 18+
npm 9+ recommended

Installation

Install from npm:

npm i @rekl0w/mcp-openapi-discovery

Or install project dependencies when working from source:

npm install
npm run build

Running locally

Run the stdio MCP server after building:

node dist/index.js

For development:

npm run dev

Connecting from an MCP client

The easiest way to use the published package in MCP clients is to let the client auto-install and run it through npx.

Auto-install from npm with `npx`

If your MCP client supports a command + args stdio server definition, use:

{
  "command": "npx",
  "args": ["-y", "@rekl0w/mcp-openapi-discovery"]
}

This is usually the cleanest setup for clients such as VS Code and Cursor-like MCP clients because the package is downloaded automatically when the server starts.

VS Code (`.vscode/mcp.json`)

VS Code supports mcp.json and can run local MCP servers through npx.

{
  "servers": {
    "openapi-discovery": {
      "command": "npx",
      "args": ["-y", "@rekl0w/mcp-openapi-discovery"]
    }
  }
}

Cursor-style MCP config

For MCP clients that use a JSON config with mcpServers, a typical setup looks like this:

{
  "mcpServers": {
    "openapi-discovery": {
      "command": "npx",
      "args": ["-y", "@rekl0w/mcp-openapi-discovery"]
    }
  }
}

Local build instead of npm

If you prefer to run the local build directly instead of using npm, point your MCP client at dist/index.js.

Claude Desktop example (Windows)

Add this to %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "openapi-discovery": {
      "command": "node",
      "args": ["C:/absolute/path/to/project/dist/index.js"]
    }
  }
}

Use an absolute path. On Windows, either forward slashes or escaped backslashes work.

Example use cases

Detect the spec behind https://example.com/docs
Detect a spec, keep the returned specId, and search only the most relevant endpoints
Detect a spec, keep the returned specId, and reuse it across restarts via persistent cache
List endpoints from https://api.example.com/openapi.json
Inspect the PUT /users/{id} endpoint
Filter only POST endpoints tagged with users
Ask the server for a likely workflow such as “create product with category and attributes”
Trace where userId appears across the API
Find endpoints related to GET /users/{id}
Send a real POST /orders request with a JSON payload
Log in with username/password, obtain a token, and call a protected endpoint

Structured tracing

Beyond plain endpoint listing, this server can help answer questions like:

“Where is userId used?”
“Which endpoints are related to GET /users/{id}?”
“Is this identifier coming from a response body, a query parameter, or a path parameter?”

This now combines structured analysis with lightweight server-side endpoint search. Instead of only doing natural-language similarity on the client, the server can inspect and score:

path parameters
query parameters
request body fields
response body fields
shared resource names in paths
shared identifier patterns such as userId, accountId, teamId, or entity-specific id fields

`specId` + `search_endpoints` flow

Run detect_openapi first and keep the returned specId.

Then call search_endpoints with that specId and a natural-language query such as:

create user email
refresh bearer token
order status update

The server builds a searchable text index per endpoint from:

HTTP method and path
operationId, summary, description, and tags
parameter names
request body field names
response body field names

This keeps endpoint retrieval on the server side and returns only the top matches.

The search scorer also adds intent-aware bonuses so queries like add order, login token, or edit product can still match createOrder, auth endpoints, and PATCH/PUT style operations without embeddings.

`suggest_call_sequence` flow

Use suggest_call_sequence when the hard part is not finding the endpoint, but figuring out the order of dependent calls.

It can work in two modes:

by exact target endpoint: targetMethod + targetPath
by natural-language goal: goal

The server analyzes:

auth requirements
path parameter dependencies
request body identifier fields such as categoryId, attributeId, fileId, or parentId
response body outputs such as id, accessToken, or resource-specific identifiers
parent/child path relationships

This makes it possible to suggest chains like:

login → create category → create category attribute → create product
login → create customer → create order
upload file → create entity using returned file id

Persistent cache

Detected specs are cached to disk and keyed by both normalized input URL and specId.

That means search_endpoints and suggest_call_sequence can keep working even after the process restarts, as long as the cached spec is still within the cache TTL.

If needed, you can override the cache directory with the MCP_OPENAPI_DISCOVERY_CACHE_DIR environment variable.

Example tracing queries

Use trace_parameter_usage when you want to follow a field such as userId across the API surface.

Use find_related_endpoints when you already know one endpoint and want to discover nearby or dependent endpoints, such as child resources or endpoints using the same identifiers.

Endpoint execution and authentication

Discovery tools that accept a url also accept an optional auth object. Use this when the docs page or spec URL itself is protected, for example a Laravel Request Docs page behind HTTP Basic auth.

{
  "url": "https://api.example.com/request-docs",
  "auth": {
    "strategy": "basic",
    "username": "demo",
    "password": "super-secret"
  }
}

Discovery auth is sent only to the same origin as the input URL, including common fallback paths such as request-docs/api?openapi=true and same-origin remote $ref files.

The call_endpoint tool can execute actual API calls, not just describe them.

Supported auth strategies:

basic
bearer
apiKey
oauth2-password
oauth2-client-credentials
auto

In auto mode, the tool inspects the endpoint’s effective OpenAPI security requirements and tries to apply the most appropriate authentication strategy from the credentials you provide.

Supported request body styles

JSON
application/x-www-form-urlencoded
simple multipart/form-data
raw string bodies via rawBody

You can also override the outgoing content type explicitly with contentType.

Example `call_endpoint` inputs

JSON body + API key

{
  "url": "https://orders.example.com/openapi.json",
  "method": "POST",
  "path": "/orders",
  "body": {
    "productId": 42,
    "quantity": 3
  },
  "auth": {
    "apiKey": "your-api-key"
  }
}

OAuth password flow

{
  "url": "https://auth.example.com/openapi.json",
  "method": "GET",
  "path": "/me",
  "auth": {
    "username": "demo",
    "password": "super-secret",
    "clientId": "client",
    "clientSecret": "client-secret",
    "scopes": ["profile"]
  }
}

Path params + query params

{
  "url": "https://api.example.com/openapi.json",
  "method": "GET",
  "path": "/users/{id}",
  "pathParams": {
    "id": 123
  },
  "query": {
    "include": ["roles", "permissions"]
  }
}

Direct bearer token

{
  "url": "https://api.example.com/openapi.json",
  "method": "GET",
  "path": "/profile",
  "auth": {
    "strategy": "bearer",
    "token": "your-access-token"
  }
}

Validation

Run the full verification suite with:

npm run check

This runs:

the TypeScript build
the Vitest test suite

Development notes

Runtime: Node.js 18+
MCP SDK: @modelcontextprotocol/sdk v1
Spec parsing: JSON / YAML + HTML discovery heuristics + bundled external $ref support
Cache: in-memory + disk-backed spec cache keyed by URL and specId
Workflow planning: dependency inference across auth, path params, request body ids, and response outputs
Request execution: real HTTP requests with automatic auth handling
Test runner: vitest

Security notes

Do not commit real credentials, client secrets, or access tokens.
Prefer environment-specific client configuration over hardcoded secrets.
Be careful when using this against production APIs.
Review OpenAPI specs from untrusted sources carefully, especially when authentication and live request execution are involved.

Contributing

Issues and pull requests are welcome.

If you want to contribute:

fork the repository
create a feature branch
run npm run check
open a pull request with a clear description

Roadmap

broader Swagger UI / Scalar detection patterns
richer Laravel-specific API summaries
optional Streamable HTTP transport support

License

MIT

Available Tools

8 tools

call_endpointB

Call an endpoint discovered from the OpenAPI document, optionally applying auth automatically and sending query, path, headers, and payload data.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`method`	Yes	HTTP method
`path`	Yes	Exact OpenAPI path, e.g. /users/{id}
`pathParams`	No	Path template values, e.g. {"id":"42"}
`query`	No	Query string parameters as an object or raw string, e.g. {"page":2} or "page=2&sort=name"
`headers`	No	Additional request headers
`body`	No	Request payload for JSON, form, or multipart requests
`rawBody`	No	Raw string body to send as-is
`contentType`	No	Override request content-type
`timeoutMs`	No	Request timeout in milliseconds
`auth`	No	Authentication configuration

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions optional auth but fails to disclose error handling, idempotency, or mutual exclusivity of body and rawBody. The description is too brief for a tool with 11 parameters.

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

Conciseness4/5

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

The description is a single sentence of 25 words, which is concise and front-loaded. However, it could benefit from a brief second sentence about auth usage or parameter relationships.

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

Completeness2/5

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

Despite the complex input schema with 11 parameters, nested objects, and no output schema, the description is minimal. It doesn't explain that the url can be a docs page, that body and rawBody are alternatives, or that path params are required. The description is incomplete for the tool's complexity.

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?

All parameters have schema descriptions covering 100%, so the baseline is 3. The description adds value by mentioning automatic auth, but overall it does not significantly enhance the schema's clarity.

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 clearly states the tool's action: calling an endpoint from an OpenAPI document. It includes key features like automatic auth and data sending. It distinguishes from sibling tools that deal with detection and listing, not actual calling.

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

Usage Guidelines3/5

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

Usage is implied: you call an endpoint after discovery. No explicit when-to-use or when-not-to-use. No alternatives are mentioned. The description assumes the agent knows this is the main execution tool.

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

detect_openapiB

Given a docs or API URL, detect the OpenAPI/Swagger document behind it and summarize the API structure.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`auth`	No	Authentication for protected docs or OpenAPI documents

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool fetches the document, how detection works, what happens with invalid URLs, or any side effects. The description adds little beyond the purpose.

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 a single sentence that is front-loaded with the core purpose. It is concise and contains no unnecessary words or information.

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

Completeness3/5

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

Given the tool has 2 parameters and no output schema, the description is adequate but minimal. It does not describe return values, error behavior, or edge cases, but it conveys the essential function. It is complete enough for a simple tool but could be improved.

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%, with clear descriptions for 'url' and 'auth' parameters. The tool description does not add additional semantic context beyond what the schema already provides, so a baseline score 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 clearly states the tool's purpose: detect an OpenAPI/Swagger document from a URL and summarize the API structure. It uses a specific verb (detect) and resource (OpenAPI document), and distinguishes from siblings like call_endpoint or list_endpoints.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no when-not-to-use conditions, and no mention of prerequisites or limitations. It only describes what the tool does.

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

find_related_endpointsB

Find endpoints that are structurally related to a source endpoint based on shared resource paths, identifiers, tags, and parent/child URL patterns.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`auth`	No	Authentication for protected docs or OpenAPI documents
`method`	Yes	Source endpoint HTTP method
`path`	Yes	Source endpoint path, e.g. /users/{id}
`limit`	No	Maximum number of related endpoints to return

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only describes the input and criteria, but omits any indication of side effects (none expected), performance, or whether it's a read-only operation. The agent lacks insight into the tool's safety or cost.

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

Conciseness4/5

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose. No wasted words. However, it could be slightly more structured by separating criteria, but overall it's concise and clear.

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

Completeness2/5

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

Given no output schema, the description should explain the return value (e.g., list of endpoints, their structure). It does not. The tool has five parameters including a nested auth object, and the description only briefly mentions the criteria. The agent lacks information about output format and missing details like whether the source endpoint is included.

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%, so each parameter has a description. The description adds context about the algorithm (e.g., 'parent/child URL patterns'), but does not significantly enhance parameter understanding beyond the schema. 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 clearly states the tool's function: finding structurally related endpoints based on specific criteria like shared resource paths, identifiers, tags, and URL patterns. This distinguishes it from sibling tools like search_endpoints (keyword search) and get_endpoint_details (specific endpoint info).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, when not to use it, or compare with sibling tools like search_endpoints or list_endpoints. The agent must infer usage from the criteria mentioned.

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

get_endpoint_detailsC

Return request/response details for a specific endpoint in the discovered OpenAPI document.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`auth`	No	Authentication for protected docs or OpenAPI documents
`method`	Yes	HTTP method
`path`	Yes	Exact OpenAPI path, e.g. /api/users/{id}

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral traits. It only states the purpose and does not disclose whether the tool is read-only, requires authentication, or any other behavioral characteristics.

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 a single sentence that immediately states the action and output. It is concise, front-loaded, and contains no superfluous information.

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

Completeness2/5

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

Given the complexity (4 parameters including a nested auth object) and no output schema, the description is insufficient. It does not explain what 'details' includes, how authentication for protected docs works, or the required combination of parameters.

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?

The input schema has 100% description coverage, so the schema itself documents parameters. The tool description does not add additional meaning beyond what is already in the schema, resulting in a baseline score of 3.

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

Purpose4/5

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

The description clearly states the tool returns request/response details for a specific endpoint. However, it does not differentiate from sibling tools like find_related_endpoints or trace_parameter_usage, which could be more specific about endpoint details.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as list_endpoints or search_endpoints. No usage context or conditions are mentioned.

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

list_endpointsA

List endpoints from a discovered OpenAPI document with optional filtering by tag, method, or path fragment.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`auth`	No	Authentication for protected docs or OpenAPI documents
`tag`	No	Optional tag filter, e.g. users
`method`	No	Optional HTTP method filter
`pathContains`	No	Optional path or summary substring filter
`includeDeprecated`	No	Include deprecated endpoints; defaults to true
`limit`	No	Maximum endpoint count to return; defaults to 50

TDQS

A3.7/5.0

Behavior4/5

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

The description implies a read-only operation (listing), which is accurate. However, since no annotations are provided, the description carries the full burden. It could explicitly state that the tool does not modify any resources or require special authentication beyond what is already specified in the auth parameter.

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

Conciseness4/5

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

Single sentence that front-loads the main action and optional filters. No wasted words, but could benefit from a brief note on default behavior (e.g., includeDeprecated defaults to true).

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

Completeness2/5

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

Given the absence of an output schema, the description should hint at what the response contains (e.g., list of endpoint objects). It also omits details about pagination (limit parameter) and the fact that includeDeprecated defaults to true. For a tool with 7 parameters and complex nested objects (auth), this is insufficient.

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 coverage is 100%, so the baseline is 3. The description adds no new parameter meaning beyond stating that there is optional filtering by tag, method, or path fragment, which is already evident from the schema parameter descriptions.

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 clearly states the action (List endpoints), the resource (discovered OpenAPI document), and the optional filtering capabilities (tag, method, path fragment). It distinguishes itself from sibling tools like call_endpoint, which actually invokes endpoints.

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

Usage Guidelines3/5

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

The description implies the tool is for listing/browsing endpoints, but does not explicitly state when to use this versus other listing tools like search_endpoints or find_related_endpoints. No exclusions or context about prerequisites (e.g., requiring a prior detect_openapi call).

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

search_endpointsB

Search cached endpoints for a previously detected OpenAPI spec using a server-side semantic-style scorer over endpoint metadata and schema field names.

ParametersJSON Schema

Name	Required	Description
`specId`	Yes	Spec ID returned by detect_openapi
`query`	Yes	Natural-language or keyword query, e.g. create user email
`tag`	No	Optional tag filter, e.g. users
`method`	No	Optional HTTP method filter
`includeDeprecated`	No	Include deprecated endpoints; defaults to true
`limit`	No	Maximum number of search results to return; defaults to 10

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions 'server-side semantic-style scorer' but does not specify whether the search is destructive, any authentication requirements, rate limits, or side effects. The description is insufficient for safe invocation.

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

Conciseness4/5

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

The description is a single sentence that is relatively compact and front-loaded with the key action. However, it could be broken into multiple sentences for better readability without losing precision.

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

Completeness2/5

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

The tool has 6 parameters, 2 required, and no output schema. The description does not explain the return format, sorting, pagination, or how the scoring works. It is incomplete for an AI agent to fully understand expected behavior.

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?

Input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides; it does not explain parameter semantics or constraints.

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 clearly states the verb 'search', the resource 'cached endpoints', and the context 'previously detected OpenAPI spec' with a specific method 'semantic-style scorer over endpoint metadata and schema field names'. It distinguishes itself from siblings like list_endpoints (listing all) and find_related_endpoints (related endpoints).

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

Usage Guidelines3/5

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

The description implies usage for searching within a previously detected spec but does not explicitly state when to use this over alternatives or when not to use it. No exclusion criteria or alternative tool references are provided.

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

suggest_call_sequenceA

Suggest a likely API call sequence for reaching a target endpoint or accomplishing a goal, such as creating prerequisites before creating a dependent resource.

ParametersJSON Schema

Name	Required	Description
`specId`	Yes	Spec ID returned by detect_openapi
`goal`	No	Optional natural-language goal, e.g. create product with category and attributes
`targetMethod`	No	Exact target HTTP method when planning from a known endpoint
`targetPath`	No	Exact target OpenAPI path when planning from a known endpoint
`limit`	No	Maximum number of workflow suggestions to return; defaults to 3
`maxDepth`	No	Maximum dependency depth to explore; defaults to 5

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It mentions 'likely' sequence, implying non-determinism, but lacks details on side effects, required permissions, or how the suggestion is generated. Adequate but minimal.

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

Conciseness4/5

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

Single sentence, no redundant phrasing. Front-loaded with key action and resource. Very concise, though could benefit from slight expansion for clarity.

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

Completeness2/5

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

Given no output schema and six parameters, the description is too brief. It does not explain the return format, how dependencies are explored, or limitations. For a tool that plans call sequences, more context is needed.

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%, so description adds no extra parameter meaning beyond listing an example usage scenario. Baseline score 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?

Description clearly states verb 'suggest' and resource 'API call sequence' for reaching a target endpoint or accomplishing a goal. It distinguishes from sibling tools like call_endpoint by focusing on planning rather than execution.

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

Usage Guidelines3/5

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

Provides an example of when to use (e.g., creating prerequisites), but does not explicitly state when not to use or mention alternatives like call_endpoint for single requests. Usage is implied but not fully guided.

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

trace_parameter_usageB

Trace where a parameter or field such as userId is used across path parameters, query parameters, request bodies, and response bodies.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Docs page URL or direct OpenAPI JSON/YAML URL
`auth`	No	Authentication for protected docs or OpenAPI documents
`parameterName`	Yes	Parameter or field name to trace, e.g. userId
`entityName`	No	Optional entity hint, e.g. user
`method`	No	Optional method filter
`path`	No	Optional exact path filter
`includeRequestBodies`	No	Include request body field matching; defaults to true
`includeResponseBodies`	No	Include response body field matching; defaults to true
`limit`	No	Maximum number of matches to return

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description alone must define behavior. It discloses that the tool traces across specified locations, but omits critical details such as whether it makes network requests, requires authentication, has rate limits, or can be slow. The behavior is only partially transparent.

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 a single, clear sentence that efficiently conveys the tool's core function without verbosity. Every word adds value, and the structure is front-loaded with the key action.

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

Completeness2/5

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

Despite high schema coverage, the tool has 9 parameters including nested objects and no output schema. The description is too brief given this complexity; it lacks details on output format, side effects, error handling, and performance implications, making it incomplete for an agent to use confidently.

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 coverage is 100%, so the schema already describes all 9 parameters thoroughly. The description does not add additional meaning beyond the schema, meeting the baseline of 3.

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 clearly states the tool's purpose: tracing where a parameter or field is used across various API spec locations (path, query, request/response bodies). It uses a specific verb ('trace') and resource ('parameter or field'), and distinguishes from sibling tools that focus on endpoints or calls.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool vs. alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support for tool selection.

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.

6 tool updatesv0.5.0May 20, 2026

Changedcall_endpoint1 field changed

addedInput schema / properties / auth / properties / headers

Added value: +{
+  "additionalProperties": {},
+  "description": "Extra headers to send while fetching protected docs/specs",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

Changeddetect_openapi1 field changed

addedInput schema / properties / auth

Added value: +{
+  "description": "Authentication for protected docs or OpenAPI documents",
+  "properties": {
+    "apiKey": {
+      "description": "API key value",
+      "type": "string"
+    },
+    "apiKeyName": {
+      "description": "API key header name; defaults to X-API-Key",
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {},
+      "description": "Extra headers to send while fetching protected docs/specs",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "password": {
+      "description": "Password for Basic auth",
+      "type": "string"
+    },
+    "strategy": {
+      "description": "How auth should be applied while fetching docs/specs",
+      "enum": [
+        "auto",
+        "none",
+        "basic",
+        "bearer",
+        "apiKey"
+      ],
+      "type": "string"
+    },
+    "token": {
+      "description": "Bearer token",
+      "type": "string"
+    },
+    "username": {
+      "description": "Username for Basic auth",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedfind_related_endpoints1 field changed

addedInput schema / properties / auth

Added value: +{
+  "description": "Authentication for protected docs or OpenAPI documents",
+  "properties": {
+    "apiKey": {
+      "description": "API key value",
+      "type": "string"
+    },
+    "apiKeyName": {
+      "description": "API key header name; defaults to X-API-Key",
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {},
+      "description": "Extra headers to send while fetching protected docs/specs",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "password": {
+      "description": "Password for Basic auth",
+      "type": "string"
+    },
+    "strategy": {
+      "description": "How auth should be applied while fetching docs/specs",
+      "enum": [
+        "auto",
+        "none",
+        "basic",
+        "bearer",
+        "apiKey"
+      ],
+      "type": "string"
+    },
+    "token": {
+      "description": "Bearer token",
+      "type": "string"
+    },
+    "username": {
+      "description": "Username for Basic auth",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedget_endpoint_details1 field changed

addedInput schema / properties / auth

Added value: +{
+  "description": "Authentication for protected docs or OpenAPI documents",
+  "properties": {
+    "apiKey": {
+      "description": "API key value",
+      "type": "string"
+    },
+    "apiKeyName": {
+      "description": "API key header name; defaults to X-API-Key",
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {},
+      "description": "Extra headers to send while fetching protected docs/specs",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "password": {
+      "description": "Password for Basic auth",
+      "type": "string"
+    },
+    "strategy": {
+      "description": "How auth should be applied while fetching docs/specs",
+      "enum": [
+        "auto",
+        "none",
+        "basic",
+        "bearer",
+        "apiKey"
+      ],
+      "type": "string"
+    },
+    "token": {
+      "description": "Bearer token",
+      "type": "string"
+    },
+    "username": {
+      "description": "Username for Basic auth",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedlist_endpoints1 field changed

addedInput schema / properties / auth

Added value: +{
+  "description": "Authentication for protected docs or OpenAPI documents",
+  "properties": {
+    "apiKey": {
+      "description": "API key value",
+      "type": "string"
+    },
+    "apiKeyName": {
+      "description": "API key header name; defaults to X-API-Key",
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {},
+      "description": "Extra headers to send while fetching protected docs/specs",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "password": {
+      "description": "Password for Basic auth",
+      "type": "string"
+    },
+    "strategy": {
+      "description": "How auth should be applied while fetching docs/specs",
+      "enum": [
+        "auto",
+        "none",
+        "basic",
+        "bearer",
+        "apiKey"
+      ],
+      "type": "string"
+    },
+    "token": {
+      "description": "Bearer token",
+      "type": "string"
+    },
+    "username": {
+      "description": "Username for Basic auth",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedtrace_parameter_usage1 field changed

addedInput schema / properties / auth

Added value: +{
+  "description": "Authentication for protected docs or OpenAPI documents",
+  "properties": {
+    "apiKey": {
+      "description": "API key value",
+      "type": "string"
+    },
+    "apiKeyName": {
+      "description": "API key header name; defaults to X-API-Key",
+      "type": "string"
+    },
+    "headers": {
+      "additionalProperties": {},
+      "description": "Extra headers to send while fetching protected docs/specs",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "password": {
+      "description": "Password for Basic auth",
+      "type": "string"
+    },
+    "strategy": {
+      "description": "How auth should be applied while fetching docs/specs",
+      "enum": [
+        "auto",
+        "none",
+        "basic",
+        "bearer",
+        "apiKey"
+      ],
+      "type": "string"
+    },
+    "token": {
+      "description": "Bearer token",
+      "type": "string"
+    },
+    "username": {
+      "description": "Username for Basic auth",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

8 tool updatesv0.4.0May 5, 2026
- Addedcall_endpoint
- Addeddetect_openapi
- Addedfind_related_endpoints
- Addedget_endpoint_details
- Addedlist_endpoints
- Addedsearch_endpoints
- Addedsuggest_call_sequence
- Addedtrace_parameter_usage

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, though search_endpoints and list_endpoints could be confused due to both listing endpoints; however, their descriptions differentiate search vs. filtering.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., call_endpoint, detect_openapi), making them predictable and easy to distinguish.

Tool Count5/5

8 tools is well within the optimal range (3-15) and covers the core workflow of OpenAPI discovery and interaction without being excessive.

Completeness5/5

The tool set fully covers the lifecycle: detect, list, get details, call, and includes advanced features like semantic search, relationship discovery, sequencing, and parameter tracing.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

OneOAuth
ai.withone
Search, document and execute authenticated API calls across 700+ apps via one MCP server
API Testing App Automation
110
Keploy A
io.github.keploy
End-to-end API testing — generate and run tests from OpenAPI, curl, Postman, or real user traffic.
API Testing Testing & QA Tools Developer Tools
7217,094
mcp-serverOAuth
com.httpstatus
AI-callable tools for API mocking, testing, monitoring, security, and automation.
API Testing Testing & QA Tools App Automation
2
Orbit A
ai.buildwithorbit
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Developer Tools API Testing
21

Related MCP Servers

OpenAPI Search MCP Server
API Testing Documentation Access
Sheepion
F
license
Not graded
quality
D
maintenance
Enables AI assistants to load, parse, and query OpenAPI/Swagger documentation from URLs with intelligent search across endpoints, schemas, and authentication methods. Provides 10 specialized tools for comprehensive API exploration including path details, operation lookups, and multi-criteria search capabilities.
Updated a year ago (2025-10-16 06:40 UTC)
4
-
swagger-doc-explorer-mcp
Documentation Access Developer Tools
anuoua
A
license
A
quality
B
maintenance
Enables progressive exploration of Swagger/OpenAPI API documentation. Supports loading multiple specs, browsing endpoints and schemas, and searching across documentation.
Updated 3 months ago (2026-06-18 05:20 UTC)
12
13
1
MIT
mcp-swagger-reader
API Testing Documentation Access Code Analysis
momei-LJM
F
license
A
quality
D
maintenance
Enables reading and parsing Swagger/OpenAPI specifications to list API endpoints, get detailed endpoint info, search APIs, and generate TypeScript types for request/response.
Updated 6 months ago (2026-03-05 03:25 UTC)
9
-
Swagger MCP
API Testing Documentation Access
yangyaofei
A
license
Not graded
quality
D
maintenance
Loads and queries OpenAPI/Swagger documents, providing tools to list APIs, get details, search endpoints, and manage schemas for efficient API exploration.
Updated a year ago (2025-07-11 17:38 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Rekl0w/mcp-openapi-discovery'

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

@rekl0w/mcp-openapi-discovery

Why this project exists

Features

Available MCP tools

Requirements

Installation

Running locally

Connecting from an MCP client

Auto-install from npm with npx

VS Code (.vscode/mcp.json)

Cursor-style MCP config

Local build instead of npm

Claude Desktop example (Windows)

Example use cases

Structured tracing

specId + search_endpoints flow

suggest_call_sequence flow

Persistent cache

Example tracing queries

Endpoint execution and authentication

Supported request body styles

Example call_endpoint inputs

JSON body + API key

OAuth password flow

Path params + query params

Direct bearer token

Validation

Development notes

Security notes

Contributing

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Auto-install from npm with `npx`

VS Code (`.vscode/mcp.json`)

`specId` + `search_endpoints` flow

`suggest_call_sequence` flow

Example `call_endpoint` inputs