SKILL.md
REST API Administration
Source Of Truth
- Prefer current MotherDuck REST API documentation, the public OpenAPI spec at
https://api.motherduck.com/docs/specs, or an explicit OpenAPI spec supplied by the user. - For token scope and embed behavior, cross-check the REST API docs and the Embedded Dives docs because they include operational constraints not obvious from the raw schema.
- If the MotherDuck MCP
askdocsquestionfeature is available, use it to check whether public REST API guidance has changed. - Treat endpoint availability, preview status, token fields, and role requirements as current only when backed by the supplied spec or current docs.
Default Posture
- Treat the REST API as the control plane; SQL and data-plane queries go through a database connection, not the REST API.
- Use
https://api.motherduck.comas the base URL unless the user provides another environment. - Authenticate with
Authorization: Bearer ${MOTHERDUCKADMINTOKEN}and keep admin read-write tokens in backend-managed secrets. - Never use read-scaling tokens for REST API administration.
- Prefer read-before-write flows for configuration changes so the current account, service account, Duckling config, or Dive metadata is known before mutation.
- Treat
POST /v1/usersas service-account creation unless current docs explicitly broaden the API. - Assume active-account, Duckling configuration, service-account creation, service-account token creation, and Dive embed-session endpoints require an organization admin bearer token unless current docs say otherwise.
- Never expose generated access tokens in logs, browser code, client bundles, or committed files.
- Confirm destructive deletes with the user. Deleting a user permanently deletes that user and all of their data.
- Treat agent/account signup (
motherduck newor the public signup flow) as separate from the organization Admin REST API. Never create an account because an admin token is unavailable. - For Dive embed sessions, keep
initial_stateJSON-serializable and within the documented size limits; validate iframe state, navigation, and export messages in the host application.
Workflow
- Identify whether the task is service-account provisioning, token management, Duckling sizing, active-account inspection, or Dive embedding.
- Resolve the admin token from the existing environment and identify the target
usernameordive_id; ask only when a required value cannot be discovered, and never invent production identifiers. - Check token scope before calling token endpoints: users can create tokens for themselves, and admins can create tokens for service accounts, but admins cannot create tokens for other non-service-account members through the API.
- For Duckling config changes, read the current config first, then update both
readwriteandreadscalingbecause thePUTpayload requires both. - Preserve response fields that are only returned once, especially newly created token strings and embed session strings.
- Surface API errors by status and response body; do not hide
400,401,403,404, or500responses behind success-shaped fallbacks. - When the MotherDuck MCP server is connected, prefer its admin tools over raw HTTP. Call
getuseradminguidefirst, or read the MCP column inreferences/RESTAPI_GUIDE.md.
For answer, review, or planning requests, inspect and report without mutating the control plane. For create or update requests, perform the requested in-scope operation and verify the response; retain confirmation for destructive deletes or broader administrative changes.
References
Read only the reference sections needed for the current task.
- Read
references/RESTAPIGUIDE.mdfor endpoint summaries, MCP tool mapping, curl examples, validation limits, and operational gotchas.
Related Skills
Load related skills only for missing capabilities; reuse established context.
motherduck-queryfor SQL and data-plane query workmotherduck-connectfor connection tokens and application connection posturemotherduck-security-governancefor admin-token handling, service-account posture, and access-boundary questionsmotherduck-create-divefor designing Dives before minting embed sessions