api-to-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| API_TO_MCP_HOME | No | Your own workspace (default): API_TO_MCP_HOME, else $XDG_DATA_HOME/api-to-mcp, else ~/.local/share/api-to-mcp. Nothing else is needed: the vocabularies, the lint and the runtime are installed with api-to-mcp. | |
| API_TO_MCP_CHECKOUT | No | Optional: a runtime checkout. API_TO_MCP_CHECKOUT=<checkout of the runtime's repository> (or --checkout <dir>) saves entries into that checkout's catalog, writes its registry metadata and runs its contract tests, for contributing an entry upstream. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| doctorA | Preflight: the workspace (your own directory, or a platform-mcp checkout when contributing), the Python gate dependencies (platform-mcp-hub, pytest, respx, ...), uv, node (>= 20) and npm, and whether platform-mcp-hub's TypeScript runtime is available. Each failed check carries the exact install command for this OS. |
| catalog_searchA | Find entries by id, label, category, country, docs URL or API host (substring, case-insensitive): your workspace's entries and, in your own workspace, the entries bundled with the runtime ( |
| catalog_getB | The full JSON of one entry: the workspace's copy, else (in your own workspace) platform-mcp-hub's. |
| template_entryA | The template for an entry. Default 'generic': tools straight from the API's own operations (any API), with a skeleton, an example and the adapter contract. A category name (jobs, trading, ...) gives that category's verb vocabulary with input/output schemas, a skeleton and an example from a live-verified entry, for contributing to a shared catalog. |
| ingest_openapiA | Summarise API documentation given as a URL, a local file path or text: OpenAPI 3.x / Swagger 2 (JSON or YAML, multi-file specs with external $refs fetched), Postman collections (v2.x) and environments, API Blueprint (text or an Apiary-hosted page), RAML, WSDL (SOAP), a GraphQL endpoint (introspection) or saved introspection result, RSS/Atom/XML answers. Returns servers, security, and an operation list: method, path, parameters with location/type/enum/default, request body keys, the 200 response shape (which path holds the list, record keys, nested objects, maps keyed by id) with the documented example, paging parameters and rate limits. A spec over 60 operations without |
| read_docsA | Fetch one API documentation page (HTML, markdown or text) and return its readable text in windows ( |
| draft_entryA | Draft a generic entry (tools straight from the API's own operations: name, description, input schema from the parameters and body, the HTTP mapping, the docs link) from an OpenAPI 3 / Swagger 2 description (URL, file path or text; same guards as ingest_openapi). No category vocabulary: the answer is passed through as |
| save_entryA | Write or update catalog//.json in the workspace (your own directory, or the platform-mcp checkout when contributing). Existing fields are kept unless the entry replaces them. Refuses unknown categories, |
| lint_entryA | Run the catalog lint (platform-mcp-hub lint) on one entry: vocabulary verbs, expressions naming real inputs, placeholders, auth, evidence (docs, verified_at), live_check/auth_audit blocks, secrets. Returns errors and warnings. |
| generate_serverB | Make a linted entry runnable. Your own workspace: servers///mcp.json (MCP client config that starts |
| test_serverA | Run the gates for one generated entry: the lint, the contract tests that name the platform id (tests/test__python.py, and in a checkout tests/.typescript.test.mjs) and a stdio smoke of |
| try_toolA | Call ONE read tool of a saved entry through the runtime (Python) and show the request it sent (URL, query, body, non-secret headers), the raw response it parsed (structure summary + truncated text) and the mapped result or error. Use it to fix result paths before live_verify: an empty list usually means result.items points at the wrong place or the platform answered another format (the runtime sends Accept: application/json). Never calls write tools. |
| live_verifyB | Start the entry over stdio ( |
| workspaceB | Where entries are saved (your own directory, or a platform-mcp checkout when contributing), and how to change 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 14 tools
Each tool maps to a distinct pipeline stage (preflight, discovery, doc ingestion, drafting, saving, linting, generation, testing, live verification), and descriptions clarify boundaries well. Minor overlap exists between ingest_openapi and draft_entry (both parse OpenAPI) and between try_tool and live_verify (both call real tools), but the debug-vs-full-verification distinction is spelled out.
All names use consistent snake_case, and most follow a verb_noun pattern (save_entry, read_docs, lint_entry, generate_server). A few deviate: catalog_search/catalog_get invert to noun_verb, and doctor/workspace are bare nouns, but everything remains readable and predictable.
14 tools sit comfortably in the well-scoped range and each corresponds to a genuine step in the authoring-to-verification pipeline. No tool appears redundant or filler.
The surface covers a full lifecycle: discover, ingest docs, draft, save, lint, generate, test, and live-verify, which is thorough for building API-to-MCP servers. Minor gaps like a delete/remove-entry operation or explicit category listing are absent but easily worked around.