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

Adds real context beyond the annotations: UBM does not auto-email the person, a human team replies, and there is a rate limit of a few per day per network. These are non-obvious traits for a mutation/openWorld tool. It still doesn't say what a successful call returns or how duplicate submissions are handled.

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 action and purpose are front-loaded before the constraints, and every clause carries information (consent, reply model, rate limit). Slightly dense but no filler sentences.

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 9-parameter, nested-object mutation with no output schema and very thin schema descriptions, the definition covers consent, side effects, and throttling but leaves most field semantics and the expected result unexplained. Adequate to decide whether to call, not fully adequate to call it correctly.

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 only 11% across 9 parameters, so the description carries the burden — yet it only clarifies name plus 'an email or phone number' (useful, since neither is required in the schema). business_type, business, role, message, and preferred are left entirely to enums and maxLengths, with no explanation of where business_type values come from or how 'plan' maps to answers.

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 concrete verb and resource: send a business's plan and contact details to UBM's team, plus the downstream intent (they get in touch). The reference to the Solutions guide's own 'send me this plan' form distinguishes it cleanly from quote/recommend/see-demo/start-signup siblings.

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 an explicit gating condition: 'Only call this when the person has asked to be contacted, with the details they gave you.' That is a clear when-to-use with a consent prerequisite, though it never names the alternative sibling (e.g. ubm_see_demo, ubm_start_signup) an agent should pick instead when the person is not asking to be contacted.

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