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

Beyond the sparse annotations (readOnlyHint=false, openWorldHint=true), the description discloses billing ('creates billable AI usage'), synchronous execution, mutation modes, partial-failure policy, the internal nature of the returned JSON, and deterministic idempotency fallback. This gives an agent an unusually complete picture of side effects and failure 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 text is front-loaded and information-dense, but it is long and mixes tool-selection semantics with response-style instructions. Sentences are short, yet the response-handling block (assistantSummary, raw JSON, IDs, next action) could be tightened or moved to a shared policy.

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 output schema covers the return shape, so the description needn't enumerate results. It does cover execution model, billing, idempotency, failure policy, and response handling. It stops short of full completeness because it does not explain how to choose among the many competitor-identification parameters or when to prefer sibling intelligence tools.

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 schema has zero parameter descriptions across 25 parameters, so the description must carry the load. It does add meaning for forceRefresh, lookbackDays, evidenceMode, and the advertiser-scoped competitor concept, but most parameters (market/region/targetMarkets, strategyModes, advertiserGuidanceSnapshot, competitorKeyMessages) receive no explanation and no parameter combination guidance is given.

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 a specific action verb and resource: 'Run canonical LeanrIQ Competitor Intelligence V2 for one advertiser-scoped competitor.' The qualifiers 'canonical' and 'V2' plus the advertiser-scope distinguish it from sibling retrieval tools like get_competitor_intelligence and leanriq_get_competitor_creative_intelligence.

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 clear invocation context: defaults match Studio (90-day DISPLAY evidence), forceRefresh controls reuse of an existing canonical result, and mutation modes validate_only/preview_only/execute define how the operation can be scoped. It also states an explicit exclusion ('Task support: forbidden'), though it never names alternative tools for when a cheaper retrieval is sufficient.

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