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

With no annotations provided, the description carries the full burden. It discloses key behaviors: 'Runs locally,' 'Rates are stored per currency exactly as Meta prints them, never converted,' and 'This is Meta's platform fee only... treat it as a floor.' It does not mention error handling or side effects, but 'Look up' implies read-only 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 a single dense paragraph that flows logically: purpose, usage, output contents, optional tier behavior, and a caveat about fees. Each sentence adds new information, and there is no fluff or redundancy despite 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?

Given there is no output schema, the description adequately describes the return contents: per-message rates by template category, currency, effective/last-verified dates, source link, and CC BY licence. It also clarifies the scope (platform fee only, local execution), but could be slightly more precise about the data structure (e.g., list vs object).

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 descriptions cover 100% of parameters, and the prose adds extra meaning: omitting market returns the whole card, include_tiers is ignored without a market, and currency rates are never converted. This goes beyond the basic enum descriptions, clarifying exactly how each parameter affects the output.

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 tool's function: 'Look up Meta's official WhatsApp Business (Cloud) API per-message rates from the site's dated rate card.' It distinguishes itself from siblings by noting it provides the same figures used by the pricing calculator and 'Runs locally,' differentiating it from cost estimation tools.

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 provides usage instructions such as 'Give a market to get one row, or omit it for every market in the chosen currency' and explains the optional include_tiers behavior. It also advises to 'prefer this over recalling or guessing prices,' but does not explicitly mention when to use alternative tools like estimate_whatsapp_api_cost, though this is inferable from the sibling context.

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