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

While annotations indicate readOnlyHint=false, the description goes much further by warning that this 'sends a REAL message to a real small business' and adding critical behavioral guardrails: never guess contact details, plain words only, no links, and a one-request-per-day limit. This gives the agent a strong sense of real-world consequence.

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 four sentences, front-loaded with the core purpose, followed by essential warnings. Every sentence earns its place, from the real-message caution to the urgent alternative. There is no filler or redundant wording.

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 side-effecting action tool with eight parameters and no output schema, the description covers all key operational aspects: consent, real contact details, content restrictions, rate limiting, and an escalation path for urgency. An agent has everything needed to decide whether and how to invoke 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 coverage is 100%, so the schema already documents all eight parameters, including the service enum and the consent requirement. The description reinforces contact-detail constraints and plain-text rules, but adds no new parameter-level meaning beyond what the schema provides, so the baseline of 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 uses a specific verb and resource: 'Ask Referral Flooring to contact a customer about a free in-home flooring estimate.' It clearly distinguishes itself from the sibling tools, which are retrieval-oriented (fetch, search, get_business_facts), by emphasizing that this sends a real message to a real business.

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 states when to call the tool ('only when the person has clearly asked to be contacted...'), what prerequisites must be met (own name and phone/email), and even provides an alternative for urgent cases ('give them the phone number instead: 289-689-4242'). It also imposes a frequency limit ('One request per person per day').

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