SpecBridge MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HTTP_HOST | No | HTTP bind host for the MCP server when using HTTP transport. | |
| MCP_HTTP_PATH | No | MCP endpoint path, such as '/mcp', for HTTP transport. | |
| MCP_HTTP_PORT | No | HTTP port for the MCP server when using HTTP transport. | |
| MCP_TRANSPORT | No | Transport mode for the MCP server, either 'stdio' or 'http'. | stdio |
| OPENAPI_BACKENDS | No | JSON array of backend configurations. | |
| DEFAULT_BACKEND_ID | No | Default backend ID; if unset, uses 'swagger-petstore'. | swagger-petstore |
| MCP_HTTP_STATELESS | No | Set to 'true' for stateless HTTP mode. | |
| OPENAPI_CACHE_TTL_MS | No | In-memory spec cache TTL in milliseconds. | |
| OPENAPI_BACKENDS_FILE | No | Path to a backend config JSON file. | |
| OPENAPI_FETCH_TIMEOUT_MS | No | Fetch timeout for spec loading in milliseconds. | |
| OPENAPI_ENABLE_SWAGGER_UI_SCRIPT_EXTRACTION | No | Opt in to strict JSON object extraction from static Swagger UI scripts; fetched JavaScript is never executed. |
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 |
|---|---|
| list_backendsB | List configured backend targets available for OpenAPI tools. |
| load_openapi_specA | Load or refresh OpenAPI spec from a URL. Use this first if tools fail because docs path changed. |
| list_api_endpointsC | List endpoints from the currently loaded OpenAPI document. |
| get_endpoint_contractA | Return full contract for one endpoint: params, request schema, response schema, and referenced DTO names. |
| generate_typescript_dtoB | Generate TypeScript DTO type declarations from OpenAPI components schema. Includes referenced nested DTO types. |
| propose_new_endpointB | Create a best-effort endpoint + DTO proposal aligned with deterministic patterns found in the current OpenAPI spec. |
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 6 tools
Each tool has a clearly distinct purpose with no overlap: generate_typescript_dto creates TypeScript types, get_endpoint_contract retrieves endpoint details, list_api_endpoints lists endpoints, list_backends lists backends, load_openapi_spec loads specs, and propose_new_endpoint proposes new endpoints. The descriptions make it easy to differentiate their functions.
All tools follow a consistent verb_noun pattern using snake_case: generate_typescript_dto, get_endpoint_contract, list_api_endpoints, list_backends, load_openapi_spec, and propose_new_endpoint. This uniformity makes the tool set predictable and easy to navigate.
With 6 tools, the count is well-scoped for an OpenAPI-focused server, covering core operations like loading specs, listing endpoints and backends, generating types, and proposing new endpoints. Each tool earns its place without feeling excessive or insufficient.
The tool set provides strong coverage for OpenAPI workflows, including loading specs, listing endpoints/backends, generating DTOs, and proposing new endpoints. A minor gap exists in lacking direct update or delete operations for endpoints or backends, but agents can work around this given the server's focus on analysis and generation.