Retrieve compact authoritative recovery state for admitted work. Use this context to reconstruct state correctly instead of deriving it from path discovery.
Return compact authoritative recovery state; never derive admitted work state from path discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_root | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds some useful context by labeling the state 'authoritative' and warning against path-derived inference, but it does not disclose side effects, permissions, idempotency, or return behavior. This is too thin to be considered transparent.
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 a single compact sentence with no filler. The primary action is front-loaded, and the behavioral caution is appended without bloating the length.
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?
Although the tool signature is simple and an output schema exists, the description leaves gaps around when to use this tool among many recovery/context siblings and what workspace_root does. The cryptic 'never derive' clause is not enough to make the definition complete for agent selection and invocation.
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 schema description coverage is 0%, and the description does not mention workspace_root at all, nor its role in scoping recovery state. The parameter's name is somewhat self-explanatory, but with such low coverage the description needed to compensate and did not.
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 clear verb and resource: 'Return compact authoritative recovery state.' The additional clause adds precision about what the tool does not do, which helps distinguish it from path-derived state inference. However, it does not explicitly name or differentiate among the many related sibling tools like read_context or session_restore.
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?
There is no explicit when-to-use or when-not-to-use guidance. The warning 'never derive admitted work state from path discovery' is a semantic constraint, not a usage guideline, and no alternatives are mentioned. An agent must infer when recovery_context is preferable to session_restore, workspace_status, or read_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.