openapi-lookup-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAPI_SPEC_URL | Yes | The location of the OpenAPI/Swagger spec. Can be a URL or a local file path, in YAML or JSON, OpenAPI 3.x or Swagger 2.0. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Looks up endpoints of this project's backend API from its OpenAPI/Swagger spec. Before writing or changing code that calls the API, use get_endpoint to read the exact params, body and responses, search_endpoints when the path is not known, and get_schema to read one data model or find the endpoints that use it. Do not download or read the spec file directly.
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 |
|---|---|
| search_endpointsA | Find API endpoints by keywords, best match first. Looks in the path, method, operation id, summary, tags, description, parameter names, schema names and the property names of request and response bodies. Word forms, camelCase or snake_case identifiers and small typos are understood. Returns one line per endpoint, the 10 most relevant by default. The search matches words, not meanings: if the endpoint you need is not listed, search again with the terms this API uses (the results show its vocabulary) or with a synonym. |
| get_endpointA | Show the auth, parameters, request body and responses of one API endpoint as a compact summary with referenced schemas resolved. The path may be a template (/users/{id}), a concrete path (/users/42) or a full URL. |
| get_schemaA | Show one schema (data model) of the API by name as a compact summary with the schemas it references, followed by the endpoints that use it. Use it to read a model without going through an endpoint, or to find which endpoints accept or return it. |
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 3 tools
Each tool has a clearly distinct role: search finds endpoints, get_endpoint retrieves one endpoint's details, and get_schema retrieves one schema. There is no meaningful overlap between searching, endpoint inspection, and schema inspection.
All three names follow a consistent verb_noun pattern: search_endpoints, get_endpoint, get_schema. The singular/plural distinction is natural and predictable for the resources involved.
Three tools is well-scoped for a focused OpenAPI lookup server. Each tool covers a distinct lookup operation and none feels redundant or extraneous.
The surface covers the core lookup workflow: discover endpoints via search, inspect endpoint details, and inspect schemas. Minor gaps exist, such as no explicit list-all-endpoints or list-all-schemas operation, but search and schema lookups allow agents to work around this.