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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's remaining job is to add context, and it does: the response is the complete record in a single response, not a paginated or summarized view. That is a genuinely useful behavioral guarantee for an agent deciding whether it needs additional calls. It still omits whether a locked case can be exported or any size/permission constraints, despite the sibling unlock_case hinting at such a state.

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 core fact is front-loaded in sentence one, which is good. The second and third sentences, however, are largely rhetorical justification about the privacy policy, with sentence three restating the same point as sentence two (comparing the export against what the policy says is kept). For a one-parameter read, some of this text does not earn its place.

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 no output schema, the description must characterize the return value, and it does so well: the full record as JSON, in one response, explicitly not a summary. What remains missing is operational context an agent would want for a case-scoped tool — required permissions and whether the case must first be unlocked.

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 0% and the description adds no information about case_id beyond the phrase "about a case". The parameter is a single, required, self-descriptively named identifier, so the schema alone is nearly sufficient, but the description does nothing to compensate for the coverage gap (e.g. accepted ID format, whether it must be unlocked).

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 first sentence states a specific verb+resource+format: everything stored about a case, returned as JSON in one response. It implicitly separates itself from a summary-style sibling ("deliberately the whole record rather than a summary"), which is useful for distinguishing it from get_case, though it never names that sibling. An agent can tell what this does without opening the schema.

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?

The description frames a use case (the portable copy the privacy policy offers, for comparison against what is kept), which implies when an agent should reach for this rather than get_case. However, it never explicitly states when to use this versus the siblings get_case/get_case_outputs, nor any precondition such as the case needing to be unlocked. Usage is implied rather than directed.

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