The valuable half is what the Metabase UI makes tedious: template-tags on a native query, filter parameters on a dashboard, and the mapping between the two, all reachable through get_card, update_card and update_dashboard_cards. The other half is administration — users, groups, the permissions graph — which puts real authority behind a username and password. Deletes lean toward archiving by default, with hard_delete the flag you have to set on purpose.
A server over a Metabase instance's API covering questions, dashboards, collections, permission groups and users in 33 tools.
- Cards read, run and rewritten — get_card returns the dataset_query including the template-tags that define each variable, and update_card writes them back
- Raw SQL against any Metabase-registered database through execute_query, with native_parameters and a max_rows cap
- Dashboard assembly end to end: create it, place cards at a row and column with a size, add filter parameters, then map those filters onto card variables with update_dashboard_cards
- Collections created, re-parented and permissioned, with the collection permissions graph readable and settable per group
- User administration that mirrors Metabase's own model — create, update, add to and remove from groups, and disable rather than delete
- Archiving as the default retirement path on cards, dashboards and collections, with hard_delete as a separate explicit flag
METABASE_URL, METABASE_USERNAME and METABASE_PASSWORD — a session login rather than a scoped API key, so whatever that account can reach in Metabase is what these tools can reach, including create_user and update_collection_permissions.
Build from source — clone the repository and build it, then point your client at the binary