HNW Mortgage Qualification (FCA MCOB 3A)

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

Annotations indicate read-only, non-destructive, and idempotent behavior. The description adds significant behavioral context, such as the inclusion of primary residence equity and pension in net assets, the default inclusion of pension, the per-applicant breakdown, and the routing recommendation. No contradiction with annotations.

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 a single, well-structured paragraph. It is concise, with no redundant sentences. Every sentence adds value, covering purpose, criteria, scope, return values, and use cases. It front-loads key information effectively.

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 complexity (nested objects, multiple financial inputs, joint applicant support) and no output schema, the description provides complete context: the test criteria, inclusion of assets, return components (verdict, breakdown, routing), and regulatory authority. It adequately prepares the agent to invoke and interpret results.

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% (all parameters have descriptions). The description adds meaning by explaining the test logic (e.g., includes primary residence equity, pension by default, joint application interpretation). While the schema itself is detailed, the description provides context that enhances understanding, justifying a score above baseline.

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 clearly states the tool's purpose: checking whether a UK mortgage applicant qualifies as a high net worth mortgage customer under FCA MCOB 3A. It specifies the criteria (income ≥GBP 300k OR net assets ≥GBP 3m), the scope (single or joint), and what it returns. It is easily distinguishable from the sibling tool 'uk_stamp_duty_calculator' as a mortgage qualification tool.

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 lists when to use the tool: 'when a user asks whether they qualify for a high net worth mortgage, about MCOB 3A, the GBP 300k income or GBP 3m net assets test, private bank mortgages, or large loans against assets.' This provides clear guidance on use cases, and no exclusions are needed given the distinct sibling tool.

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