Connect Claude to Metabase

List the databases this Metabase is connected to, with each one's id, name and engine. Start here: the database id is what run_native_query and get_database_metadata take, and this is the cheapest call that proves the API key works and says what it can see - which is why it is the connection test. Connection details come back with secrets already masked by Metabase, and this connector adds no operation that could unmask them.

Fetch one database's full schema as Metabase understands it: every table, and for each table every field with its type, its semantic type and its display name. This is the map to read before writing SQL for run_native_query, because it names the tables and columns as they actually exist. It can be a very large response on a wide warehouse - pass skip_fields to get tables only, then use get_table_query_metadata for the one table you care about.

List every table Metabase knows about, across all connected databases, with each one's id, name, schema and database. Use it to find a table id for get_table_query_metadata when you do not want to pull a whole database's metadata. On an instance connected to a large warehouse this is a long list, so prefer get_database_metadata with skip_fields when you already know which database you mean.

Fetch one table's fields as they matter for querying: name, base type, semantic type, whether each field is a foreign key and what it points at. This is the precise version of get_database_metadata for a single table, and the right call before writing a join. Fields an admin marked sensitive are withheld unless include_sensitive_fields is set, which is Metabase's own choice about them and is left off by default here.

List the saved questions in this Metabase - what its own API calls cards - with each one's id, name, collection, database and query definition. This is the catalogue of analysis somebody has already written and reviewed, and it is nearly always the better answer than writing new SQL. The id is what get_card and run_card_query take. `f` narrows the list; "mine" is the questions the API key's own user owns, which for a key is rarely what you want.

Fetch one saved question by id, with its full query definition, its visualisation settings, its collection and the parameters it accepts. Read this before run_card_query so you know which parameter ids that question takes and what they mean. Ids come from list_cards or from search.

Run a saved question and return its result rows. This is a genuine read and is classified as one: the statement being executed was written and saved by a person in Metabase, the caller cannot change it, and all this operation supplies is values for the parameters that question already declares. That is the whole difference from run_native_query, which sends SQL a caller wrote and is a write. Reach for this first - a saved question is reviewed, cached and permissioned, and running one avoids writing SQL at all. Get the parameter ids from get_card; each entry needs the `id` of a parameter the card declares plus the `value` to use.

List the dashboards in this Metabase with their ids and names. Metabase itself marks this route as kept only for backwards compatibility and no longer uses it in its own interface, so treat what it returns as a plain list and prefer search with models set to ["dashboard"] when you need collections, ownership or last-edited information alongside the names. Note that `f` here accepts only all, mine or archived - a much smaller set than list_cards takes.

Fetch one dashboard by id, with every card on it, how those cards are laid out, and the filters the dashboard declares. This is how you find which saved questions a dashboard is built from - take their ids and run them with run_card_query. Ids come from list_dashboards or from search.

Search everything in this Metabase by name - questions, dashboards, models, collections, tables and databases - and get back what each hit is, where it lives and its id. This is the fastest way from "the revenue dashboard" to an id, and it is the recommended way to list dashboards with their context. `models` narrows what kinds of thing come back and is repeated once per kind. Metabase pages this route with limit and offset, and defaults to 50 results when either is given.