Cloudflare Radar

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details: free default model, BYO key for Anthropic with direct billing, and return structure per-model. No contradiction with annotations.

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?

Three sentences covering purpose, model configuration, and use cases. Front-loaded with the core function, every sentence adds value with no redundancy or fluff.

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?

With 4 params, no output schema, and moderate complexity, the description covers what, how, and why. It lacks details on rate limits or errors, but annotations (readOnly, idempotent) and simplicity make it sufficient.

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%, so baseline is 3. The description adds practical context: default model, Anthropic key requirement, and context disambiguation. This provides meaningful additional guidance beyond schema descriptions.

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 verb 'probe' and the resource 'one or more LLMs' with a specific outcome 'score visibility (0-100) per model'. It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on scoring visibility across multiple models.

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 provides clear usage context: 'AI-marketing audits, pre-launch brand checks, competitive monitoring'. It explains when to provide `_apiKey` for Anthropic, but doesn't explicitly exclude alternative tools or state when not to use it.

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

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

The description discloses key behavioral traits beyond the annotations: it routes to other tools, fills arguments automatically, returns a structured answer with stable pipeworx:// citation URIs, and works 'on every tier, one fast call'. Annotations already declare read-only, idempotent, and non-destructive, so the description's added context about the routing mechanism and response format is valuable. No contradiction with annotations exists.

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 well-structured and front-loaded: it opens with the high-priority directive 'PREFER OVER WEB SEARCH', then systematically explains scope, mechanics, trigger phrases, examples, default status, and escalation paths. Every sentence contributes new information; there is no redundancy or filler. The length is justified by the tool's broad scope and the need to distinguish between sibling tools.

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 no output schema, the description is remarkably complete: it enumerates supported data domains (SEC filings, FDA, FRED/BLS, patents, news, etc.), explains the routing and response format, provides usage triggers and examples, and clearly situates the tool relative to its siblings with step-up criteria. The presence of detailed annotations and schema coverage means no critical information is missing, making the description sufficient for agents to select and invoke the tool correctly.

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 input schema has 100% coverage with descriptions for all parameters and clearly identifies the main 'question' parameter with five aliases. The tool description adds meaning by providing concrete example questions (e.g., 'current US unemployment rate', 'Apple's latest 10-K') that illustrate the expected natural-language input format and domain coverage. This goes beyond the generic schema description, though the schema already handles the alias semantics adequately, so it stops short of a 5.

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 that ask_pipeworx routes natural-language questions to one of 5,366 tools across 1,396 verified sources and returns structured answers with stable pipeworx:// citation URIs. It strongly differentiates from siblings by naming ask_pipeworx_grounded and deep_research as step-up options for specific needs. The extensive examples and trigger phrases ('what is', 'look up', 'find') unambiguously establish its purpose as a general factual question-answering entry point.

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 is explicit about when to use this tool: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions'. It provides concrete trigger phrases, examples, and explicitly states the escalation path to siblings ('for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'). It also clarifies that breaking-news is already covered, preventing unnecessary use of alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, providing a strong safety profile. The description adds valuable context beyond annotations: that no candidate is currently active (as of a specific date), that results are compared against the stable router, and that it falls back to nothing (fully functional). However, it does not detail how routing outcomes are used for merges or the exact behavioral differences when a candidate is active, leaving some ambiguity.

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 paragraph of three sentences, each earning its place: explaining the beta nature, the current inactive candidate state, and the comparison/merge process. It is front-loaded with the essential fact (identical to ask_pipeworx) and ends with the 'experimental edge' emphasis. No wasted words.

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 the tool has no output schema and a simple six-alias parameter schema, the description is complete enough. It conveys the experimental nature, the current exact-match status with the stable router, the usage instruction (use exactly like ask_pipeworx), and the fact that it is a full working router. This covers the key contextual requirements for an agent to invoke it correctly.

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 coverage is 100% with six aliases (q, text, input, query, prompt, question) all described as aliases for the question field. The description adds the semantic point that the tool accepts natural language questions or requests, but this is redundant with the schema's 'Your question or request in natural language.' The description does not add new parameter meaning beyond what the schema already provides, so a baseline 3 is appropriate.

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 identifies the tool as a beta version of ask_pipeworx, emphasizing its identical functionality (same 5,366 tools, arguments, response shape) while noting experimental routing improvements. This distinguishes it from the stable sibling ask_pipeworx and clarifies its role as the experimental edge, making the purpose specific and actionable for an AI agent.

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 explicitly directs agents to use it exactly like ask_pipeworx when wanting the newest routing, and explains the current inactive candidate state (matching ask_pipeworx exactly). It also names the sibling tool ask_pipeworx as the stable alternative, providing clear when-to-use and when-not-to-use guidance. The beta context implies this is for experimentation rather than production-critical tasks.

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

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

Goes far beyond the annotations by detailing the refusal behavior (with specific refusal_reason values), the evidence verbatim quote, and the extra LLM call cost. This gives the agent complete insight into the tool's behavior and failure modes.

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?

Four sentences, front-loaded with the primary purpose, efficiently packed with routing, output format, usage guidance, and cost trade-off. No fluff or redundancy.

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?

Despite lacking an output schema, the description explicitly states the success return fields and refusal reasons, making it complete for a complex tool. It also covers usage context and cost, leaving no critical gaps.

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 coverage is 100% (all parameters are aliases for the same 'question' parameter) and described in the schema. The description does not add further parameter semantics; baseline of 3 is appropriate since the schema already fully documents the parameters.

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 identifies the tool as a 'hallucination-resistant answer mode for high-stakes reads' and explicitly contrasts it with the sibling ask_pipeworx, explaining that it uses the same routing but then extracts answers only from tool results. This distinguishes it from alternatives.

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?

Provides explicit usage criteria: 'Use whenever an answer will be quoted, cited, or acted on' and explicitly instructs to 'prefer ask_pipeworx for casual lookups' due to additional LLM cost. This clearly states when and when not to use the tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that the tool returns a percentage breakdown over a time window, which is useful context. However, it does not disclose any additional behavioral details beyond what annotations provide.

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 two sentences, front-loaded with the core purpose, and contains no redundant or vague language. Every sentence adds value.

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 the presence of an output schema and annotations, the description explains the tool's purpose and filtering capability adequately. It could mention defaults, but the schema covers that. Overall complete for the tool's complexity.

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%, so baseline is 3. The description mentions 'location' and 'dimension' (mitigation product or attack vector), but the schema already describes each parameter equivalently. The description adds minimal new meaning.

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 returns a 'percentage breakdown of attacks by mitigation product or attack vector' over a time window, specifying it's for 'Layer-7 DDoS attacks'. It is specific about the resource and action, but does not explicitly distinguish from sibling 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?

The description indicates when to use the location filter but provides no guidance on when to choose this tool over alternatives. Given many sibling tools, this omission limits the agent's ability to correctly select it.

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

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

The description extensively details behavioral traits: handling of low-confidence matches (status:'low_confidence_match', suppressed analysis), closed markets (status:'market_closed_or_inactive'), wide spreads (tradeability:'illiquid_wide_spread'), resolution-rule risk (cancellation_rule parsing), and response shapes. This far exceeds the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), providing critical context for safe usage.

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 very long and detailed, with multiple paragraphs covering classifiers, fan-out examples, response shapes, resolver contracts, and safety mechanisms. While well-organized with clear sections, it is verbose and could be more concise for an AI agent, possibly overwhelming with information that could be documented elsewhere.

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 the complexity (3 parameters, no output schema, many behavioral nuances), the description is exceptionally complete. It covers edge cases (low-confidence matches, closed markets, wide spreads, resolution rules), safety instructions, and response interpretation, leaving no critical gaps for the agent to infer.

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 coverage is 100%, and the description adds significant meaning: for 'market' it reiterates and expands on input formats; for 'depth' it explains defaults and trade-offs; for 'include_raw' it clarifies when to use true vs. false and the impact on response size. This goes beyond the schema's descriptions.

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 purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the types of inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). It differentiates itself from sibling tools by being specifically for Polymarket betting research, with detailed classifiers and fan-out examples.

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 explicitly lists use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' However, it does not explicitly state when not to use this tool vs. alternatives like polymarket_edges or polymarket_arbitrage, limiting its guidance on choosing between siblings.

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

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

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds behavioral context by stating the data source (Cloudflare) and the specific fields returned, which is useful beyond what annotations provide.

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 sentence that immediately conveys the tool's purpose and output. No unnecessary words or repetition, making it highly efficient.

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 low-complexity tool with a clear output schema (implicitly present), the description is complete: it specifies the source, type of events, and returned fields. No additional context is needed.

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 coverage is 100%, so the input schema already documents both parameters (limit and date_range). The description does not add any additional meaning or constraints for parameters, keeping the score at baseline.

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 returns 'Recent BGP route-leak events detected by Cloudflare' and specifies the exact data fields (leaker AS, victim AS, originated prefixes, start/end times). This provides a specific verb-resource combination and distinguishes it from sibling tools, none of which appear to offer similar functionality.

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 implies the tool is used to get recent BGP route-leak events, but does not explicitly state when to use it or mention alternatives. However, given the uniqueness of this tool among siblings, the usage context is clear enough.

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

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

The description discloses data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, result sorting by primary metric, and citation URIs. This adds significant context beyond the annotations (readOnlyHint, etc.) without contradiction.

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 dense and front-loaded with key trigger phrases, but it could be slightly more structured. However, every sentence is informative and earns its place, making it very efficient.

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?

Despite no output schema, the description explains return format (paired data + citation URIs) and sorting behavior. It covers the tool's full functionality for its complexity and parameter set, and contrasts with sibling tools like entity_profile.

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 coverage is 100%, and the description enriches parameter meaning by specifying that 'values' should be tickers/CIKs for companies and drug names for drugs, and that 'type' determines which data is fetched. This adds valuable context beyond the schema alone.

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 it performs side-by-side comparison of 2–5 companies or drugs in a single parallel call. It explicitly distinguishes itself from sequential single-entity lookups, making the purpose unambiguous.

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 explicit guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also lists trigger phrases like 'compare X and Y' and 'X vs Y', helping the agent know when to invoke this tool.

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

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

While annotations already indicate readOnly, openWorld, idempotent, non-destructive behaviors, the description goes far beyond by disclosing account requirements, the decomposition and parallel routing mechanism, the exact structure of the findings packet (verbatim evidence, confidence, source, fetched_at, stable citation), explicit gaps[] behavior, second-hop iteration, contradictions[] scan, semantic excerpting, and expected latency. This is rich behavioral context that annotations cannot convey.

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 every sentence earns its place: access requirements, fallback alternative, core capabilities, use-case guidance, depth behavior, return packet details, and timing. It is front-loaded with the most critical operational constraint (account requirement) and is well-structured despite its length. Some redundancy exists (e.g., repeating 'ask_pipeworx' alternatives), preventing a perfect score.

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 complex tool with no output schema, the description is remarkably complete. It explains the return format, failure handling via gaps[], contradiction detection, excerpting behavior, second-hop iteration, expected latency, account/tier requirements, and explicit comparisons to sibling tools. An agent has all necessary information to decide when to invoke this tool and what to expect from it.

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 coverage is 100% and both parameters ('question' and 'depth') already have detailed descriptions in the schema. The description further adds that 'question' is meant to be broad/multi-part and explains the plan implications of 'depth' (thorough requires paid plan), timing expectations, and the distinction between quick/standard/thorough hops. This supplements the schema without being redundant, though the schema already carries much of the semantic weight.

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 performs 'grounded multi-source research' across 1396 structured data sources, decomposes questions into facets, routes to 5,366 tools in parallel, and returns a findings packet. It explicitly contrasts itself with open-web search and distinguishes from ask_pipeworx for single lookups, making its purpose unambiguous and well-differentiated.

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 provides explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data' with concrete examples. It also gives clear when-not-to-use guidance and alternatives: 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx', and 'If you are not signed in, use ask_pipeworx instead'. This fully covers usage context and exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe, non-destructive, idempotent tool. The description adds value by explaining what is returned: 'names, descriptions, and full input schemas (with curated examples)' and that 'each result is ready to call directly, no second schema lookup needed.' No contradictions.

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 paragraph that front-loads the main purpose. It includes useful examples and context without being overly verbose. It could be slightly more concise, but every sentence adds value. Efficient overall.

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 the tool's simplicity (discovery, 6 parameters, no output schema), the description adequately explains what it does, what it returns, and when to use it. The examples in the input schema further clarify usage. It is complete enough for an agent to invoke correctly.

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 coverage is 100% with 6 parameters, all described. The description mentions the query parameter and its aliases, but does not add significant meaning beyond the schema's parameter descriptions. The baseline of 3 is appropriate since the schema already provides adequate parameter documentation.

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 purpose: 'Find tools by describing the data or task.' It provides a specific verb ('find', 'browse', 'search', 'discover') and resource ('tools'), and lists many example domains (SEC filings, financials, FDA drugs, etc.). It distinguishes itself from siblings by explicitly saying 'Call this FIRST when you have many tools available and want to see the option set.'

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 explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST... to see the option set (not just one answer).' This provides clear positive guidance. It does not explicitly state when not to use or list alternatives, but the context is well-defined and sufficient for an agent to decide.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. Description adds substantial detail: fans out across multiple sources (SEC, XBRL, USPTO, news, GLEIF), lists exact return fields, notes patent sunset and soft-fail behavior. No contradictions.

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?

Description is a single paragraph with example queries upfront, making it easy to scan. It is somewhat long (5-6 sentences) but each sentence adds value. Slightly less concise than ideal, but well-structured.

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 no output schema, description covers all return fields and their sources. Limitations (patent sunset, name not supported) are noted. Could mention error handling or rate limits, but overall very complete for a holistic profile tool.

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 coverage is 100% with descriptions for both parameters. Description adds context: type is currently limited to 'company', value must be ticker or zero-padded CIK, names not supported. This exceeds baseline and provides clarity beyond schema.

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?

Description clearly states the tool provides a full cross-source profile of US public companies. Uses explicit verbs like 'get full cross-source profile' and includes example queries. Distinguishes itself from sibling tools by recommending preference over chaining single-pack lookups.

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?

Provides explicit when to use: when user asks for a holistic view of a company. Also gives clear when-not: if only a name is provided, use resolve_entity first. Mentions soft-fail for patents, guiding proper expectations.

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

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

The description does not add behavioral information beyond what annotations already provide. Annotations declare destructiveHint=true and idempotentHint=true, and the description simply says 'Delete' without elaborating on behavior like error handling or idempotency. No contradiction.

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 extremely concise: two sentences plus a pairing hint. The primary purpose is stated first, making it front-loaded with the most important information. No unnecessary words.

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 simple tool with one parameter, no output schema, and clear annotations, the description is complete. It covers purpose, usage guidelines, and pairing with siblings, leaving no ambiguity.

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 coverage is 100% with the single 'key' parameter already described as 'Memory key to delete'. The description does not add any additional semantic information beyond the schema, earning the baseline score of 3.

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 it deletes a stored memory by key. It distinguishes from sibling tools 'remember' and 'recall' by explicitly mentioning them in the pairing hint.

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 provides explicit guidance on when to use the tool: when context is stale, task is done, or to clear sensitive data. It also suggests pairing with remember and recall, making the usage context clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds context: fetches page, extracts title/description/key links, emits markdown. Does not contradict annotations; provides useful behavioral details.

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?

Single paragraph, front-loaded with purpose, followed by mechanics and use cases. Every sentence adds value with no fluff.

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 simple input (URL, optional max_links), no output schema, description explains output format and purpose fully. Annotations cover safety. No gaps for tool selection.

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 coverage is 100% with both parameters described. Description does not add significant meaning beyond schema; baseline score applies.

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?

Description clearly states it generates a standard llms.txt file for a given URL, detailing what it extracts and the output format. Use cases are provided, distinguishing this tool from general web scraping or AI presence 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?

Explicitly lists specific use cases (client indexing, personal projects, auditing competitors), which guides when to use. No explicit when-not or alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds specificity about output metrics but lacks deeper behavioral context like data source or frequency.

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, efficient sentence that front-loads the purpose and key details without waste.

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?

With two optional parameters, high schema coverage, and an output schema, the description adequately covers the tool's purpose and output, though it could mention that it returns historical comparison data.

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 coverage is 100% with clear descriptions for both parameters. The description restates filtering by location code but adds no new meaning beyond the schema.

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 provides an Internet Quality Index summary with specific metrics (bandwidth, latency, jitter, packet loss) and current value vs prior period change, clearly distinguishing it from sibling 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?

The description implies usage for querying IQI data but gives no explicit guidance on when to use this tool over alternatives among siblings, nor any exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the list of returned fields and implies default behavior (only active subscriptions), but no further significant behavioral traits beyond annotations.

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 two sentences: the first states the action and return fields, the second gives usage guidance. No filler, every sentence adds value.

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 simple list tool with no output schema, the description covers return fields and usage context. Annotations provide safety guarantees. Could be improved by noting pagination, but it's not essential given the likely limited data.

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 one parameter with a description, and coverage is 100%. The tool description does not add additional meaning beyond what the schema provides, so baseline score 3 is appropriate.

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 uses a specific verb ('List') and resource ('subscriptions'), and clearly states the scope ('caller's active'). It also enumerates the returned fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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 explicitly states when to use this tool: 'to review what you're monitoring before adding more or to find an id to cancel.' It provides clear context but does not explicitly mention when not to use it or compare to siblings.

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

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

Annotations provide minimal info (all false), but the description adds valuable behavioral traits: rate-limited to 5 per identifier per day, free, and doesn't count against tool-call quota. It also explains how feedback is processed (team digests daily, affects roadmap).

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 well-structured and front-loaded with purpose. Every sentence adds value: use cases, writing guidelines, rate limits, and quota info. It is concise without being terse.

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 covers purpose, usage, parameters, and behavioral traits. It lacks mention of what happens after submission (e.g., acknowledgment or response), but for a feedback tool this is acceptable completeness.

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%, so baseline is 3. The description adds value beyond the schema by explaining how to write the message (be specific, describe in terms of tools/packs) and clarifying that context is optional. This provides meaningful guidance.

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 purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb and resource, and it distinguishes itself from sibling tools, none of which are feedback-related.

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 explicitly lists when to use the tool (bug, feature/data_gap, praise) and provides guidance on what to include in the message. It also mentions rate limits and that it doesn't count against quota, offering clear context for usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: data source ('CF analytics-engine'), no PII, caching behavior ('5min-1h depending on window'), and the specific data format. No contradictions with annotations.

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 concise, front-loaded with the core function, followed by bullet-point use cases and data source details. Every sentence serves a purpose; no redundancy.

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 the tool's simplicity (one optional parameter, no output schema, rich annotations), the description covers all essential aspects: function, use cases, data source, privacy, caching. It provides sufficient context for an AI agent to decide when and how to use it.

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 coverage is 100% (only one parameter with an enum and description). The description adds interpretive guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand,' enhancing the enum semantics beyond the schema alone.

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 identifies the tool's function: returning top tools, top packs, and total call volume over a window. It specifies the action ('Returns'), resource ('trending data'), and distinguishes from siblings by emphasizing 'what other AI agents are calling' and 'self-aggregating signal', differentiating it from other discovery tools like discover_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?

The description provides three explicit use cases and explains window choice implications ('shorter windows surface what's hot', 'longer windows show steady-state demand'). It lacks explicit exclusion criteria or alternatives, but the guidance is clear and actionable.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false; description aligns perfectly. It adds significant behavioral context: top 200 markets by volume, Jaccard similarity ≥0.30 for cross-event, partition filter dropping placeholder slugs, fill check behavior. No contradictions.

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?

Description is dense and somewhat long, but well-structured with clear sections for each mode, semantic anchor, partition filter, response format, and fill check. Front-loaded with core purpose. Minor deduction for verbosity, but effective.

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?

Despite no output schema, the description thoroughly explains the response shape (opportunities array, partition_check object, fill check results). Covers edge cases (placeholder slugs, similarity threshold, fill check conditions). Provides sufficient context for an AI agent to interpret results correctly.

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 coverage is 100% but description adds rich meaning: event mode walks child markets and checks date-axis/threshold-axis ordering plus partition_check; topic mode searches related events and flattens markets. Provides concrete examples of event slugs and seed questions, and explains the semantic anchor and partition filter in detail.

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?

Description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes (no args, event, topic) and explains the resource (Polymarket) and actions (scan, check).

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?

Explicitly tells when to use each mode: no args for trending scan, event for specific market, topic for cross-event scanning. Provides recommendations ('compares the slopes of two lines') and warns when not to trade (fill check condition). References alternative tool polymarket_fill_risk for custom sizing.

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

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

Annotations indicate readOnly, openWorld, and idempotent. The description adds extensive behavioral context: detailed model families (crypto_price, news_momentum, etc.), edge calculation (edge_pp_net, kelly_fraction), slippage adjustments, caching at KV level, diagnostic info (filter_skips), and the Fed note about data reliability. No contradictions with annotations.

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 lengthy (multiple paragraphs) but well-structured with clear headings and sections (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, etc.). It is dense with necessary detail for a complex tool. Could be slightly more concise, but the information is valuable and well-organized.

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 9 parameters (all optional), no output schema, and complex behavior, the description is extremely thorough. It explains output structure (by_segment with segments), diagnostic info, caching, and all model details. This fully compensates for the lack of output schema and provides complete context for an agent.

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 coverage is 100%, but the description adds significant meaning beyond schema. It explains complex parameters like min_partition_leg_kelly (distinction from min_kelly), slippage_pp (context on Polymarket fees), and tradeable-edge knobs (max_spread_pp, min_liquidity) with practical advice. This helps an agent understand when and how to set these knobs.

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 purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It also provides a specific use case ('what should I bet on today') and distinguishes from siblings by focusing on Pipeworx data disagreement, unlike other Polymarket 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?

The description gives some usage guidance (e.g., 'agents discover opportunities without paging hundreds of markets', Fed bets excluded from ranking with reason, and knob descriptions), but it does not explicitly state when to use this tool versus alternatives or when not to use it. No direct comparison to sibling tools.

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

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

Annotations already mark it as read-only and idempotent. The description adds valuable behavioral context: data comes from daily snapshots, history bounded by 60-day TTL, gaps mean no scan, decay from daily closes. No contradictions.

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 front-loaded with purpose, then elaborates with analogy, arguments, response structure, and limits. Every sentence adds value, though the detail on response fields and limits makes it longer. It is well-structured for the complexity.

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 no output schema and moderate complexity, the description is extremely complete. It details the exact response format (tracked, expired, snapshot_dates), explains derived fields (trend, decay_pp_per_day), and covers edge cases like cache-miss gaps and history limits. No gaps.

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 coverage is 100% with descriptions for both parameters. The description adds context: default values (14 days, 1wk) and explains 'window' as snapshot family. It clarifies the available window families implicitly (24hr, 1wk, 1mo) but the schema does not list enums, so the description adds meaning.

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 purpose: 'Edge persistence and decay telemetry' and answers a precise question ('how long has this edge existed and is it shrinking?'). It distinguishes itself from sibling tools by focusing on time-series analysis of edge persistence, unlike polymarket_edges for raw current edges or polymarket_arbitrage for spreads.

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 provides good usage context: it contrasts 'fresh wide edge' vs '3-week-old wide edge' and explains decay computation. It implies when to use (for persistence/decay analysis) but does not explicitly state when not to use or name alternative tools. The LIMITS section adds helpful constraints.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and no destruction; the description adds context about walking the order book ladder, returning verdicts like 'clean|degraded|cannot_fill', and the risk of 'forced_directional_risk'. No contradiction with annotations.

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 well-structured with sections for single-market and basket, and front-loads the core purpose and requirements. However, it is quite long and could be slightly more concise without losing clarity. Still, it earns its length given complexity.

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?

Despite no output schema, the description enumerates all return fields for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict, theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk. Highly complete for a risk-check tool.

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 coverage is 100%, but the description goes beyond by explaining the meaning of size_usd in basket mode (settlement notional, shares per leg), the auto side default in basket, and the distinction between market and event parameters. It adds semantic richness.

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 explicitly states the tool checks 'realizable-vs-theoretical edge against live CLOB order-book depth'. It clearly distinguishes between single-market and basket modes, using specific verbs like 'walks the ladder' and 'returns'. It differentiates from siblings like polymarket_arbitrage and polymarket_edges.

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 provides explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains why—theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. Description adds crucial context: compatibility warnings for mismatched bet shapes, temporal alignment checks, skipped cross type/subtype details. No contradiction with annotations.

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?

Well-structured with labelled sections (TWO MODES, RESPONSE, SAFETY FIELDS). Though lengthy, every sentence adds information. Could be slightly tighter, but effective.

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 no output schema, the description comprehensively explains the response structure, safety fields, and caveats. Covers all aspects an agent needs to invoke and interpret results correctly.

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 covers all 3 parameters with descriptions. Description adds value by explaining `topic` values and the override behavior of explicit tickers, including examples. Baseline 3, plus extra context justifies 4.

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 it computes cross-venue spread between Kalshi and Polymarket, with specific modes (`topic` shortcuts and explicit tickers). It differentiates from sibling tools like `polymarket_arbitrage` by focusing on cross-venue comparison rather than intra-venue arbitrage.

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?

Provides explicit guidance: use `topic` for common presets, explicit tickers for custom pairs. Warns that real spreads are rare and pre-mapped topics often return compatibility warnings. Explains safety fields to determine when results are meaningful.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds scope (identifier-based) and pairing context, which are valuable beyond annotations.

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?

Four sentences: main action, use cases, scope, related tools. No wasted words, logically ordered.

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?

Covers what tool does and when. No output schema, but description doesn't detail return format. However, for a simple retriever, it's adequate.

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 coverage 100% but description enriches with concrete examples ('user_research_topic') and explains that omitting key lists all keys, adding meaning beyond schema.

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?

Verb 'retrieve' + resource 'value' is clear. Examples (ticker, address, notes) specify purpose. Distinguishes from siblings 'remember' and 'forget' explicitly.

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?

States when to use: look up stored context. Pairing with remember/forget guides usage. Not explicitly stating when not to use, but context is clear.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral details: return structure (source, citation_uri, payload), mark_read side effects, and filter behavior. No contradictions, and it enriches understanding beyond annotations.

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 four sentences, front-loaded with the main purpose. It is efficient but could be slightly tighter. No wasted sentences.

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 5 optional parameters and no output schema, the description covers return structure, filter options, mark_read behavior, and even mentions polling and an alternative API. The agent has sufficient context to use the tool correctly.

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 coverage is 100% with descriptions. The description adds meaning to key parameters like 'type', 'since' (ISO timestamp), and 'mark_read' (next call only shows newer ones). It does not repeat all params but enhances the schema's clarity.

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 purpose: 'Pull fired events from your subscription feed. Returns the most recent alerts...' It specifies the verb and resource, and differentiates from siblings like list_subscriptions by focusing on alerts and fired events.

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 provides guidance on filtering ('Filter by type and/or since'), the mark_read feature, and notes that polling works. It also suggests an alternative API endpoint for scripts/dashboards, but does not explicitly contrast with sibling tools like list_subscriptions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds detailed behavioral context: fan-out to multiple sources, fallback mechanism (GDELT→GNews), and soft-failure of USPTO endpoint. It also explains the return structure (changes grouped by source, total_changes count, citation URIs). No contradictions with annotations.

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 approximately 120 words, front-loaded with example queries, then covers sources, parameters, output structure, and sibling differentiation. Every sentence serves a purpose with no redundancy.

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?

Despite no output schema, the description explains return format (changes array, total count, citation URIs). It covers fallback behavior, potential failures, and parameter constraints. It also provides a clear contrast with entity_profile. Given the tool's complexity, the description is fully informative.

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 coverage is 100%. The description adds meaning beyond the schema: explains the 'since' parameter accepts ISO date or relative shorthand with examples, recommends typical monitoring values, clarifies 'type' only supports 'company', and explains 'value' can be ticker or CIK. This significantly aids correct parameter usage.

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 explicitly states the tool provides a change feed for a company in a time window, lists example queries, enumerates data sources (SEC EDGAR, GDELT/GNews, USPTO), and distinguishes from sibling tool entity_profile. This gives a clear, specific purpose.

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 provides guidance on when to use this tool versus entity_profile (static profile). It also recommends typical values for the since parameter ('30d' or '1m'). However, it does not explicitly list all alternative tools or exclusion criteria beyond the sibling comparison.

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

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

Annotations indicate idempotentHint=true, destructiveHint=false. Description adds context: key-value scoped by identifier, persistence for authenticated users vs 24h for anonymous. Does not mention size limits or error cases, but adds value beyond annotations.

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?

Four sentences, well-structured, front-loaded with purpose. Could be slightly more concise by removing redundant phrasing, but overall efficient.

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 explains what the tool does and when to use it, but lacks any mention of return values or confirmation of success. Since there is no output schema, the description should ideally cover what the agent can expect after invoking the tool.

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 coverage is 100% with descriptions for both key and value parameters. The description provides usage context but does not add new semantic detail beyond what the schema already includes, so baseline 3 is appropriate.

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 uses a specific verb ('Save') and resource ('data'), and clearly distinguishes itself from sibling tools recall and forget by stating its purpose as storing for later reuse across conversations or sessions.

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?

Explicitly states when to use ('when you discover something worth carrying forward'), provides examples (resolved ticker, address, etc.), and mentions alternatives (pair with recall, forget).

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that each call cascades through multiple internal endpoints and explains the return format, providing useful behavioral context beyond the annotations.

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 somewhat lengthy but every sentence adds value, starting with examples, then usage recommendation, then type details. It's well-structured and front-loaded with key action and purpose.

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?

Despite no output schema, the description fully compensates by detailing return fields for both entity types, including citation URIs. It covers all necessary information for an agent to use this tool effectively.

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 coverage is 100%, but the description adds meaning: for 'value' it enumerates acceptable formats (ticker, CIK, name for company; brand/generic for drug) and for 'type' it implies output structure. This goes beyond the schema's minimal descriptions.

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 begins with concrete example queries ('What's the ticker for…') and states it resolves names to official identifiers. It explicitly lists supported entity types (company, drug) and what each returns, distinguishing it from sibling 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?

The description advises 'Use FIRST whenever you have a name but need an ID' and notes it replaces multiple manual lookups. While it doesn't explicitly state when not to use or name alternatives, the usage context is very clear.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds value by detailing the behavior: probing each entity with ai_visibility_check, ranking by score, highlighting most/least recognized, and returning specific fields (score, confidence, signal density). No contradiction with annotations.

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?

Three sentences, each purposeful. First sentence states core purpose. Second explains mechanism and outputs. Third gives concrete use case. No wasted words, front-loaded effectively.

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?

Despite no output schema, description explains return format (ranked list with score, confidence, signal density per entity). It covers the main use case and key parameters. Could mention entity count range (2-8) but that is in schema. Overall sufficient for agent to understand and invoke correctly.

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%, so baseline is 3. Description does not add parameter-level detail beyond what schema provides. For example, 'models' and '_apiKey' are not explained in the description, though the schema covers them adequately. Description mentions only 'entities' implicitly, which matches schema.

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?

Description clearly states verb 'compare', resource 'AI visibility', and scope 'across multiple entities'. It explicitly distinguishes from sibling tool 'ai_visibility_check' by noting it probes multiple entities and returns a ranked list. The final sentence provides concrete use case and output format, making purpose unmistakable.

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?

Description provides clear context: 'useful for competitive AI-marketing audits' and a concrete example question. It implies when to use (comparing multiple brands) but does not explicitly state when not to use or mention alternatives like single-entity check. Still, the context is sufficiently directive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds significant behavioral context beyond annotations: mentions partial failures, bundlephobia's first measurement can take 5-30s, and that sources_failed will list timeouts. No contradiction with annotations.

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 moderately long but every sentence is informative. It is front-loaded with a clear summary. Slight verbosity could be tightened, but it remains well-structured and 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?

Given the tool's complexity (composite check from multiple sources, no output schema), the description provides comprehensive context: return structure (summary block, advisories, links, alternatives), behavior (graceful degradation, timing issues), and ecosystem scope. It leaves no critical gaps for agent usage.

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%, so baseline is 3. The description does not add substantial meaning beyond the schema's parameter descriptions (package name and version). It mentions version defaults to latest, but that's already in schema.

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 purpose: performing a composite security/size/popularity check for npm packages. It specifies the sources (deps.dev, bundlephobia) and what checks are performed (license, advisories, bundle size, etc.), distinguishing it from sibling tools by limiting scope to NPM ecosystem.

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?

Provides explicit usage guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also tells when NOT to use (PyPI/Maven/Cargo/Go) and directs to a different tool (deps.dev:version).

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds substantial behavioral details: embedding model (BGE-base-en), similarity metric (cosine), windowing strategy (500-char overlapping windows), character limit (200K with truncation flagging), and return format (passages with offsets and scores). This goes well beyond the annotations.

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, well-structured paragraph that front-loads the purpose, then gives usage guidance, and ends with technical details. Every sentence adds value, with no fluff or redundancy.

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?

Despite having no output schema, the description fully explains what the tool returns (passages with offsets and scores), how it works internally (windowing, embeddings), and limits (200K chars truncation). It also contextualizes usage with a sibling tool, making it complete for an agent to invoke correctly.

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 coverage is 100% and each parameter already has a good description (e.g., query has examples). The description does not significantly add new semantic meaning beyond what's in the schema; it mostly repeats or elaborates slightly. Therefore, baseline 3 is appropriate.

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 it performs semantic search inside a fetched record, gives concrete examples (SEC 10-K body, article), and distinguishes it from sibling tools like ask_pipeworx_grounded by explaining the use case. The verb 'search' and resource 'source' are specific, and the description sets it apart from other 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?

The description explicitly says 'Use when the record is too big to cram into the prompt' and explains that it saves context by returning only relevant passages. It also suggests pairing with ask_pipeworx_grounded, providing clear context and an alternative workflow.

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

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

The description discloses behavioral traits beyond annotations: requires OAuth account, delivery channels, SMS rate limits, and webhook behavior. No contradictions with annotations.

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 well-structured and concise, with front-loaded purpose and clear separation of requirements, types, and delivery channels. Every sentence adds value.

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 covers parameters thoroughly and provides necessary context for an agent to invoke the tool. Although the output schema is missing, the description states it returns a subscription ID, which is sufficient for most use cases.

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 description adds significant value beyond the input schema by providing detailed examples for each type and delivery option, including webhook signing secret behavior. Schema coverage is 100% but the description enriches understanding.

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 it creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It is distinct from sibling tools like 'unsubscribe' and 'list_subscriptions'.

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 specifies when to use this tool (for live-data event streams), lists supported types with examples, and mentions prerequisites (Pipeworx OAuth account). However, it does not explicitly exclude scenarios where other tools are better suited.

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

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

Annotations already indicate a safe, read-only, idempotent tool. The description adds valuable behavioral details: it returns category-bucketed examples with exact tool and argument shapes, drawn from the live catalog, and explains that calling with no arguments gives a full spread while passing a topic focuses the results.

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 comprehensive but slightly lengthy. It is well-structured, starting with natural language triggers, then the purpose, and ending with usage advice. Every sentence serves a purpose, but it could be tightened slightly without losing meaning.

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 the tool's simplicity (one optional parameter, rich annotations), the description is complete. It explains when to use, what parameters do, what output to expect (category-bucketed questions), and how it relates to other tools. No gaps are evident.

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 input schema has 100% coverage with a single optional topic parameter. The description goes beyond the schema by providing example values ('finance', 'pharma', etc.) and clarifying that omitting the parameter yields a cross-category spread, adding practical guidance for calling the tool.

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 that this tool returns category-bucketed example questions to help a user understand what Pipeworx can do. It explicitly distinguishes itself from sibling tools like ask_pipeworx by positioning itself as the first tool to use when onboarding.

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 advises to use this tool first when unsure what Pipeworx can do and to learn how to call meta-tools. It implicitly suggests that for specific queries, other tools are appropriate, though it does not explicitly list when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that the output is a ranked list with share percentages, providing behavioral context beyond what annotations offer.

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 with no wasted words. The first sentence immediately states the purpose, and the second provides metric-specific details. Well-structured for quick understanding.

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 the output schema exists and the description already mentions key output features (ranked list, percentages), the description is complete. No gaps remain for an agent to invoke the tool correctly.

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?

Input schema coverage is 100%, so the description is not required to add much. It briefly mentions the three metric options but does not elaborate on parameters beyond the schema.

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 returns top locations by a specified metric (http_requests, dns_queries, attacks) with share percentages. It distinguishes itself from siblings like 'attack_summary' by specifying multiple metrics and a ranked output.

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 explains what the tool does but lacks explicit guidance on when to use it versus alternatives. It does not mention exclusions or situations where another sibling tool would be more appropriate.

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

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

Beyond annotations (which already indicate non-read-only, non-destructive, idempotent), the description adds that the row is deactivated (not deleted) and historical events remain available. This provides useful behavioral context.

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 two sentences, front-loaded with the main action, and every sentence adds value. No wasted words.

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 the tool's simplicity (single parameter, no output schema, good annotations), the description covers the essential context: action, ownership, and data impact. It is complete for the tool's complexity.

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 coverage is 100% and the parameter 'id' is well-described in the schema. The description does not add new semantic information about the parameter beyond what the schema provides, so baseline score of 3 is appropriate.

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 action ('Cancel a subscription by id') and specifies the resource (subscriptions). It distinguishes the tool from siblings like 'subscribe' and 'list_subscriptions' by mentioning ownership enforcement and deactivation behavior.

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 provides context about ownership enforcement ('you can only cancel your own subscriptions'), guiding when the tool can be used. However, it does not explicitly mention alternatives or when not to use it.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotent, and non-destructive. The description goes beyond by detailing the two-path processing, the verdict types (confirmed, approximately_correct, refuted, inconclusive, unsupported), the inclusion of citations and reasoning, and the special handling of tolerance. No contradictions with annotations.

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 moderately sized (about 6 sentences) and efficiently conveys the tool's core functionality, processing details, and return format. It is front-loaded with examples and key use cases. Every sentence adds necessary information, though it could be slightly more concise.

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 the lack of output schema, the description adequately covers what the tool returns (verdict, value with citation, reasoning). It explains both processing pipelines and the tolerance mechanism. The description is complete for a tool of this complexity and requires no additional information for agent invocation.

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 coverage is 100% with descriptions for both 'claim' and 'tolerance_pct'. The description adds value by explaining that 'tolerance_pct' overrides the default implied by the claim wording and is capped at 5%, and that it's useful for hallucination detection with a high baseline.

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 explicitly states it is a natural-language claim verification tool with examples like 'Is it true that...' and 'fact check'. It clearly distinguishes the two processing paths (structured SEC data for financial claims, grounded pipeline for others), making its purpose highly specific and distinguishable from sibling 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?

The description says 'Use whenever the agent needs to check whether something a user said is factually correct', providing clear guidance on when to invoke. It does not explicitly list when not to use or compare to alternatives, but the context and sibling list make the use case sufficiently clear.

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