context_delivery

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: 'Local disk read with no side effects,' 'Read-only across all three,' and explains that installing hooks and refreshing context are human-only. It also discloses return shape and diagnostic signal: 'A stale or absent revision on one row is the signal to look for.' 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?

The description is dense but every sentence earns its place: purpose, safety, usage guidance, sibling differentiation, parameter explanation, return value, and diagnostic hint. It is front-loaded with 'READ-ONLY' and the core purpose, followed by succinct supporting details.

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?

Given the tool's moderate complexity, the description covers all necessary aspects: purpose, safety, parameter semantics, return format, sibling differentiation, and practical diagnostic guidance. An output schema exists, and the description still summarizes the return value, so the agent has a complete picture without needing to inspect structured fields.

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% and the description repeats the schema's parameter description nearly verbatim ('project_path project root whose memory tree the operation applies to. Omit it to use the machine-wide tree, and always omit it when this server was started pinned to a project.'). It adds no new semantic information beyond what the schema already provides.

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 action and resource: 'show, per agent, whether context is actually reaching it, listing each supported agent's integration mode, hook installation status, and the revision and hash of the last context bundle.' It also distinguishes itself from sibling tools: context_status answers what the current context revision contains and context_projection renders the actual text one agent would receive.

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?

Explicitly says when to use: 'use it to diagnose why one agent seems to be missing context that another has.' It also provides alternatives by naming context_status and context_projection and clarifying they are different questions, plus notes that installing hooks and refreshing context are deliberately human-only operations.

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