Create collection row
create_collection_rowCreate one row. data maps field key → value, validated against the schema. Plan-gated.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Site id. | |
| data | Yes | Field key → value. | |
| slug | Yes | Collection slug. |
create_collection_rowCreate one row. data maps field key → value, validated against the schema. Plan-gated.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Site id. | |
| data | Yes | Field key → value. | |
| slug | Yes | Collection slug. |
Changes observed during successful MCP inspections.
Input schema / properties / idAdded value: +{
+ "description": "Site id.",
+ "maxLength": 256,
+ "type": "string"
+}Input schema / properties / site_idRemoved value: -{
- "maxLength": 256,
- "type": "string"
-}Input schema / properties / slug / descriptionAdded value: +"Collection slug."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly=false, destructive=false, and idempotent=false, so the safety profile is partly covered. The description adds meaningful context beyond them: 'validated against the schema' and especially 'Plan-gated,' which signals a non-obvious precondition the annotations don't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight fragments, front-loaded with the core action, and every clause carries information (validation, plan-gating). No filler, though the fragmentary style is terse enough that structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param mutation with a nested object and no output schema, the description covers the essentials and flags plan-gating, but omits what a successful create returns, how validation failures surface, and any required site/collection selection context. Minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters, making the baseline 3. The description restates that `data` maps field key → value and adds the validation note, but adds little syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Create) and resource (one row), which distinguishes it from the bulk sibling create_collection_rows and from update_collection_row. It doesn't name the sibling explicitly, but 'one row' clearly implies singular creation, so it's clear though not fully differentiated in prose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Create one row' versus the plural create_collection_rows sibling, but there's no explicit when-to-use guidance, no prerequisite for selecting a site/collection first, and no routing to alternatives. Adequate but leaves inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.