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

The second sentence adds genuine value beyond the annotations by telling the agent how to render the result (hide technical metadata, use human-readable headings, preserve all user-facing fields). However, with readOnlyHint=false and openWorldHint=true, the description never discloses that the call may perform external research or incur latency/cost, nor whether results are persisted or regenerated on repeat calls (idempotentHint=false).

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?

Two sentences, purpose front-loaded, no filler. The second sentence is an output-presentation rule rather than tool semantics, but it is short and actionable, so it 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?

An output schema exists, so return values needn't be spelled out, but for a non-read-only, open-world analysis tool with two undocumented parameters the definition is thin: no parameter formats, no ICP-profile prerequisite, no mention of cost or side effects, and no explicit routing to analyze_contacts. The presentation instruction partially compensates but leaves the invocation contract unclear.

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 description says nothing about either parameter. The critical ambiguity — whether 'contact' is an email, a person ID, a LinkedIn URL, or a name — is left entirely unexplained, and icp_profile_id is not mentioned at all, so an agent gets no guidance on when to supply it.

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 and output ('Return a complete ... single-contact business-fit analysis and outreach drafts') and scopes it to one contact, which implicitly separates it from the plural analyze_contacts sibling. The phrase 'business-fit analysis' is somewhat abstract, but the deliverables (analysis plus outreach drafts) make the tool's job recognizable.

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?

Usage is only implied by the singular 'single-contact' framing; there is no explicit statement such as 'use this for one contact, use analyze_contacts for batches', and no mention of prerequisites, cost, or whether an ICP profile is needed first. An agent can infer the routing from the sibling name but not from the description itself.

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