Legacy owner_managed only: replace title/goal/status using the space version. In self_governed use a space proposal; do not retry this direct mutation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Resource ID from a prior response. For memory use your stable note name, e.g. working-context. | |
| data | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | ||
| replayed | No | ||
| operation | No | ||
| truncated | No | ||
| next_cursor | No |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "Structured result for update_space. Resource fields vary by detail, permissions and operation. Paginated results use items/next_cursor; operation-key replays use operation/replayed. Failures have error and the MCP result has isError=true. See get_help for this tool's contract.",
+ "properties": {
+ "error": {
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "help": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "next_action": {
+ "type": "string"
+ },
+ "retry_after_seconds": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "code",
+ "message",
+ "next_action",
+ "help"
+ ],
+ "type": "object"
+ },
+ "next_cursor": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "object"
+ },
+ "replayed": {
+ "type": "boolean"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+}Input schema / properties / data / properties / operation_keyAdded value: +{
+ "description": "Optional stable client key scoped to this agent for 30 days. Reuse identical payload after a timeout. Different payload conflicts. Retry returns compact operation receipt, not original body. Distinct from diagnostic request_id; existing create-space request_id remains required.",
+ "maxLength": 80,
+ "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive behavior, so the description's main job is to add context beyond that. It adds the critical nuance that this is a versioned direct mutation and that retrying it in self_governed spaces is inappropriate. This goes beyond the structured hints and helps the agent anticipate consequences.
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?
The description is two sentences with the most important constraint front-loaded. It contains no filler or restatement of the tool name, and every clause contributes routing or behavior information.
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 destructive mutation tool, the description, annotations, detailed schema, and output schema together give enough guidance for correct invocation. It would be even stronger if it defined how an agent can identify a 'legacy owner_managed' space, but that can likely be inferred from related governance tools.
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?
The description maps the operation to the relevant data fields (title/goal/status) and references the space version, which partially compensates for the schema coverage gap. However, it does not clarify the id or operation_key semantics; those are left to the schema. It adds modest value without fully covering the parameter surface.
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?
The description specifies a concrete action ('replace title/goal/status') on a clear resource (a space) and immediately scopes the tool to 'Legacy owner_managed' spaces. This distinguishes it from related mutations like update_space_entry and from the proposal-based flow used in self_governed spaces.
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?
The description explicitly states when the tool is valid ('Legacy owner_managed only'), names the alternative for self_governed spaces ('use a space proposal'), and adds the exclusion 'do not retry this direct mutation.' This gives an agent actionable routing and failure guidance.
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.