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

No annotations are provided, so the description carries the full burden. It adds meaningful behavioral context by disclosing per-endpoint pricing (e.g., '$0.05', '$2.00'), highlighting deterministic versus LLM behavior ('subscription-rights — deterministic, no LLM'), and noting citation-locked output for the demand letter. It does not cover auth, rate limits, or side effects of mutating endpoints like 'store', but the cost and determinism disclosures are substantial.

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 but well-structured with a front-loaded summary and a bulleted endpoint list. Each endpoint has a concise one-line purpose and price. Some information is redundant with the schema's action enum, but the pricing and endpoint-specific notes earn their place. A slightly tighter grouping or explicit parameter mapping would improve it, but it remains readable.

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?

For a tool with 35 parameters and 15 endpoints, the description gives a solid endpoint-level overview and costs, but it does not map which parameters apply to which endpoint, nor does it describe return formats. Since there is no output schema, the description leaves the agent to infer expected outputs from endpoint names. This is sufficient for simple tasks but incomplete for complex invocations like the subscription-letter endpoints.

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 100%, and parameter descriptions already explain fields like item, store, event, and query. The tool description adds no parameter-level semantics beyond what the schema provides; it only lists endpoint names. Baseline of 3 is appropriate since the schema carries the semantic load.

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 opens with 'DealPulse: Global deal intelligence API' and enumerates 15 distinct endpoints with specific intents (e.g., 'Best deal on a specific product', 'Live price comparison across retailers'). This clearly identifies the tool's function and differentiates it from sibling pulse tools by focusing on deals, coupons, cashback, and subscription savings.

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 endpoint list provides strong implicit usage guidance (e.g., use 'item' for a product, 'compare' for price comparison, 'event' for sales). However, it does not explicitly discuss when to prefer DealPulse over sibling tools like shopperpulse, nor does it state any exclusions or alternatives. The guidance is clear but stops short of full when-to-use vs. when-not-to-use instructions.

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