Switchboard Finance

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds real behavioral context beyond that: it discloses that responses include documents usually needed, deal-breakers and an expected callback time, and it clarifies the output is general information rather than a credit decision or advice.

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?

Purpose and scope are front-loaded in the first sentence, followed by the category list, the derived-check explanation and a concrete example. It is on the dense side, but each element (categories, example, disclaimer) does useful work, so little is wasted.

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 an output schema present, the description needn't detail return values, and all 10 parameters are schema-documented. It supplies the qualifying context (what triggers a fit, what comes back in general terms, and the advice disclaimer), making it complete enough to invoke correctly, with only the sibling-routing gap remaining.

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, but the description adds meaning by grouping amount, property value, timing and trading history and explaining what they are checked against (loan size, LVR, time to fund), implying how existing_debt and property_value combine. It stops short of fully specifying every parameter's interpretation.

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 states a specific verb (checks) and resource (an Australian business owner's finance need) and spells out the finance categories covered, so an agent immediately knows what this tool qualifies. It also distinguishes itself from siblings like list_products and request_callback by framing itself as a fit-check rather than a lookup or submission.

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?

Usage is strongly implied through the worked example and the mention of returning a callback time, which positions this as a pre-qualification step ahead of request_callback. However, it never explicitly says when to use this versus list_products or search, nor are there stated exclusions, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail beyond that: it returns full text plus the source URL for citation, which tells the agent what it gets back and why (citation), supplementing the annotation set.

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?

Two short sentences, front-loaded with the core purpose and followed by a minimal example. No wasted words or redundancy.

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 an output schema present, the description needn't document return values, and the rich annotations cover behavior. For a trivial one-parameter lookup tool, everything an agent needs to select and call it is present, including the relationship to the search sibling.

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 100% and the single 'id' param is already documented with example values in the schema. The description's inline example {"id":"lane:caveat"} largely repeats that schema content, adding no new format or constraint information. Baseline 3 is appropriate.

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 states a specific verb and resource ('Returns the full text of one Switchboard Finance document') and ties it explicitly to the search workflow, distinguishing it from the sibling 'search' tool which produces the id. An agent can tell exactly what this does without opening the schema.

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?

'found by search' establishes the correct usage context: run search first, then fetch a single result by id. It does not, however, explicitly state when not to use it or name the alternative (search) as a routing option, so the guidance is implied rather than spelled out.

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

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

Annotations already establish read-only, idempotent and non-destructive behavior, so the bar is lower; the description still adds genuine value by disclosing the returned metrics (loan sizes, time to fund, max LVR, rate ranges) and explicitly scoping output to category level with no lender named, plus the effect of passing lane.

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?

Two dense sentences front-load the purpose and the parameter behavior, with the enumeration of criteria and the example earning their space. Slightly heavy on list-like detail, but nothing is wasted.

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 an output schema present, return values need not be documented, and the description still covers scope, the optional-parameter effect, and output granularity. The one gap is the absence of any routing cue to the sibling tools.

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, but the description goes beyond the schema by listing what a passed lane actually unlocks (security, LVR, trading history, ATO position, deal-breakers, documents, pricing, term) and showing a concrete example value.

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 states a specific verb and resource ('Lists the types of business finance Switchboard Finance arranges') and narrows the audience to self-employed Australians and ABN holders, which is far more specific than the tool name alone. It does not, however, contrast itself against siblings like check_fit or search, leaving the agent to infer the boundary.

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?

It gives usage for the optional parameter ('Pass lane for one type's full criteria') and an example payload, which implies the no-arg case lists categories. But it never states when to choose this tool over check_fit, search or fetch, and no exclusions are offered.

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

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

Annotations only cover the safety profile (readOnly false, idempotent true, openWorld true), yet the description adds real behavioral context: the return payload (reference number and expected contact time), the negative guarantees (nothing is applied for, no credit check), and explicit idempotency semantics ('retries with the same idempotency_key return the original reference instead of creating a second enquiry'). That is exactly the kind of detail annotations cannot carry.

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?

Four sentences, front-loaded with what the tool does, then the gating condition, then the return/no-side-effect guarantees, then idempotency. The quoted consent wording is verbose but load-bearing, since it is the exact text the agent must obtain.

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 13-parameter, high-stakes, externally facing submission tool it covers the essentials: consent gating, the collection-notice cross-reference, downstream contact channels, absence of credit checks, return shape and retry behavior. With an output schema present and annotations covering safety, nothing material is left for the agent to guess.

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 92%, so parameters are largely self-documenting and the baseline is 3. The description goes beyond that by embedding the literal consent wording that the consent parameter depends on and by clarifying that idempotency_key exists to collapse retries, adding meaning the schema's terse descriptions only hint at.

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 verb and resource (sends a finance enquiry to a licensed broker) and spells out the downstream effect (broker contacts by phone, SMS and email). Combined with the consent precondition, it is clearly the terminal submission action rather than a lookup like check_fit, so an agent can separate it from siblings without opening a schema.

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 precondition is explicit and unusually precise: use only after the person has agreed to the quoted consent wording. That is strong when-to-use guidance, though the description never names an alternative (e.g. check_fit for eligibility or search/list_products) or states when to avoid this tool entirely.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds value beyond them by scoping results to 'published information' and stating the citation-oriented return shape (ids, titles, source URLs), though with an output schema present the return detail is somewhat redundant.

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?

Three tight sentences, front-loaded with purpose before workflow and example. The example is illustrative rather than filler, and no sentence is wasted.

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 single-parameter, richly-annotated tool with an output schema, the description covers purpose, scope, return shape, and the downstream fetch workflow. Nothing an agent needs to call it correctly is missing.

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% and the param docs are minimal ('What to look up'), so the baseline would be 3. The concrete natural-language example query ('second mortgage LVR for a trust') adds real meaning about the expected query style that the schema does not convey.

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?

States a specific verb (searches) and resource scope (Switchboard Finance's published information on Australian business finance types, criteria and licensing). Crucially it distinguishes itself from the sibling 'fetch' by explaining that it returns ids/titles/URLs while fetch delivers full text.

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?

Clearly routes the agent: search first, then 'pass an id to fetch for the full text'. It gives context for the search-then-fetch workflow but does not state when to prefer other siblings such as check_fit or list_products, which could be relevant alternatives for the same domain.

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