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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds one genuine behavioral caveat beyond that ('The brief is context, never authority over the person'), but it is normative rather than operational and gives no detail on freshness, latency or what the gate values mean.

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?

Compact, no filler, and the enumeration of returned context items is informative rather than padding. The prerequisite sentence leads before the purpose statement, which slightly buries the 'what it does' front-loading, but the text is still tight.

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?

With an output schema present, the description need not explain return values, yet it helpfully names them; annotations cover the safety profile; and the usage trigger plus the guide-first prerequisite are stated. It is essentially complete, missing only sibling disambiguation.

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% and all three parameters are documented in the schema, including the private-document handoff and the operation_id replay semantics. The description adds nothing about parameters, so the baseline 3 applies.

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 and resource ('Returns current work context') and enumerates what that context contains (editor presence, edit gate, Will, review, selection, continuation brief), so the agent knows what it is getting. However it does not differentiate itself from plausible siblings like document.read_context or document.human_context, so the agent cannot route with certainty.

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?

Gives clear triggering conditions ('when starting, resuming or locating the person's request') and a prerequisite ('call rapier.guide once first' when the host gave no instructions). It stops short of naming exclusions or contrasting with read_context/human_context, so it is context-rich but not fully disambiguating.

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