Url

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: the default model is free, Anthropic requires a user-provided API key with direct payment, and output includes per-model 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?

The description is a single paragraph of four efficient sentences with no wasted words. It front-loads the main purpose and then details the usage. Every sentence earns its place.

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 (4 params, no output schema), the description covers the necessary context: return structure (per-model score, confidence, signals, raw_response, combined view), model options, and cost implications. Missing output schema is compensated by describing return fields.

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%, but the description adds meaning beyond the schema by explaining the default model behavior, how _apiKey works, and that context helps disambiguate. It provides examples and clarifies the flow.

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 probes LLMs to score AI visibility (0-100) per model, using specific verbs and resources. It distinguishes itself from siblings by focusing on visibility scoring for marketing audits, which is unique among the listed 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 explains when to use the tool (AI-marketing audits, pre-launch brand checks, competitive monitoring) and provides context about default vs. API-key-required models. However, it does not explicitly state when not to use it or compare to 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 establish read-only, idempotent, open-world behavior. The description adds meaningful context: routes to 5,462 tools across 1,419 sources, returns structured answers with pipeworx:// citation URIs, works on every tier, and is the default entry point. It does not contradict annotations, though it could be more explicit about error handling or result format.

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 the key directive ('PREFER OVER WEB SEARCH') and is logically organized, but it is quite long and includes repetitive lists and examples. Several sentences could be tightened without losing value, so it is not optimally 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?

For a tool with no output schema, the description covers essential operational context: what kinds of questions it handles, what it returns (structured answer with citations), performance characteristics (one fast call, every tier), and clear escalation paths. It is sufficiently complete for an agent to select and 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?

The input schema already provides 100% coverage for all parameters (including aliases). The description reinforces natural-language usage but does not add new parameter-level details. Thus 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 the tool's core function: routing factual questions to a massive set of verified sources and returning structured answers with stable citations. It uses strong verbs like 'PREFER OVER WEB SEARCH' and 'Routes the question', and explicitly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research.

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 guidance ('Use whenever the user asks...'), a comprehensive list of domains (SEC, FDA, FRED, etc.), and clear alternatives for escalation ('Step up only when needed: ... ask_pipeworx_grounded; ... deep_research'). Also notes special cases like breaking-news routing within the same 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 readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral context: it is experimental, currently matches ask_pipeworx exactly, may have candidate routing improvements, and falls back to nothing. 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 three sentences, front-loads the beta identity, and every sentence carries essential information: identical to ask_pipeworx, current no-candidate state, usage guidance, and reassurance it's fully functional. 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?

For a simple single-parameter router, the description covers the beta status, current behavior, and usage. It references ask_pipeworx for the exact response shape and behavioral details, which is acceptable given the sibling relationship, but it doesn't explain what 'routing' means in absolute terms.

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 all parameters are aliases for the single 'question' field, fully documented in the schema. The description adds no parameter-specific meaning, so it meets the baseline for high schema coverage without extra value.

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, a universal router with the same tools and response shape. It distinguishes itself from the stable ask_pipeworx via the beta/candidate testing status, but the core function ('router') is only referenced indirectly, relying on knowledge of ask_pipeworx.

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 it: 'Use it exactly like ask_pipeworx when you want the newest routing.' It contrasts with the stable router and clarifies that it's a full working router, giving clear context for selection versus ask_pipeworx.

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 establish read-only, idempotent, open-world hints. The description adds significant behavioral context: the exact return shape ({answer, evidence, confidence, source, fetched_at, refusal_reason}), all five refusal reasons, and the 'ONLY what the tool result contains' extraction guarantee. It also discloses the additional LLM call cost, which is not inferable from 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 dense but every sentence contributes: core purpose, routing behavior, extraction guarantee, return format, refusal modes, usage guidance, and cost comparison. It is front-loaded with the hallucination-resistant positioning and avoids redundant fluff. Despite length, it is efficiently structured for an agent needing to make a high-stakes decision.

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 fully covers the return structure and refusal cases. It explains the tool's behavior, when to use it, the cost trade-off, and how it differs from the sibling. Combined with rich annotations, the agent has complete information 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?

Schema coverage is 100% with all six parameters being aliases for 'question', and the schema describes this clearly. The description adds no parameter-specific details, but with full schema coverage, the baseline of 3 applies. The description's note about 'Same routing as ask_pipeworx' slightly reinforces the question-only interface without adding new semantics.

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 defines the tool as a 'hallucination-resistant answer mode' for high-stakes reads, explicitly stating it extracts answers using only the tool result. It distinguishes from the sibling 'ask_pipeworx' by noting same routing but adding grounded extraction and a cost trade-off, making its unique 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?

Provides explicit usage instructions: 'Use whenever an answer will be quoted, cited, or acted on' and lists example domains (financial verdicts, legal claims, medical lookups). It also specifies when NOT to use it: 'prefer ask_pipeworx for casual lookups' and explains the extra LLM call cost, giving clear selection criteria versus the sibling 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?

The description extensively covers behavioral traits beyond annotations: how market resolution works, fan-out logic, response shapes, resolver contract with confidence levels, parent event extraction, news fallback mechanisms, safety checks for low-confidence or closed markets, wide-spread warnings, and cancellation rule parsing. 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 very detailed and well-structured, starting with the core functionality and then expanding on edge cases. However, it is quite long (over 300 words). While valuable, some details could be condensed, but the front-loading of purpose is good.

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 (3 parameters, no output schema), the description thoroughly covers return structures, edge cases, safety checks, and usage nuances. It provides all necessary information for an agent to correctly invoke and interpret 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 all three parameters. The description enriches by explaining acceptable formats for 'market' (slug, URL, question text), the effect of 'depth' (quick vs thorough), and 'include_raw' (summarized vs full payloads). This adds 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's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies inputs (slug, URL, question text) and outputs (evidence packet + market-vs-model comparison). This is distinct from sibling tools like 'ask_pipeworx' or 'polymarket_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?

Explicit usage scenarios are given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It provides context on classifiers and fan-out examples but does not explicitly mention when not to use or alternatives. However, the guidance is clear and helpful.

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, which fully disclose the safe, pure-computation nature. The description adds minimal behavioral context beyond confirming it returns a constructed string.

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, front-loading the purpose and listing key components. Every word contributes to understanding, 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?

For a tool with 6 parameters, nested objects, and no output schema, the description adequately explains the construction task and key inputs. It could mention default values (e.g., protocol defaults to https) but those are covered in schema.

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 well-described parameters, so the description's mention of required hostname and query object adds marginal value. It does not introduce new semantics beyond what the schema already provides.

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 'Build' and resource 'URL string from components', enumerating components like hostname, protocol, port, path, hash, and query. It effectively communicates the tool's 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?

Provides clear guidance on required input (at least hostname) and optional components plus a query object. Although it doesn't explicitly mention when not to use or alternatives, the distinction from sibling parse_url is implied.

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 adds substantial behavioral context beyond the annotations: it specifies the exact data sources (SEC EDGAR/XBRL for companies, FAERS/FDA for drugs), explains that results are sorted by primary metric, mentions handling of off-calendar fiscal years, and notes the return of paired data with citation URIs. All these details enrich the agent's understanding without contradicting the read-only, idempotent, non-destructive 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 long but front-loaded with example phrases and clear purpose. Every sentence adds value, including technical details about data sources and fiscal year handling. However, it could be slightly trimmed without losing essential information, so it is not maximally 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 absence of an output schema, the description does an excellent job explaining the return format (paired data, citation URIs) and sorting behavior. It covers both entity types with sufficient detail, including edge cases like off-calendar fiscal years. The parameter count is small (2 required), and the description fully addresses what the agent needs to know 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?

The input schema has 100% coverage with descriptions for both parameters. However, the description goes further: it explains the meaning of the 'type' enum values ('company' or 'drug') and the expected format for 'values' (tickers/CIKs for companies, drug names for drugs). It also clarifies that the data returned depends on the type, providing semantic value beyond the raw 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: side-by-side comparison of 2-5 companies or drugs using specific financial or regulatory data. It provides example phrases like 'X vs Y' and 'rank these companies,' making the intent unmistakable. This distinguishes it from siblings like entity_profile or deep_research, which are for single entities or broader research.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing a strong usage directive. It gives examples of when to use the tool (comparisons, rankings, head-to-head) and implies that for single entity lookups, other tools should be used. The statement about replacing 8-15 sequential lookups further clarifies efficiency benefits.

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 goes far beyond annotations, disclosing account/signup requirements, paid tier for 'thorough', return format (findings packet with gaps[], contradictions[], citations), temporal expectations (15-60s, ~90s), and semantic excerpting behavior. It also clarifies that citations are always fetchable and that findings are 'never invented'—rich behavioral context beyond readOnly/idempotent hints.

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 but densely packed with operational value—account constraints, tool mechanics, use-case differentiation, output format, and timing. It is front-loaded with the sign-in requirement and key distinction from ask_pipeworx, and while verbose, each sentence earns its place with substantive information.

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 fully documents the return packet (verbatim evidence, confidence, source, fetched_at, citation_uri, hop, gaps[], contradictions[]), as well as auth prerequisites, depth-level behavior, timing expectations, and edge cases like breaking news. This gives a complete operational picture.

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 'question' and 'depth'. The description adds meaning by explaining depth semantics in terms of gaps recovery and contradiction scans, and clarifies that 'question' accepts broad/multi-part natural language, enriching the enum 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 it performs 'grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources' in one call, decomposing questions into facets and routing to 5,462 tools in parallel. It explicitly distinguishes from open-web search and sibling ask_pipeworx (single lookup), making its 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?

Explicitly provides when-to-use guidance: 'Best for broad/multi-part questions over structured data' and when-not-to-use with named 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'. This covers use cases, exclusions, and 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, idempotentHint=true, destructiveHint=false. The description adds valuable context: returns top-N tools with full schemas, ready to call directly. No contradictions. Missing mention of pagination or rate limits, but sufficient.

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 and usage, then lists domains, then output details. It's slightly long but every sentence adds value. Could be more concise, but not overly verbose.

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 what the response contains: top-N tools with names, descriptions, and full input schemas. It covers input, behavior, and output adequately for a discovery 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 description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for the parameters; it only mentions query and limit in context. The aliases are already in schema. No extra semantics needed.

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: finding tools by describing data or task. It lists many domains and distinguishes itself from sibling tools by being a discovery tool to call first when many tools are available.

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 says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set.' Provides concrete examples, making it easy to decide when to use.

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 value by detailing cross-source behavior, field specifics, patents API sunset (soft-fail), and news fallback. No contradictions, but could mention rate limits or performance.

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?

Reasonably concise despite length; front-loaded with examples and core purpose. Every sentence adds value, though some examples could be condensed without loss.

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?

Comprehensively covers all aspects: inputs (ticker/CIK, no names), outputs (list of fields, sources, fallbacks, limitations), and conditions (patents sunset). No output schema, so description fully compensates.

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 reinforces parameter usage with examples and the name-not-supported caveat, adding marginal value 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 produces a full cross-source profile of a US public company in one parallel call, with specific examples. It distinguishes from siblings by recommending preference over chaining single-pack lookups, though explicit sibling naming is omitted.

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 (holistic view), when not to use (names not supported), and directs to resolve_entity as alternative. Clearly prioritizes over chaining single-pack 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 provide destructiveHint=true and idempotentHint=true, covering safety. Description adds no new behavioral traits beyond stating 'delete', which is consistent but not additive.

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, first sentence front-loads the purpose. 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 single required parameter, annotations covering destructive behavior, and no output schema, the description is complete and 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 coverage is 100% with description 'Memory key to delete'. Description does not add meaning beyond schema, so baseline 3 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?

The description clearly states the verb 'Delete', the resource 'previously stored memory', and the method 'by key'. This distinguishes it from sibling tools like 'remember' and 'recall'.

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 when to use: 'context is stale', 'task is done', 'clear sensitive data'. Also references pairing with 'remember' and 'recall'.

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 explains the process (fetch, extract, emit) and output format, adding context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations. It could mention potential limitations like large page size handling, but overall it's transparent.

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 at four sentences, with a clear structure: purpose, process, output, use cases. Every sentence adds value without 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?

For a simple two-parameter tool without output schema, the description covers all needed aspects: purpose, process, output format, and typical use cases, making it 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% with clear descriptions for both url and max_links. The description does not add significant new semantics beyond what the schema already provides, meeting the baseline for high coverage.

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 generates an llms.txt file for a given URL, specifies the verb and resource, and distinguishes it from related siblings like ai_visibility_check and scan_competitor_ai_presence by focusing on file generation.

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 use cases (indexing client site, drafting own project, auditing competitor) but does not directly contrast with or exclude sibling tools, leaving some ambiguity about 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 readOnly, idempotent, and non-destructive. Description adds that it returns specific fields and defaults to active subscriptions, providing behavioral context 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?

Two succinct sentences: first states functionality and return fields, second gives usage guidance. No filler, front-loaded, every sentence earns its place.

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 read-only tool with comprehensive annotations and one parameter, the description covers purpose, returned fields, and usage. Minor gap: does not explicitly state the return is an array, but it is implied.

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 only parameter (include_inactive) is fully described in the schema. Description does not add new meaning beyond what the schema already provides, so score is baseline 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?

Description clearly states the tool lists the caller's active subscriptions, specifies returned fields, and implicitly differentiates from sibling tools subscribe and unsubscribe by referencing review and cancellation use cases.

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 explicitly advises using the tool to review monitoring before adding subscriptions and to find IDs for cancellation. It does not explicitly exclude other uses, 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 already indicate readOnly, openWorld, idempotent, non-destructive. The description adds the key behavior of repeated keys becoming arrays, which is not in annotations. 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?

Single sentence, front-loaded with the core functionality and edge cases (leading '?', repeated keys). 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?

Given the simple nature of the tool (1 parameter, no output schema), the description fully covers what the agent needs to know to use 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%, so baseline is 3. The description does not add new meaning beyond the schema examples, though it implicitly clarifies the string format. Adequate but not enhanced.

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 ('Parse') and resource ('query string'), including handling of leading '?' and repeated keys. This distinguishes it from sibling parse_url, which likely handles full URLs.

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 when parsing query strings but does not explicitly state when to use this tool versus parse_url or other alternatives. No exclusions or context are provided.

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, and non-destructive behavior. The description adds 'keyless, offline', which clarifies no API keys or network calls are needed. This extra context is valuable beyond annotations, though it could mention behavior on invalid input or edge cases.

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 sentence that efficiently and clearly conveys the tool's purpose and output. No extraneous information, well-suited for quick comprehension.

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, rich annotations, and complete schema coverage, the description adequately covers purpose and behavior. However, it lacks guidance on handling invalid or relative URLs, which would complete the context for edge 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?

Only one parameter ('url') with full schema description coverage (100%). The schema includes examples and a clear description. The tool description does not add further parameter details beyond what the schema already 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?

Description clearly states the tool's function: parsing a URL into its components. It lists specific output components (protocol, host, hostname, port, path, query as object, fragment, origin, userinfo), making the purpose unambiguous and distinct from siblings like 'build_url' or 'parse_query'.

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?

No explicit instructions on when or when not to use this tool. While the description implies usage for extracting URL components, it does not mention alternatives like 'parse_query' for query-only parsing, or 'build_url' for constructing URLs. The agent must infer context from sibling names.

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?

With all annotations false, the description carries the full burden and delivers: it discloses rate limiting (5 per identifier per day), that it's free and doesn't count against quota, that the team reads digests daily, that signal affects roadmap, and a content boundary (don't paste end-user's prompt). This is rich behavioral context beyond any structured annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph, but every sentence earns its place (purpose, triggers, exclusions, content rules, rate limit, quota). It is front-loaded with the primary action. A slightly more structured format (e.g., bullets or shorter sentences) would improve scannability, but there is 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?

For a simple feedback tool with 3 params, all-false annotations, and no output schema, the description is remarkably complete. It covers purpose, use cases, exclusions, behavioral limits, content expectations, and likely outcomes (roadmap impact). There is no significant gap that would prevent an agent from invoking 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%, so baseline is 3. The description adds meaning beyond the schema by instructing agents to 'describe the issue in terms of Pipeworx tools/packs' and not to paste the end-user's prompt, which directly informs how to fill the 'message' and 'context' parameters. This extra guidance justifies a 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 opens with a clear, specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It explicitly lists the feedback categories (bug, feature/data_gap, praise), which distinguishes it from siblings like ask_pipeworx or recent_changes, making the tool's 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?

The description gives explicit when-to-use instructions for each feedback type ('Use when a tool returns wrong/stale data...'), and equally explicit when-not-to-use guidance, telling the agent to file feedback with other MCP servers instead. It even offers a fallback criterion ('Pipeworx tool names are the ones this connection lists'), leaving no ambiguity.

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. Description adds that data is self-aggregating from CF analytics, has no PII, and is cached 5min-1h, supplementing the annotations well.

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 plus a bullet list with zero waste. Every sentence adds value, 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?

Simple tool with one optional parameter. Description covers return type (top tools, packs, volume), caching, and PII statement. Annotations cover safety. Fully adequate for an agent to use 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 has 100% coverage with enum and description for the only parameter. Description adds meaning about window behavior: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' Adds value 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?

The description clearly states it returns trending tools, packs, and call volume for a recent window, distinguishing from sibling tools like ask_pipeworx or discover_tools. Verb 'trending' and resource 'Pipeworx' are specific.

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 three explicit use cases (discovering hot sources, confirming canonical choice, aligning use case) and implies context for when not to use (e.g., for specific queries). No explicit 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, openWorldHint, idempotentHint as true and destructiveHint false. The description adds extensive behavioral detail: how it scans markets, computes partition checks, performs fill check against live CLOB depth, and reasons about realizable edge. 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 front-loaded with the core purpose and structured into clear sections (modes, semantic anchor, partition filter, response, fill check). Some sentences are dense but necessary; a little verbose in places but overall efficient for the tool's 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 the tool's intricacy (two parameters, no output schema), the description thoroughly explains inputs, modes, internal logic (Jaccard similarity, placeholder filter), response structure, and even references a sibling tool for custom sizing. An agent can understand exactly how to invoke and interpret results.

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 have descriptions, but the tool description adds substantial meaning: explains what event slugs/URLs are accepted, what topic queries work, and gives examples. It also clarifies the differing behavior between event and topic modes, going far beyond schema basic type info.

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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes (no args, event, topic) and explains each, making the purpose specific and distinct 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?

Provides explicit guidance on when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. Includes recommendations and conditions (e.g., partitions with >20% placeholder fraction return null). Lacks explicit '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?

The description goes beyond annotations by detailing caching (1h KV-level), diagnostic info when segments are empty, and the model families (e.g., crypto_price, news_momentum, partition_overround). It also explains edge calculation and tradeable-edge knobs, providing rich 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 very long and dense, containing excessive detail (e.g., exact alpha values for sports, caching mechanism). While informative, it lacks conciseness and could be front-loaded with the core purpose. Every sentence earns its place but could be streamlined.

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 (9 parameters, three segments, multiple models), the description covers the key aspects: segments, edge fields, diagnostics, and caching. It does not describe the exact output structure fully but mentions top-level fields, which is adequate without an output schema.

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 all parameters have descriptions. The description adds substantial context, such as explanations for min_liquidity, max_spread_pp, min_kelly, and min_partition_leg_kelly, including tradeable-edge filters and Kelly sizing nuances.

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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, using a specific verb and resource. It distinguishes from sibling tools like polymarket_arbitrage by focusing on Pipeworx-based edge detection.

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 it is built for 'what should I bet on today' and helps agents discover opportunities without paging hundreds of markets, implying when to use. However, it does not provide explicit when-not-to-use instructions or compare directly with sibling tools like polymarket_arbitrage.

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, idempotent, and non-destructive. The description adds significant behavioral context beyond these annotations: it explains data sources (daily snapshots), temporal bounds (60-day snapshot TTL, from snapshotting enablement), calculation details (decay from daily closes, not intraday), and response structure (tracked, expired, snapshot_dates). 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 a single dense paragraph that front-loads the purpose, then covers response details and limitations. Every sentence contributes useful information. It could be slightly more structured (e.g., bullet points for response fields), but it remains concise 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 no output schema, the description thoroughly explains the response fields (tracked, expired, snapshot_dates) and their meanings. It also covers limitations (TTL, decay computation). For a read-only tool with two optional parameters and clear annotations, the description is complete enough for an AI 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 description coverage is 100% for both parameters ('days' and 'window'). The description adds value by restating defaults (14 days, '1wk'), clarifying the 'days' clamp range (2-30), and explaining what 'window' means ('which polymarket_edges window family to read snapshots for'). This enriches the schema definitions without duplication.

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 built from daily polymarket_edges snapshots' and answers the specific question 'how long has this edge existed and is it shrinking?'. It uses a specific verb-noun pair ('track edge persistence and decay') and distinguishes itself from the sibling 'polymarket_edges' by focusing on historical tracking rather than current snapshots.

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 explains when to use the tool: when you need to know if an edge is fresh or decaying, illustrated with a trade example. It notes that a fresh wide edge differs from a 3-week-old wide edge. While it does not explicitly state when not to use it or name alternatives, the context makes the usage clear. Sibling 'polymarket_edges' is implied as the source of snapshots but not directly contrasted.

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=true, destructiveHint=false, and the description adds detailed behavioral context: walks the ladder, returns top_of_book, vwap, slippage, verdict, and warns about partial basket fills converting arb to unhedged directional position. 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 long but packed with crucial information, front-loaded with purpose, then mode-specific details, and finally usage guidance. Every sentence adds value, though it could benefit from slightly more structured formatting.

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 (two modes, multiple return fields) and no output schema, the description is comprehensive. It explains all return values for both modes and includes warnings about thin books and directional risk, 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%, but the description adds extra context beyond schema: explains side defaults per mode, size_usd interpretation for buys vs sells and basket settlement notional. This adds significant value.

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 a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It uses specific verbs and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by explicitly stating when to use it.

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: before acting on arb signals or edges trades above ~$500. Provides rationale about theoretical overround not being capturable and partial fills creating directional risk. Also specifies required parameters (market or event) and default behaviors.

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 (readOnly, openWorld, idempotent), the description details compatibility warnings, temporal alignment, and skipped counters. It explains when spreads are meaningful and when they are not, providing transparency about behavioral traits like shape equivalence checks and venue differences.

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 clear sections but is verbose (approx. 250 words). Some redundancy exists (e.g., repeating the modes and warning about pre-mapped topics). Conciseness could be improved without losing information.

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 thoroughly covers response structure (leg-by-leg prices, spread object, safety fields like compatibility_warning, temporal_alignment, skipped counters). It explains edge cases and limitations, making the tool complete for an agent to understand inputs and outputs.

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 baseline is 3. The description adds significant meaning: it clarifies that explicit tickers override topic-mapped sides, lists the pre-mapped shortcuts, and explains the effect of parameters. This goes beyond the schema's descriptions, justifying a 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, distinguishing itself from sibling tools like polymarket_arbitrage by focusing on the same resolving question across venues. It uses specific verbs ('compute', 'spread between') and identifies the resource (Polymarket-Kalshi spread), differentiating it effectively.

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 two modes (topic shortcuts and explicit tickers) and warns that most pre-mapped topics are not tradeable, guiding when not to use. However, it does not explicitly compare to sibling tools like polymarket_arbitrage or bet_research, which could serve similar purposes in different contexts.

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?

Description reinforces read-only nature beyond annotations (readOnlyHint, idempotentHint) by emphasizing retrieval and listing. Adds scoping and pairing details, 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?

Three sentences, no wasted words. Front-loaded with primary action, then usage context, then scoping. 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?

Covers purpose, usage, scoping, and sibling pairing. No output schema but return value is implied. Could mention return format but not essential given simplicity.

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%, description adds meaning by clarifying that omitting the key lists all saved keys, which is not obvious from 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 the tool retrieves a saved value or lists all keys, with specific verb and resource. It 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?

Provides context on when to use (look up stored context like ticker or notes) and pairs with remember/forget. Lacks explicit when-not-to-use but sufficient for most agents.

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=true (safe read), idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail: setting mark_read:true flags events as read so subsequent calls return only newer events. This goes beyond annotation info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense paragraph of three sentences. It front-loads the core purpose, then returns info, filters, behavioral flags, and a note about alternative access. Every sentence adds value without 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?

Despite having no output schema, the description compensates by specifying return fields (source, citation_uri, payload). It covers all key aspects: what it returns, filtering, side effects of mark_read, and polling suitability. For a tool with 5 optional parameters, this is complete.

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 5 parameters with descriptions, achieving 100% coverage. The description adds meaning beyond schema: it gives an example for type ('sec_8k'), specifies ISO format for since, and explains the read-marking effect of mark_read. This enriches the parameter semantics.

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.' It details the return fields (source, citation_uri, payload) and mentions filter options, distinguishing it from siblings like list_subscriptions which manage subscriptions rather than retrieve 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 notes that 'Polls work fine' and provides an alternative raw endpoint for scripts/dashboards, giving context on when to use this tool. However, it does not explicitly state when not to use it or directly compare with siblings, so a slight deduction applies.

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 destructiveHint. The description adds significant behavioral context: fan-out to multiple sources, fallback logic, soft-fail for USPTO, and the return format (changes grouped by source + counts + citation URIs). 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 concrete query examples, uses efficient sentences, and includes all necessary information without redundancy. 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?

Despite no output schema, the description explains the return structure. Given the tool's complexity (multiple sources, fallback, soft-fail), the description covers all key aspects needed for correct invocation and interpretation.

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%, baseline 3. The description enriches parameter meaning by providing examples for 'since' (ISO date, relative shorthand, recommended default) and clarifying acceptable inputs for 'value' (ticker or CIK). This adds value 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 defines the tool as a change feed for a company over a recent window, listing multiple data sources and explicitly differentiating from sibling tool entity_profile. Example queries ('What's new with X', 'latest on Y') make the 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?

The description provides explicit guidance on when to use this tool versus entity_profile, and explains fallback behavior between GDELT and GNews. It also includes practical advice like 'Use "30d" or "1m" for typical monitoring'.

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?

Adds key context beyond annotations: key-value scoped by identifier, persistent for authenticated users, 24h retention for anonymous. 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?

Three concise sentences, front-loaded with main purpose. Every sentence adds value—usage guidance, persistence behavior, and pairing with other 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 simple tool with 2 parameters and no output schema, the description fully covers purpose, when to use, persistence details, and relationship with recall/forget.

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 baseline 3. Description enhances with examples of key patterns (e.g., 'subject_property') and value descriptions (findings, addresses, preferences).

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 saves data for reuse across conversations/sessions, with specific verb 'save' and resource 'data'. Distinguishes from siblings recall and forget.

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 says when to use: 'when you discover something worth carrying forward'. Provides examples and pairs with recall/forget for complete 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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses that each call cascades through several lookup endpoints internally, auto-disambiguates ambiguous inputs, and returns specific data with citation URIs. This adds valuable behavioral context not captured in 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 begins with natural-language examples, making it immediately understandable, and is packed with information. However, it's a single dense paragraph without headings or bullets; could be more scannable. Still, no sentence is wasted.

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 (two entity types, multiple input formats, specific data sources), the description fully covers inputs, outputs, data provenance, and disambiguation behavior. The absence of an output schema is compensated by explicit mention of returned fields and citation URIs.

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 detailed descriptions for both type and value. The tool description reinforces this with concrete examples (AAPL, CIK format, drug names) and adds the 'auto-disambiguated' behavior, slightly exceeding the schema's 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 resolves user-spoken names to canonical identifiers, with examples of ticker/CIK/RxCUI lookups. It explicitly says 'Use FIRST whenever you have a name but need an ID,' distinguishing it from siblings like entity_profile or compare_entities.

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 guidance ('Use FIRST whenever you have a name but need an ID') and notes it replaces 2-3 manual lookups. However, it does not explicitly name alternative tools or specify when not to use it, so it stops short of the full 5 criterion.

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, openWorld, non-destructive. Description adds behavioral details: probes each entity with ai_visibility_check, treats first entity as subject for narrative, returns ranked list with score, confidence, signal density. Adds value beyond annotations 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?

Three sentences: action, process, use case with output format. Front-loaded with purpose, no extraneous words. Every sentence earns its place.

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 4 parameters, no output schema, and composite nature (calls ai_visibility_check), the description adequately explains process, ranking, and output fields. Could add more on prerequisites or error states but still complete for typical use.

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 all 4 parameters. Description adds meaning by clarifying first entity is treated as 'subject' for narrative and implicitly limits entities to 2-8 ('your brand + N competitors'), which is not 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 compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and identifies most/least recognized. It distinguishes from sibling ai_visibility_check (single entity) and compare_entities (generic) by being specific to AI presence audits.

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 use case: 'competitive AI-marketing audits' with an example question. Clearly implies when to use (comparing multiple entities), but lacks explicit when-not-to-use or alternative tools beyond the sibling list.

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 adds value beyond annotations by disclosing partial failures, bundlephobia timeout (5-30s), and degraded graceful behavior with sources_failed field.

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 front-loaded with purpose, then details return fields and limitations. It is dense but every sentence earns its place; slight length is justified by the composite nature of the tool.

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?

No output schema, but description compensates by listing return fields (is_latest, license, advisory_count, bundle sizes, etc.) and notes about partial failures. Complete enough for an agent to understand what to expect.

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 has 100% coverage with descriptions. Description adds meaningful extra: scoped packages like '@types/node' are accepted, and version defaults to latest when omitted, which aids correct 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 clearly states the tool is a composite check for evaluating npm packages, covering license, advisories, bundle size, etc. It distinguishes itself from sibling tools by being a one-call solution for safety, popularity, and size questions.

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: when agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'. Also specifies scope (npm only in v1) and alternatives (deps.dev:version directly for other ecosystems).

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?

Description discloses technical details beyond annotations: 'BGE-base-en embeddings + cosine over 500-char overlapping windows', 'cap is 200K chars (longer inputs are truncated and flagged)'. Annotations already indicate readOnly, idempotent, non-destructive; description adds valuable implementation specifics.

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 three sentences, front-loaded with purpose, provides key details (truncation, pairing, technical model) without redundancy or 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?

Despite lacking an output schema, the description explains what is returned (top-N passages with offsets and scores) and the truncation behavior. For a 3-parameter read-only tool, this is complete and covers all necessary context.

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 baseline is 3. The description repeats schema content for 'text' and 'limit', and adds an example to 'query' parameter. While examples are helpful, the description doesn't significantly augment the schema's 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 'Semantic search INSIDE a fetched record' with specific verb-resource pairing. It distinguishes itself from siblings by mentioning the 'ask_pipeworx_grounded' pairing, differentiating from other search 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?

Explicit when-to-use guidance: 'Use when the record is too big to cram into the prompt'. Also suggests alternative workflow: 'Pairs with ask_pipeworx_grounded'. This provides clear context for tool selection.

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 provides rich behavioral details beyond the annotations: mentions idempotent behavior implicitly (returns new subscription id), delivery channel specifics (always-on feed, SMS cap of 10/day, webhook HMAC verification, auto-disable after 10 failures), and prerequisites for SMS (phone must be verified at /account).

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 thorough but well-organized, covering types first then delivery channels. It is somewhat long but every sentence provides value. A slightly more structured format (e.g., bulleted lists) could improve readability, but it remains clear.

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 (3 parameters, nested objects, multiple subtypes, no output schema), the description is highly complete. It covers prerequisites, type-specific parameters, delivery channels with constraints, and what the tool returns. No gaps are apparent.

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?

Even though schema coverage is 100%, the description adds significant meaning: explains each subscription type with examples (e.g., sec_8k items codes like '5.02' for officer change), details delivery options including webhook signing and auto-disable, and clarifies required vs. optional fields (e.g., 'sponsor or condition required' for clinical_trial).

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 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This uses a specific verb ('create') and resource ('proactive monitoring subscription') and distinguishes from siblings like list_subscriptions 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 explains necessary prerequisites ('Requires a Pipeworx OAuth account') and describes the different subscription types and their use cases. However, it does not explicitly state when not to use this tool in favor of alternatives, but the context is clear given the sibling tool names.

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 destructiveHint false. The description adds value by explaining the return structure: category-bucketed example questions with tool+argument shapes. No contradictions. It provides context about the live catalog and the parameter 'topic' for refinement.

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 informative but dense, packing many example queries and categories into the first line. It is efficiently structured, with the purpose and usage front-loaded. Slightly verbose in listing all categories, but overall 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?

For a simple tool with one optional parameter and no output schema, the description is fully complete. It explains when to use, what to expect in return, and how parameters affect behavior. No gaps remain.

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 one optional parameter with 100% description coverage. The description adds context by listing example values for 'topic' and stating the default behavior (full spread). This goes slightly beyond the schema's description, justifying a 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 defines the tool as an onboarding entry point for new users to learn what Pipeworx can do, using phrases like 'the onboarding entry point' and listing multiple synonymous example queries. It distinguishes it from siblings by positioning it as a first-use tool for discovering capabilities.

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 to use this FIRST when you do not yet know what Pipeworx can do, or to learn how to call meta-tools. It also explains the optional topic parameter for focusing. While it does not explicitly state when not to use it, the context is clear and the guidance is 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?

Discloses that the row is deactivated (not deleted) and historical events remain available, adding value beyond annotations which already indicate non-destructive, idempotent write operation.

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 concise sentences with no unnecessary details, efficiently communicating purpose, ownership constraint, and behavioral nuance.

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 single-parameter tool with no output schema, the description fully covers purpose, parameter source, behavioral effect, and ownership constraint.

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 has 100% coverage and description adds that id is the subscription id returned by subscribe, which is helpful 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 uses specific verb 'Cancel' and resource 'subscription by id', clearly distinguishing it from sibling tools like 'subscribe' 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?

It states ownership enforcement and that only own subscriptions can be canceled, providing context for when to use. Lacks explicit comparison to alternatives but 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?

Annotations indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds substantial insight: explains the return verdict, grounded/structured value with citation, and notes it replaces 4-6 sequential calls.

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 unique value—examples, routing logic, and output summary. It is well-structured with clear sections.

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 details the return values (verdict, value, citation, reasoning) and covers key use cases. It is fully self-contained for an agent to understand what the tool does and expects.

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 documented. The description enriches the meaning: provides examples for the claim parameter, explains tolerance_pct default and typical usage, and mentions tolerance override for hallucination detection.

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 specifies the tool is for natural-language claim verification against authoritative sources, with distinct handling for company-financial claims (SEC EDGAR) and other claims. It clearly distinguishes itself from sibling tools by focusing on fact-checking.

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 states 'Use whenever the agent needs to check whether something a user said is factually correct,' providing clear context. It outlines two processing paths but does not explicitly exclude scenarios or mention alternative tools.

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