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

Annotations already declare this is a non-read-only, non-destructive, closed-world write, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 48-hour trial window, a human follow-up within one business day, the consent/privacy-policy gate, and that no sign-in is required.

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, each carrying distinct information: purpose, downstream effect, precondition, and access requirement. The consent precondition is front-loaded after the purpose, and there is no filler. Slightly long but every clause earns its place.

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 form-submission mutation with no output schema, the description covers what an agent needs: the effect of the call, the post-call timeline, and the consent requirement. It does not address duplicate submissions or confirm whether a lead record is created, which is a minor remaining gap.

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 22% across 9 parameters, so the description must carry more weight. It clarifies the most consequential parameter ('agreed_to_be_contacted' as a hard consent gate, reinforced by the privacy policy URL), but says nothing about the optional city, state, industry, or message fields. It partially compensates rather than fully closing the gap.

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 ('Sign a business up for RingGuard's free 48-hour Shadow Trial') and specifies the trial duration, so the agent knows exactly what the tool creates. It does not, however, differentiate itself from the sibling 'add_lead', which an agent could easily confuse with a trial signup.

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 a clear, explicit precondition for use: only call after the person has provided details and explicitly agreed to be contacted and to the privacy policy. It also states the downstream effect (RingGuard follows up within one business day). It stops short of naming an alternative tool or an explicit when-not-to-use case.

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