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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds extensive behavioral nuance: de-duplication by lead, rates computed over their own denominators, nulls when denominator is zero, sentiment evaluated once per lead ever, and the meaning of all-zero results. It also clarifies that 'LinkedIn reactions' actually refers to replies because Onsa stores no likes. This goes far beyond annotations, fully disclosing the tool's behavior.

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 long and dense, but every sentence contributes unique behavioral insight. It opens with a crisp one-sentence summary, then systematically addresses edge cases and clarifications. It is well-structured and front-loaded with the core purpose. While it could be trimmed slightly, the complexity of the data justifies the length.

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?

The description is exhaustive for a read-only stats tool. It covers return structure, de-duplication logic, rate denominators, null semantics, the difference between counts and actions, scheduled counts, sentiment evaluation, and the all-zero case. The output schema exists but the description enriches it with practical interpretation. Nothing an agent needs to correctly interpret the returned data is missing.

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?

The only parameter, campaignId, is already well described in the schema: 'Campaign id, as returned by list_campaigns or fetch_leads.' The description adds no additional parameter-specific meaning. Since schema description coverage is 100%, the baseline of 3 applies; the description is not required to compensate, and it doesn't.

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 clearly states the exact output: 'Returns the outreach funnel for one campaign: invites sent, invites accepted, messages sent, and replies split into positive / negative / other by sentiment.' It uses a specific verb ('returns') and a precise resource ('one campaign'). It also distinguishes itself from list_replies by noting that tool returns text while this one counts, which differentiates it from a sibling.

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 gives strong contextual guidance by contrasting with list_replies: 'list_replies returns their text, and this tool only counts them.' It also explains why counts may differ from the Overview widget, helping agents choose the right tool. However, it does not explicitly state 'use this instead of X when you need aggregate counts,' but the guidance is clear enough for a competent agent.

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