pocketbase-mcp

Overview Schema Source Related Servers Discussions Admin

write_record

Idempotent

Create or update a single record in a PocketBase collection by specifying collection, action, and data. Use create for new records or update with record_id to modify existing ones.

Instructions

USE WHEN you need to create or update a single record.

EXAMPLES:

Create: write_record(collection="posts", action="create", data={"title": "Hi", "body": "..."})
Update: write_record(collection="posts", action="update", record_id="abc", data={"title": "New"})

NEXT STEPS: find_records to verify, describe_collection for field names.

Input Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Field values to set. For update, include only fields to change.
`action`	Yes	Whether to create a new record or update an existing one.
`expand`	No	Comma-separated relation fields to expand in the response.
`record_id`	No	Required for action='update'. The id of the record to update.
`collection`	Yes	Collection name or id.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 16, 2026

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide idempotentHint=true, and the description adds the create/update distinction with concrete examples showing how requests are shaped. It does not explain side effects, permissions, or how create remains idempotent, but the annotation covers retry safety, so this is adequate rather than rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized into USE WHEN, EXAMPLES, and NEXT STEPS with no filler. Each section earns its place, and the examples are compact while clearly demonstrating parameter usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema and output schema carry the parameter and return details, while the description supplies the selection condition and useful follow-up steps such as find_records and describe_collection. It could more explicitly point to bulk_write for multi-record writes, but the single-record scope makes this easy to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all parameters with 100% coverage, so the baseline is 3. The examples add value by showing how action, data, collection, and record_id combine, especially clarifying that record_id is used for updates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific trigger and names the exact operation: create or update a single record. This clearly distinguishes the tool from bulk_write, which handles multiple records, so an agent can immediately tell what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description uses 'USE WHEN' to state the condition for calling the tool, and 'single record' implicitly excludes bulk operations. It does not explicitly name bulk_write as the alternative or provide when-not conditions, but the routing context is clear enough for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server