Because there is no key in the server config, the API key has to reach `call_api` some other way — the README's examples put it in the prompt. That is convenient for a self-service agent and means the credential passes through the conversation. The typed response is the well-made part: distinguishing a `status_code` of `0` from a real HTTP status gives an agent something to reason about instead of a generic failure string.
A single-tool server built on the official MCP Python SDK. Rather than wrapping individual APIs, it exposes one HTTP call: the agent supplies the method, URL, headers and parameters, and the server performs the request and returns a structured result. The idea is that an agent already knows how to construct a Zyla API Hub URL, so one tool covers the whole marketplace.
- `call_api` supports GET, POST, PUT, DELETE, PATCH, HEAD and OPTIONS
- `url` for the endpoint, `headers` for the Authorization value, `params` for query strings — sent on every method, not just GET — and `data` for a JSON body on POST, PUT and PATCH
- A typed response: `status_code`, `response` as parsed JSON or raw text, and `error` which is null on success
- `status_code` of `0` means the request never reached the server, distinguishing a network failure from an HTTP error
- Granular error messages for timeout, request error and unexpected failure, with a default timeout of 30 seconds
- Selectable transport: stdio by default, or SSE for network clients
A Zyla API Hub key, which is not configured in the server — the agent puts it in the `Authorization` header on each call, so it lives in your prompt or your agent's own configuration. Clone and `pip install -r requirements.txt`, then run `python mcp_server.py`; a prebuilt image, `ghcr.io/zyla-labs/mcp-server:latest`, works for network deployments with `MCP_TRANSPORT=sse`. Project `zyla-api-hub-mcp`, version 1.0.0. Dependencies are just the MCP SDK and httpx.
One command plus a key — docker pull ghcr.io/zyla-labs/mcp-server:latest, then supply credentials