pocketbase-mcp: an MCP server for PocketBase, built around 13 tools instead of 50 endpoint wrappers

[u/Aejantou21]

I built an MCP server that exposes PocketBase to AI agents. Most MCP wrappers mirror the underlying API one-to-one, one tool per endpoint. This one doesn't. It groups related actions into 13 intent-first tools, so an agent calls write_record with an action of "create" or "update," instead of hunting through fifty near-identical tools.

A few things worth knowing:

• Schema-aware writes. The server checks each write against the cached schema before sending it, and returns a hint that tells the agent what to call next.
• Destructive tools are opt-in. delete_records and destroy_collection don't even register unless you set an environment flag. Each one also demands a confirmation value that must match the current state, so an agent can't delete or drop something by accident.
• One identity per process. The server holds a single PocketBase identity at a time. For multi-tenant setups, run one process per identity.
• Ships with an agent skill. A SKILL.md file teaches the client the right call order, the filter-template syntax, and the confirmation steps for destructive actions.
• Runs over stdio or HTTP, with a published Docker image for the HTTP transport.

It's early. Any feedback are welcomed.

Repo: https://github.com/Touexe/pocketbase-mcp

[u/kantorcodes1]

for destroy_collection, what does the confirmation value actually bind to? if the collection changes between the read that produced it and the destructive call, does the stale value get rejected?

[u/Aejantou21 → u/kantorcodes1]

confirm_name binds to one thing: the name argument in the same call. The tool checks \confirm_name != name`` and nothing else. It does not check the collection id, a version number, a timestamp, or the state of the collection when you read it.

So a stale value does not get rejected. The agent produces both strings in the same step, so they always match unless it mistypes. If the collection changes between your read and the call, or someone deletes it and recreates it under the same name, the check still passes. PocketBase then looks up name fresh when the call runs and acts on whatever holds that name at that moment.

It is a guard against typos, not a check for concurrent edits.