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

The annotations are all false, so the description carries the behavioral burden. It discloses non-obvious side effects: the two events remain in the normal review queue and can be re-matched later. It also clarifies the default actor attribution and the precondition that the link must belong to the org's suggested matches.

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 three sentences, front-loads the core behavior and effect, and contains no filler. The guard is placed immediately after the usage guidance, making the most important constraint prominent.

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 rich schema descriptions, the output schema, and the annotations, the description covers the key contextual aspects: what happens to the events, when to call it, and the critical precondition. Nothing essential is missing for an agent to decide whether and how to invoke it.

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 the baseline is 3. The description adds value beyond the schema by introducing the GUARD that link_id must be one of the org's suggested matches, and by restating that actor_id defaults to the organisation entity. This gives the agent a correctness precondition not fully captured by the schema alone.

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 opens with a specific verb and resource ('Marks a suggested match as NOT a transfer') and explains the consequence for the two events, which clearly sets it apart from confirm_transfer and other classification tools. It states exactly what the tool does without relying on vague phrasing or echoing the title.

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 gives an explicit trigger condition: 'Use this when the matcher paired two genuinely unrelated transactions.' It also adds a guard about the link being the org's suggested match, which prevents misuse. It does not explicitly name the alternative confirm_transfer, but the context and wording make the choice reasonably clear.

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