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

With no annotations provided, the description carries the full burden. It discloses key behavior: the output is the full verbatim section in markdown, and the exact provenance and format of the required id. It also flags `effort` as an internal diagnostics tag that clients should leave unset, which is valuable beyond the schema. It does not mention side effects or permissions, but for a 'get/expand' tool used after a search, these are largely covered by the verb and context.

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 compact and well-structured: a one-line purpose statement followed by a bullet-style Args list. Every sentence adds necessary information—purpose, parameter meaning, and client guidance—with no redundancy or filler. The most important usage constraint is front-loaded.

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 simplicity (2 params, 1 required, output schema present), the description covers the core aspects: what it does, how to construct the argument, and which parameter to ignore. The output schema can handle return-value details. A minor gap is the absence of explicit guidance on error behavior or invalid ids, but this does not impede correct invocation for the intended workflow.

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 0%, so the description must compensate fully. It does: `result_id` is precisely defined as the token from a search_docs hit's `_ref:` line, with a concrete example and instruction to pass it exactly. `effort` is explained as an internal diagnostics tag and explicitly instructed to be left unset. This provides far more semantic meaning than the bare schema's `type: string` and `default: null`.

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 opens with a precise verb and resource: 'Expand a previous search hit to its full verbatim section (markdown).' This clearly distinguishes get_context from siblings search_docs (which finds hits) and request_document (which likely fetches whole documents), while the reference to 'previous search hit' anchors its specific niche without ambiguity.

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?

It gives explicit context for when to use the tool: it follows a search_docs hit and uses the `_ref:` id from that hit. This implies the workflow and ties directly to the named sibling search_docs. It does not explicitly list exclusions (e.g., when not to use), but the dependency on a prior search hit is a clear and sufficient usage guideline.

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