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

Goes well beyond the annotations (which only declare write/non-destructive/idempotent/openWorld=false). It discloses the critical behavioral fact that the AGENCY sends the link and 'ShearQuery sends nothing', that the call adds the business to the pipeline, and that the request form records permission to contact — all consequential side effects an agent could not infer.

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?

Front-loads the key precondition ('For an APPROVED agency') and the core artifact, and every clause carries information rather than filler. It is dense and reads as one long run-on sentence, but little is wasted.

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?

No output schema exists, yet the description covers the resulting side effects (pipeline addition, permission capture) and the follow-up surfaces (my_prospects, prospect_details), which is enough to invoke and reason about results. The main omission is any definition of the 'prospect' argument, which leaves a hole for a mutation tool.

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% and the tool has one required parameter, 'prospect'. The description never defines what that value should be (name, ID, URL, email?) or its format, so an agent must guess. Reference to prospect_details does not compensate for the undocumented parameter.

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 specific verb+resource: it creates a shareable audit page/link for a target business, and describes concrete artifacts on that page (Google profile check, 'Get started free' button, review request form). The name and description distinguish it from adjacent siblings like audit_google_business_profile and prospect_details, though it never names those siblings explicitly to say how it differs.

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 precondition ('For an APPROVED agency') and points to follow-up tooling (my_prospects shows opens, prospect_details for messaging), which implies when to use it. But there is no explicit when-to-use-vs-alternative guidance: it doesn't say when to create this link instead of running a plain audit or messaging a prospect directly, nor what disqualifies non-approved agencies.

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