The split is the whole idea. Rather than wrapping a chosen set of Metabase operations, this makes the specification searchable and then gives you a single generic executor — so any endpoint in the spec is reachable, including the ones a curated wrapper would have skipped. The cost is that you compose the call yourself, which is why get_api_spec returning parameters and schemas matters more here than it would elsewhere. The three specification tools each state that they read the documentation rather than your instance.
A two-layer Metabase server: three tools that read the API specification, and one that calls the API itself.
- The endpoint list from the specification, filterable by category, HTTP method and search text, with page and limit paging
- One endpoint's detail: its parameters, request body and response schemas
- Specification search for when you know the operation you want but not which endpoint performs it
- api_call, which executes any endpoint by method and path, taking pathParams, queryParams, body, headers and a selectors argument
A Metabase instance and an API key for it — api_call authenticates using the METABASE_URL and METABASE_API_KEY environment variables. The three specification tools work against the documentation and need neither.
One command plus a key — npx -y metabase-mcp-server, then supply credentials