openapi-explorer-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAPI_BASE_URL | No | Base URL for calls. Required whenever any credential or header is configured; otherwise servers[0].url of the spec is used for anonymous calls. | |
| OPENAPI_CALL_LOG | No | Journal of api_request calls. Default: <cache dir>/calls.jsonl. | |
| OPENAPI_ENV_FILE | No | Env file merged into the environment at startup; variables already set win. | |
| OPENAPI_SPEC_URL | Yes | Required. URL or file path of an OpenAPI 3 JSON spec. URLs are cached on disk and revalidated with ETag. | |
| OPENAPI_CACHE_DIR | No | Spec cache and generated types. Default: ~/.cache/openapi-explorer-mcp/<hash of the spec source>. | |
| OPENAPI_SPEC_TTL_S | No | How often a URL spec is revalidated. Default: 900. | 900 |
| OPENAPI_TIMEOUT_MS | No | Timeout of spec fetches and calls. Default: 20000. | 20000 |
| OPENAPI_ALLOW_WRITE | No | Set to 1, true or yes to register the api_request tool. Off by default. | false |
| OPENAPI_AUTH_MODULE | No | Path to an ES module that supplies credentials minted at runtime. | |
| OPENAPI_DANGER_FILE | No | JSON with danger overrides. See the Danger rules section. | |
| OPENAPI_RECIPES_DIR | No | Directory of markdown recipes (with a description: line) served by the recipe tool. | |
| OPENAPI_SERVER_NAME | No | Server name reported to the client. Default: openapi. | openapi |
| OPENAPI_AUTH_<SCHEME> | No | Credential for a security scheme. Replace <SCHEME> with the upper-cased scheme name (e.g., OPENAPI_AUTH_BEARER). See the Authentication section for details. | |
| OPENAPI_HEADER_<NAME> | No | A header sent with every call. Replace <NAME> with the upper-cased header name (e.g., OPENAPI_HEADER_X_API_KEY sends x-api-key). | |
| OPENAPI_INSTRUCTIONS_FILE | No | Markdown appended to the instructions the server gives the model. | |
| OPENAPI_MAX_RESPONSE_CHARS | No | Cap on a tool response. Default: 40000. | 40000 |
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 |
|---|---|
| api_spec_infoB | Spec version and age, counts, groups, security schemes with credential status, and changes since the previous version. |
| api_searchA | Searches method, path, operationId, summary, tags and parameter names. One line per endpoint, no schemas. Admin endpoints come last. Summaries can be wrong — check the path and method. |
| api_endpointB | Parameters, request and response shapes (compact, depth-limited), danger level, security alternatives and URL of one endpoint. |
| api_schemaA | A schema from components by name, compact and depth-limited. |
| api_typesA | Ready-to-paste TypeScript types for the request, response and parameters of an endpoint, generated from the spec with @hey-api/openapi-ts. |
| api_getA | Calls a GET endpoint and returns the response. Read-only: the method is fixed. |
| api_call_logA | What api_request has called: endpoint, status and ids from responses — use it to clean up what was created. |
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 7 tools
Tools are mostly distinct: api_spec_info, api_search, api_endpoint, api_schema, api_types, api_get, and api_call_log each target a different aspect of API exploration. Slight overlap between api_endpoint (details) and api_types (types) but descriptions clarify their purpose. The reference to api_request in api_call_log hints at a missing tool, but the set itself is clear.
Naming follows a consistent 'api_' prefix but the suffix style is mixed: some are nouns (api_spec_info, api_endpoint, api_schema, api_types, api_call_log) while others are verbs (api_search, api_get). This hybrid is readable but not a uniform verb_noun pattern. The inconsistency is mild but noticeable.
With 7 tools, the count is well within the ideal range (3-15). Each tool addresses a distinct need for exploring an OpenAPI spec. However, the mention of api_request in api_call_log suggests there might be an additional tool not listed, which could slightly grow the set but still remain appropriate.
The set covers spec overview, endpoint discovery, detail retrieval, schema inspection, type generation, and safe GET execution. It notably lacks a POST/PUT/PATCH tool for actually creating or modifying resources, only supporting read-only GET. Also, api_call_log implies a separate api_request tool that is missing, leaving a gap between logging and executing non-GET calls.