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

Annotations already declare that this is not read-only, is open-world, not idempotent, and not destructive. The description adds useful behavioral context: it targets stuck documents and explicitly excludes failed documents that require re-upload. It does not describe side effects, permissions, or what happens to already-passed checks, so it stops short of full transparency.

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 two focused sentences with no unnecessary wording. The primary condition is front-loaded, and the exclusion follows immediately.

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?

The trigger and exclusion are well covered, which is the core need for this tool. However, the only required parameter is unexplained, and there is no indication of what business_id identifies or what the recheck applies to. For a simple one-parameter tool this is adequate but incomplete.

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 never mentions the required business_id parameter. It also does not clarify whether the tool rechecks all stuck documents for a business or whether there is an implicit document scope, leaving an important ambiguity.

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 uses a specific verb and resource: 'Run the checks again on documents that are stuck.' It also distinguishes the target state from failed documents, though it does not explicitly name which sibling tool handles the new-upload alternative.

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 clear when-to-use conditions with examples ('check service was down', 'NIN slip is waiting on the passport photo') and a clear when-not-to-use case ('Not for a document that failed'). The alternative action is described as 'a new upload' rather than naming a sibling tool, which leaves a small gap.

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