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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds real value beyond that by enumerating the returned payload in detail (status values pending/closed/under order, timeline entries with filing date, title, PDF URL), which matters because there is no output schema.

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?

Front-loaded with the purpose and return payload, then drops into parameter usage and a concrete example. The long inline list of returnable fields is dense but each item is informative; a touch of trimming is possible but nothing is wasted.

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 one required parameter, no output schema, and annotations covering the safety profile, the description fills the one real gap — what the response contains — and shows exactly how to construct the slug. Nothing an agent needs to call this correctly is missing.

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%, so baseline is 3; the description earns a step up by explaining how to derive the value ("the last path segment of the case's ftc.gov URL") with a concrete worked example and a sample invocation. It duplicates the schema's note that a full URL is also accepted, but the derivation example is genuinely additive.

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?

Opens with a specific verb+resource ("Get full detail for one FTC case or proceeding") and enumerates exactly what comes back: status, court, caption, summary, press release, document timeline. It is clearly the single-case detail counterpart to the sibling list tools ftc_search_cases and ftc_recent_actions.

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 states the slug comes from ftc_search_cases or ftc_recent_actions, which defines the workflow position (search first, then detail). It does not state an explicit when-not or note that this returns one case rather than many, but the source-tool routing removes most ambiguity.

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