MotherDuck’s agent skills are runbooks—not permission boundaries

MotherDuck’s open-source agent-skills catalog clarifies a distinction that analytics teams can easily blur: teaching an agent how to work is not the same as authorizing it to touch data.

MotherDuck’s April 20 announcement introduced 17 skills for schema exploration, DuckDB SQL, data loading, modeling, dashboards and other analytics workflows. The repository now lists 22, spanning narrow utilities, multi-step workflows and end-to-end use cases.

The format is deliberately lightweight. Each skill is a folder built around a SKILL.md file containing metadata and instructions, with optional scripts, references and assets. An agent initially sees names and descriptions, then loads the full instructions when a task matches. That makes skills suitable for encoding choices such as preferring DuckDB syntax, inspecting a live schema before querying or selecting MCP rather than another connection path.

Guidance does not create access

The repository states the boundary plainly: installing the skills does not configure a MotherDuck connection or MCP server. Live work still requires the official MCP connection or an authenticated database client, and credentials should be supplied through normal secret or environment handling rather than prompts or committed files.

That separation matters because the MotherDuck MCP setup guide exposes capabilities with materially different consequences. The remote server provides a read-only query tool and a read-write query_rw tool. MotherDuck recommends allowing read-only exploration automatically where appropriate while keeping query_rw approval-gated or blocked when write access is unnecessary.

Authentication also changes attribution. The guide says OAuth lets each user connect with an individual MotherDuck account. A shared service-account token makes every end user’s queries appear as actions by that service account, not by the initiating Microsoft 365 user. The documentation recommends OAuth when per-user attribution is required and suggests a dedicated service account plus a read-scaling token for shared read-only access.

Review two artifacts separately

Teams adopting skill catalogs should therefore maintain two reviews.

First, review the instruction artifact like code: version the skill, inspect bundled scripts, verify its dialect and architectural defaults, and test whether its trigger description selects the right workflow. A skill can steer an agent toward safer choices, but its markdown is still guidance the model interprets.

Second, review the authority path independently: which account authenticates, which databases it can reach, which MCP tools are enabled, which actions require approval and whose identity appears in the audit trail. Those controls determine what the agent can actually do even if its instructions are wrong or ignored.

MotherDuck’s own materials make the division useful: skills supply workflows and domain knowledge; MCP supplies live tools. Pairing them can improve analytics execution, but neither should be mistaken for the other. The practical rollout order is to constrain credentials and tools first, then add and test the runbook that guides their use.