unreject_reconciliation_candidate

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

With no annotations available, the description carries the full burden. It discloses key behavioral traits: 'Mutates state', the timing (next read of list_reconciliation_candidates), and the non-effect on model version. It could further disclose error behavior or idempotency, but the core side effects are clearly communicated.

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 well-structured and efficient, starting with the main action, then consequences and usage, and ending with a caveat. No redundant sentences; all information earns 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?

Given the tool's moderate complexity, the description covers purpose, when to use, parameter sourcing, and side effects. It also leverages the output schema so return values need no explanation. It could mention behavior for invalid rejection_id or repeated calls, but the overall context is solid.

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 67% with model_id and rejection_id described, but server_version lacks a description. The description adds value by explaining that rejection_id is a surrogate from rejections[*].id or the return value of reject_reconciliation_candidate, which is meaningful beyond the schema. It does not clarify server_version, leavingsome gap.

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 the specific verb 'Remove' with a clear resource: 'a persisted reconciliation rejection'. It distinguishes itself from siblings like reject_reconciliation_candidate and list_reconciliation_candidates by explaining the effect: making the pair eligible again for the candidate queue.

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 explicitly states when to use this tool: 'Use when the operator changes their mind about a prior rejection'. It also explains where the rejection_id comes from, providing a clear context and differentiating it from other reconciliation tools.

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