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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: per-attribute credit pricing (phone/email/IP 1 each, signup up to 3) and the note that demo fixtures consume no credits — exactly the cost/limit disclosure that matters here.

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 purpose then return shape then cost; no filler. The mild redundancy of "check signup for signup" and the terse credit shorthand keep it just short of a 5.

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?

It does disclose the return shape (signals plus a summary) and the cost model, which covers a lot for a tool with no output schema. Still missing: meaning of the two undocumented inputs and any note on the external lookup, non-idempotent behavior, or whether credits are charged on failed lookups.

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 0%, so the description must carry parameter meaning. It implicitly names email, phone, and ip via the credit table and gives their cost, but says nothing about country or idempotency_key, and gives no format guidance (e.g., E.164 phone, ISO country) or which combination constitutes a 'signup'.

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?

"Check signup for signup or lead-list quality" identifies the resource (a signup) and the goal (quality scoring), so the verb and object are present. But the phrasing is close to circular and never contrasts with the siblings check_email / check_ip / check_phone, so an agent cannot tell from the description alone that this is the composite, multi-signal version.

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?

There is no statement of when to use this versus the single-signal siblings, no prerequisites, and no exclusions. The only contextual hint is the credit table, which implies cost but does not guide tool selection.

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