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

With no annotations, the description carries the full burden and does well: it declares the interaction is free, nothing is bought/ordered/paid, and no quote is guaranteed, which sets accurate expectations about the operation's nature. It also previews the returned content (recipients, consent wording, confirmation flow), though it omits whether this is purely read-only and whether calling it has side effects.

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 front-loaded with 'Read first' and then packs the essential disclaimers and return-content summary into a few dense sentences. It is slightly wordy ('States plainly what submit_enquiry does on CRM for trades') but every clause carries useful information.

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 zero-parameter, no-annotation, no-output-schema informational tool, the description covers the important ground: what the enquiry is, what it is not, and what the response describes. No output schema exists, yet the description compensates by summarizing the return content, leaving only minor gaps about read-only behavior.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level semantics are needed or expected here.

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 clear purpose: it explains what submit_enquiry does and what an enquiry entails (human providers quoting directly). It names the sibling submit_enquiry and clarifies scope (not a purchase, not a guaranteed quote), but it does not differentiate itself from enquiry_fields, and its framing ('States plainly what submit_enquiry does') is slightly indirect about the tool's own action.

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?

'Read first' gives explicit ordering guidance that positions this as a prerequisite read before acting on the enquiry flow. It does not, however, state when not to use it or explicitly contrast it with enquiry_fields, so the routing guidance is clear but incomplete.

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