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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. Beyond that, the description adds genuinely new behavioral facts: the status is a closed set of three values, the call never grants authorization, and visibility is scoped to 'only your own holds'. Those are operational constraints an agent cannot derive from the annotations or 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 core purpose and the status values, then the safety/workflow constraint. It is dense but every clause carries operational meaning; the trailing 'Read-only' merely restates the annotation and is the one redundant fragment.

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-parameter status-polling tool with no output schema, the description covers what is returned (the three states), the authorization implications, the visibility scope, and the precise next step in the workflow. Nothing an agent needs in order to call it or interpret the result 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%, and the schema descriptions already explain both hold_id provenance and the optional run context for shared connections, so this is the baseline case. The description reinforces provenance ('that check_premises or verify_premises returned to you') and adds downstream meaning (hold_id is later passed as resumes_hold), but adds no new syntax or format detail beyond the schema.

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?

Description gives a specific verb and resource ('says whether a person has dealt with it yet') plus the exact status vocabulary (open, resolved, withdrawn) and the provenance of the hold_id. It also distinguishes itself from the sibling tools that create holds (check_premises, verify_premises), so an agent can tell which side of the workflow this call sits on.

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?

Explicit when-to-use and when-not-to-act guidance: while the hold is open, 'do not act'; once closed, call check_premises again with resumes_hold set to this hold_id, and act only after verify_premises confirms an allow. It names the alternatives and the exact follow-up parameters, leaving nothing to inference about ordering.

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