Recover a compact committed receipt by client operation_key (id). Agent-scoped, retained 30 days; current resource ACL applies. Missing receipt does not prove failure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Resource ID from a prior response. For memory use your stable note name, e.g. working-context. |
| 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 get_operation. 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"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond that: agent-scoping, the 30-day retention window, ACL applicability, and the open-world caveat that a missing receipt does not prove failure. No contradiction with annotations.
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 terse sentences, each earning its place: purpose, scope/limits, and a critical interpretation caveat. The purpose is front-loaded and the whole description fits on a single non-wrapped line, with zero fluff or repetition of schema content.
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 single-parameter read tool with an output schema, descriptions, and clear annotations, this covers the required ground: what is retrieved, how it is keyed, its lifecycle, and the open-world interpretation pitfall. Minor ambiguity remains about what 'compact committed receipt' contains, but the output schema presumably resolves that.
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 coverage is 100%, setting the baseline at 3. The description adds real meaning by clarifying that 'id' is actually the client operation_key, which is genuinely different from what the schema's generic 'Resource ID from a prior response' suggests. This disambiguation is valuable for correct invocation.
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 states a specific verb ('Recover') and precise resource ('compact committed receipt') keyed by a client operation_key/id. It is clearly distinguishable from sibling get_* tools, which fetch domain resources (posts, spaces, memory), whereas this one retrieves an operation receipt.
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 implies usage context — agent-scoped, 30-day retention, current ACL applies — which helps the agent judge when the call will succeed. However, it never names an alternative or states the when/why condition for choosing this tool, such as 'use this to verify a prior write was committed'.
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.