OpenAPI MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_KEY | No | API key (when API_AUTH_TYPE=apiKey) | |
| API_BASE_URL | Yes | Base URL of the API (e.g. https://api.example.com) | |
| API_AUTH_TYPE | No | Authentication type: none, apiKey, or bearer | none |
| API_KEY_HEADER | No | Header name for API key | X-API-Key |
| API_TIMEOUT_MS | No | Request timeout in milliseconds | 30000 |
| API_BEARER_TOKEN | No | Bearer token (when API_AUTH_TYPE=bearer) | |
| API_CACHE_TTL_MS | No | OpenAPI spec cache TTL | 3600000 |
| API_OPENAPI_PATH | No | Path to OpenAPI spec | /openapi.yaml |
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_discoverA | List all available API endpoints grouped by domain. Call this first to understand what APIs are available before making requests. Returns method, path, description, and optionally parameters for each endpoint. |
| api_requestA | Make an HTTP request to any API endpoint. Use api_discover first to see available endpoints and their parameters. Supports path parameter substitution (e.g., '/api/servers/{id}' with pathParams: { 'id': '123' }). |
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 2 tools
The two tools have clearly distinct purposes: api_discover is for listing and exploring available API endpoints, while api_request is for executing HTTP requests to those endpoints. There is no overlap in functionality, making it easy for an agent to choose the right tool for each task.
Both tools follow a consistent snake_case naming pattern with a clear 'api_' prefix and descriptive action names (discover and request). This uniformity makes the tool set predictable and easy to understand at a glance.
With only two tools, the server feels under-scoped for an OpenAPI server, which typically involves operations like schema validation, endpoint testing, or parameter management. While the tools cover basic discovery and execution, the count is too low for comprehensive API interaction, limiting functionality.
The tool set is severely incomplete for an OpenAPI domain, lacking essential operations such as schema retrieval, parameter validation, response inspection, or error handling. Agents will face dead ends when needing to perform common API tasks beyond simple listing and requesting, leading to potential failures.