finance_financial_advice_mortgage_finance_au

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description does not contradict them (annotation_contradiction=false). The description adds the routing context — dispatcher under JWT, tenant, and company scope — which is useful but thin. It does not disclose what side effects may occur, whether the action modifies data, or what inputs trigger destructive behavior, leaving the agent without behavioral expectations beyond the annotation flags.

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 text is short, organized with an Args section, and front-loads the action name. However, the brevity reflects under-specification rather than efficient use of space; the routing sentence and parameter glosses are near-repetitions of what the name and schema already imply, so it is concise but not informative.

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 dispatcher tool with 0% schema coverage and no behavior detail, the description is materially incomplete. An agent cannot determine what mortgage finance questions to route here, what structured inputs are expected, what scenarios trigger destructive side effects, or what the output schema returns. The presence of an output schema helps but the input semantics and domain scope remain unexplained.

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 description must compensate fully for parameter meaning. It provides only minimal glosses: 'message: Free-text objective for the action' and 'inputs: Optional JSON string of structured inputs for the action.' This tells the agent message is a free-text objective but gives no syntax, format, structure, or example for the JSON inputs — exactly the compensation needed at 0% coverage is missing.

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 is essentially a tautology: 'Run the finance domain agent action financial_advice_mortgage_finance_au' restates the tool's own name with no explanation of what mortgage finance advice entails. The verb 'run' plus the resource name is vague — it never says what the action does, what questions it answers, or what output it produces. Purpose must be inferred entirely from the name.

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?

There is no guidance on when to use this tool versus the many near-identical siblings (finance_financial_advice_mortgage_finance_ca, finance_financial_advice_life_insurance_au, finance_financial_advice_personal_investments_au, etc.). The description mentions routing through a dispatcher but gives no selection criteria — no exclusions, no alternatives, no context about choosing AU mortgage finance over CA or other advice domains.

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