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

Goes beyond annotations by declaring the confirmation gate and explicitly bounding the result set: "does not return credit offers or an approval." With destructiveHint=false and openWorldHint=true already present, the remaining gap is that it never states the external side effect (enquiries actually submitted to lenders) or what happens on duplicate submission.

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 short sentences, front-loaded with the action and its return value. The required-field sentence duplicates the schema's required list and applicant sub-object, so it earns only partial credit.

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 17-parameter write tool with nested objects, no output schema, and four overlapping lender-identifier parameters, the description leaves significant ambiguity: which of applicant/lenders/providers/flat fields actually take effect, and what the returned application record contains. It is complete on intent but thin on shape.

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 88%, so the schema already carries most parameter meaning, and the description merely restates the required first name/last name/email and optional phone that the schema lists. It adds nothing about the alias families (lender/lenders/provider/providers, product/productType) that dominate this 17-parameter surface.

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?

Names a specific verb and resource ("Create ... enquiry to the selected lenders") and states the returned artifact ("application record"). The plural/lender-scoped framing implicitly separates it from create_lender_enquiry, but that sibling is never named, so the distinction is left to inference.

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?

Gives a clear precondition — the enquiry must be user-confirmed — plus the exact data the user must supply, which tells an agent when the call is legitimate. It stops short of naming alternatives (create_lender_enquiry, display_offer_form) or stating when not to call it.

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