There is no fixed set of capabilities here — what an agent sees is exactly what you put in `config.yaml`, which makes this useful for internal APIs nobody is going to publish a server for. The cost is that quality is on you: an argument with a vague description is a tool the model will call wrongly.
A Python gateway that reads a `config.yaml` and exposes every entry in its `tools` list as an MCP tool. Each entry declares a name, a description and its arguments, a `requestTemplate` that maps the call onto an HTTP request, and a `responseTemplate` that formats the reply.
- Any HTTP endpoint reachable as a tool, with URL, method and headers built from templates that interpolate `{{.args.address}}` and `{{.config.apiKey}}`
- Argument definitions the model sees — name, description, and whether it is required — so a tool is described without writing code
- Response formatting: the raw HTTP body rendered through a template into the text the model reads
- A choice of transport: SSE by default, or `--transport=stdio` for clients that launch the process themselves
No account and no key of its own — credentials for the target API go in the YAML `config` block and are referenced from the templates. Copy `config.example.yaml` to `config.yaml` and map your endpoints. Launch with `uv run mcp-gateway`; SSE listens on 3001 unless `--port=` says otherwise.
Build from source — clone the repository and build it, then point your client at the binary