finance_reconciliation_exceptions

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

Annotations already carry destructiveHint=true, readOnlyHint=false, and idempotentHint=false, and the description adds useful routing/auth context: execution is scoped by JWT, tenant, and company and goes through the domain-agent dispatcher. It does not describe side effects or what may be modified, but that burden is partially covered by the annotations. No contradiction is present.

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 compact, front-loads the action name, and uses an Args block for parameters. The routing sentence is relevant execution context rather than fluff. It is about as concise as a generic dispatcher description can be, though it is boilerplate-like.

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 zero required parameters and an output schema present, an invocation is technically possible from the description alone. But the missing domain semantics and complete lack of selection guidance make it incomplete relative to the enormous sibling toolset. An agent cannot confidently decide whether this tool, rather than finance_reconciliation_sweep or company_exceptions, is the right one.

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%, so the Args block is the only semantic source. It correctly defines message as a free-text objective and inputs as an optional JSON string, adding meaning beyond the bare titles and defaults. However, it gives no hint of what a valid message should contain or what structured inputs finance_reconciliation_exceptions expects, so it only minimally compensates for the missing schema descriptions.

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 names a specific resource ('finance domain agent action finance_reconciliation_exceptions') and a verb ('Run'), so an agent knows this is an invocation proxy. However, it never explains what the action actually does beyond its name, nor what 'exceptions' means in this reconciliation context. Among the many finance reconciliation siblings, it is indistinguishable without prior knowledge.

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?

No guidance is given on when to choose this tool over finance_reconciliation_sweep, finance_xero_reconciliation_review, company_exceptions, or the generic dispatch_domain_agent sibling. The routing/scoping sentence describes mechanics, not selection criteria. There are no exclusions or alternative conditions.

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