get_decision_full_text

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

No annotations are provided, so the description carries the full burden; "verbatim text" implies a read, but nothing states that it is non-mutating, whether the call can be slow or rate-limited in live mode, or what happens when the documentId is unknown. The embedded example at least shows the sourceMode value in use, which is more than nothing.

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 short sentences: purpose first, routing second, concrete example last. Given the zero schema coverage, the example payload earns its place by showing shape and an enum value in a single line; nothing is redundant.

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 two-param, no-annotation, no-output-schema tool, the definition covers purpose, ID provenance, and an example. It omits what the returned "full text" looks like (size, format, truncation), the sourceMode semantics, and failure behavior for a bad documentId — gaps an agent will hit on first call.

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. It does well on documentId (origin from search_health_precedents or verifiedHighCourtPrecedents), but sourceMode appears only as the literal "live" in the example — the meaning and consequences of mock/live/snapshot are never explained, leaving half the parameters undocumented.

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 ("Fetch the full verbatim text of a single court decision") and pins the key ("by its documentId"), which is exactly what distinguishes it from the search/filter siblings. It also tells the agent where documentIds come from, so the tool is unambiguous at selection time.

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 scopes usage: "Use for deep-dive into one decision instead of re-running the whole pack," which is a real when-to-use plus a when-not-to-use (don't re-run the pack). It stops short of naming the other candidates (drill_down_pack_item, filter_reasoned_precedents) that could also serve a deep-dive, so the routing is clear but not exhaustive.

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