Intact

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds that it makes external API calls to Workers AI and optionally Anthropic, and that the user pays Anthropic directly when using that model. This is useful behavioral context beyond annotations, though it does not mention rate limits or error handling.

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

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

The description is four sentences that flow logically: action, default behavior, return format, use cases. Every sentence adds value without repetition 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?

Despite no output schema, the description fully explains the return structure (per-model score, confidence, signals, raw_response, plus combined view). With 4 parameters fully described and clear use cases, the tool is self-contained and understandable.

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 schema already documents each parameter. The description adds value by explaining the default model, the need for _apiKey only for Anthropic, and the return format. This enhances understanding beyond the bare 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 probes LLMs for knowledge about entities and scores visibility (0-100). It specifies the default model and the option to add Anthropic. This differentiates it from siblings like 'scan_competitor_ai_presence' which likely does a different task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring). It explains the default model and the API key requirement for Anthropic. However, it does not explicitly state when not to use it or contrast with alternatives, though the context implies its niche.

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 cover read-only, idempotent, non-destructive safety. The description adds meaningful context: it routes to thousands of tools, fills arguments automatically, and returns stable pipeworx:// citation URIs. This discloses expected behavior and output format beyond the annotations.

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

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

The description is longer than average but front-loads the core purpose and usage rule, followed by concrete examples. Every sentence contributes to clarifying scope or invocation, though some redundancy exists across the trigger phrases and examples.

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 meta-tool with no output schema, the description explains the return format (structured answer with citation URIs), the routing behavior, and provides varied usage examples. It lacks details like potential latency or the shape of citations, but is sufficiently complete for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described as an alias for the natural language question. The description reinforces that natural language input is expected, but doesn't add new semantic details beyond the schema. 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 that this tool answers factual questions by routing to verified sources and returning cited data. It distinguishes itself from web search, but does not differentiate from sibling variants like ask_pipeworx_beta or ask_pipeworx_grounded.

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 with concrete trigger phrases ('what is', 'look up', 'find') and example questions. It states 'START HERE for most questions' and 'PREFER OVER WEB SEARCH', giving clear context, but does not mention any exclusions or when to prefer sibling alternatives like ask_pipeworx_grounded.

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 cover read-only, idempotent, open-world, and non-destructive traits. The description adds meaningful behavioral context: candidates are enabled live under test, no candidate is currently active, and the tool currently matches ask_pipeworx exactly. The "falls back to nothing" clarification is especially useful for preventing the wrong inference that it delegates to the stable router.

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 compact and front-loaded, with the core "beta version of ask_pipeworx" message first. Every sentence adds contextual value, including the inactive-candidate status and the no-fallback clarification. It is slightly verbose with details like the retirement date, but not to a harmful degree.

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?

There is no output schema, but the description explicitly states that the response shape is identical to ask_pipeworx, which gives an agent a reference point. It also clarifies the tool's current behavior and experimental status. It does not enumerate response fields, but for a beta alias of an existing known tool, this is adequately 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 description coverage is 100%, so the alias parameters are already fully documented. The description adds that it accepts the same arguments as ask_pipeworx, which is useful but not necessary. This is the expected baseline: the schema handles parameter semantics, and the description does not need to compensate.

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 this as the beta variant of ask_pipeworx, a universal router with the same toolset, arguments, and response shape. It explicitly frames the difference as "candidate routing improvements" and "the experimental edge," which distinguishes it from its stable sibling without ambiguity.

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 an explicit usage direction: "Use it exactly like ask_pipeworx when you want the newest routing." It also clarifies that results are compared to the stable router, so an agent can infer when this tool is appropriate. It stops short of explicitly saying when not to use it or naming all exclusions, but the guidance 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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the refusal contract with exact reason values, the guarantee of verbatim-evidence extraction, and the extra LLM call cost. It also clarifies failure modes and the fact that only tool-result content is used.

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?

Every sentence carries distinct value: the behavioral distinction, the return/refusal contract, the use cases, and the cost-based alternative route. It is dense but well organized, with the core differentiator and return contract front-loaded.

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 fully specifies the success and refusal response shapes, the grounding guarantee, when to use it, and the cost comparison to its sibling. An agent has everything needed to invoke it correctly and interpret its result.

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 schema already documents the parameters fully. The description mentions the routing and argument-filling behavior but does not add parameter-level details; baseline 3 is appropriate given full schema 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 names a precise behavior: a hallucination-resistant, grounded answer mode that routes identically to ask_pipeworx but extracts answers only from tool results. It clearly distinguishes itself from the sibling ask_pipeworx tool by describing the exact behavioral difference.

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 this tool ('whenever an answer will be quoted, cited, or acted on ... must not invent facts') and when not to ('prefer ask_pipeworx for casual lookups'), even quantifying the cost trade-off. This is exemplary routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral context beyond these: resolution contract (market_match_confidence, suggestions), parent_event extractor, news fields with fallback, safety (low-confidence short-circuits, closed/dead markets), wide-spread market handling, and resolution-rule risk. 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 long but well-structured, front-loaded with the core purpose and followed by detailed sections. Every sentence provides specific value (classifiers, fan-out examples, response shapes, edge cases). Could be slightly more concise, but the complexity of the tool justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (resolver, fan-out, safety checks) and lack of output schema, the description is exhaustive: it explains return shapes (result.market, result.analysis, result.evidence, etc.), edge cases (low-confidence, closed markets), and safety mechanisms. 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?

Schema coverage is 100% with descriptions. The description adds value beyond the schema by explaining the depth parameter (quick vs thorough with source counts) and the include_raw parameter (summarized vs full payloads). The market parameter is effectively explained via examples in the schema. No additional param details are needed, but the description provides usage context.

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 starts with a clear verb+resource: 'Research a Polymarket bet'. It specifies inputs (slug, URL, question text) and outputs (evidence packet + comparison). It distinguishes from sibling tools by being specific to Polymarket betting research, while siblings include general tools like deep_research and 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?

Explicit usage guidance is given: 'Use for should I bet on X, what does the data say about Y, or is there edge in Z'. It provides examples of classifiers and fan-outs. However, it does not explicitly state when not to use this tool, e.g., for non-Polymarket bets or when simpler queries suffice.

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 context on data sources (SEC EDGAR/XBRL for companies, FAERS/fda for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. 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?

Single dense paragraph with no wasted words. Every sentence adds value: usage examples, data source details, sorting info, citation URIs, and efficiency claim. Front-loaded with key phrases.

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 2 params, 100% schema coverage, and no output schema, description covers all needed aspects: purpose, usage, data retrieval, sorting, return format, and efficiency benefit. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds crucial meaning: explains how 'type' determines data fetched, provides examples for 'values' (tickers/CIKs vs drug names), states min/max items, and clarifies sorting behavior. Enhances schema significantly.

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 performs side-by-side comparison of 2–5 companies or drugs in one call, with specific verb phrases ('Compare X and Y', 'rank these companies'). It distinguishes from sequential lookups and provides clear scope.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear when-to-use guidance. Provides example queries and implies alternatives (single entity lookups). No exclusions needed.

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 readOnly/idempotent annotations, the description reveals the decomposition-and-parallel-routing execution model, the findings packet structure (evidence, confidence, source, fetched_at, citation_uri), the gaps[] mechanism, contradictions[] for certain depths, hop behavior, semantic excerpting, and latency ranges. This gives an agent a strong mental model of what will happen and what the response will look like.

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 dense, and every sentence earns its place: prerequisite and alternatives are front-loaded, then execution behavior, return format, citation semantics, depth differences, and latency follow in logical order. There is no filler or repetition despite the heavy information load.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description carries the full burden of explaining expected results, and it does so thoroughly: findings packet, gaps[], contradictions[], citation_uri fetchability, excerpting behavior, depth semantics, latency, authentication, and fallback tool. Given the tool's complexity, this is a complete and actionable definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful refinement: it clarifies that depth 'thorough' requires a paid plan, that 'quick' is a single hop, that 'standard' adds gap recovery and contradictions[], and that 'thorough' adds a full iterative hop. This supplements the enum descriptions with operational consequences and selection guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1499 STRUCTURED data sources ... in ONE call' and explicitly contrasts it with 'open-web search'. It also names the intended use case ('broad/multi-part questions over structured data') and differentiates the tool from ask_pipeworx and news-style lookup tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and when-not-to-use guidance: use ask_pipeworx if not signed in or for single lookups, prefer it for breaking news topics, and use deep_research for broad structured multi-part questions. It even says deep_research 'returns mostly empty gaps[] when the topic isn't in the structured catalog,' clearly setting expectations about when this tool is the wrong choice.

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=true, destructiveHint=false. Description adds details about return value: 'top-N most relevant tools with names, descriptions, and full input schemas' and 'each result is ready to call directly, no second schema lookup needed.'

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, but it runs long. Every sentence adds value, though minor trimming could improve conciseness.

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 explains what is returned (top-N tools with full schemas). It covers the main behavior but does not specify empty query handling or ranking details.

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% with all parameters described. Description adds context by listing aliases (task, q, search, description) and providing examples of query values, adding 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 states 'Find tools by describing the data or task,' a specific verb+resource. It distinguishes itself from sibling tools (e.g., deep_research, entity_profile) as the discovery/search tool among many specialized tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set.' Provides use cases like 'browse, search, look up, or discover what tools exist for: ...' but does not explicitly state when not 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?

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description details the fan-out across sources, the meaning of sources_used/sources_failed, that empty sections indicate real absence of data, the resolved:false + notes behavior for private companies, and resolved_from/resolved_to for name inputs. This gives the agent concrete expectations about output structure and edge cases without contradicting the annotations.

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

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

The description is dense and front-loaded with trigger examples, and most sentences carry useful information. However, it runs as one long paragraph and repeats some schema details (e.g., type interchangeability and value shapes), so it is not maximally concise or structurally optimized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no output schema, the description thoroughly covers input variants, output sections with pipeworx URIs, source success/failure semantics, and edge cases like private companies. Nothing an agent needs to select and invoke the tool correctly is missing.

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% description coverage for both parameters, so the baseline is 3. The description adds meaningful nuance — names resolve via SEC EDGAR's company-name match, ticker/CIK/name are all valid regardless of type, and private companies yield resolved:false — which goes beyond the schema's explicit text and justifies a higher score.

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 states a specific action — producing a full cross-source profile of a US public company in one parallel call — and reinforces it with concrete trigger phrases like 'Tell me about X' and 'brief me on Tesla.' It clearly distinguishes itself from single-pack SEC/XBRL/news lookups by emphasizing the holistic, cross-source scope, even if it does not explicitly contrast with sibling tools like resolve_entity 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?

It explicitly instructs 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' giving a clear when-to-use directive with example phrasings. However, it does not provide an explicit when-not-to-use condition or directly mention alternative sibling tools such as compare_entities, so the guidance is clear but not fully exclusionary.

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 valuable context: data source (IntAct), 'keyless' access, and output fields. No contradictions. Adds appropriate 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?

Single sentence efficiently conveys source, purpose, input, and output. Front-loaded with 'IntAct (EBI) molecular-interaction database'. 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?

Though no output schema, description lists key output fields. Lacks mention of pagination behavior or result format, but schema covers page/limit. Adequate for a simple retrieval tool with good annotation support.

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 parameters (page, limit, query). Description repeats parameter examples but does not add new semantics beyond schema. 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?

Description clearly states the tool finds molecular interactions from IntAct database, specifies input types (gene/protein name or UniProt id), and lists output fields (detection method, interaction type, organism, PubMed ref, MI confidence). It distinguishes from sibling 'interaction_count' by indicating it returns detailed results and is 'keyless'.

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 when-to-use or when-not-to-use guidance. The term 'keyless' hints at no authentication needed, but alternatives like 'interaction_count' are not mentioned. Usage context is implied but not clarified.

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 destructiveHint=true and idempotentHint=true. The description adds context about clearing 'sensitive data' and is consistent with annotations. No additional behavioral details needed.

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 succinct sentences: action, usage guidance, and related tools. No fluff, effectively front-loads the core 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?

Given the tool's simplicity (1 parameter, no output schema), the description covers purpose, usage, and related tools. It could mention permanence or error handling but overall is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter 'key' described as 'Memory key to delete.' The description does not add further meaning or constraints beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Delete a previously stored memory by key,' clearly identifying the verb and resource. It distinguishes from siblings like 'remember' and 'recall' by focusing on deletion.

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 scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' Also mentions pairing with 'remember' and 'recall,' guiding appropriate 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 declare read-only, idempotent, open-world nature. Description adds fetching and extraction behavior, but does not detail failure modes or rate limits. Baseline 3 because annotations carry the bulk of safety information.

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 with no waste: first defines purpose and audience, second explains process, third lists use cases. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema, the description covers purpose, process, output format, and use cases. Lacks detail on error handling but sufficient for agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. Tool description does not add extra meaning beyond mentioning 'key links' implied in output. Baseline 3 as schema already provides complete parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb and resource. It distinguishes from sibling tools by focusing on generation of the file itself, not auditing or scanning.

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 cases (indexing a client's site, drafting for own project, auditing competitor). Implicitly suggests when to use but lacks explicit alternatives or when-not-to-use guidance compared to siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'fast' and 'keyless', providing performance and authentication context beyond the annotations.

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

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

The description is a single concise sentence that front-loads the key information: purpose, input, and keyless nature. 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 tool's simplicity (one param, no output schema), the description covers the essential aspects. Could mention output format but not necessary for understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage with a clear description for the 'query' parameter. The description reinforces the input types but adds no new information 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 counts molecular interactions for a gene/protein, specifies input types (name or UniProt ID), and notes it is keyless. This distinguishes it from sibling tools like find_interactions.

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 use for a fast count and mentions keyless access. It does not explicitly state when not to use or mention alternatives, but the context is clear for a simple count 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 read-only, idempotent, non-destructive. Description adds that it returns specific fields and implies subscription status filtering (active by default). No contradiction; adds useful 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-sentence description: first sentence declares function and return fields, second sentence guides usage. Front-loaded, every sentence adds value, no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single optional parameter, no output schema) and rich annotations, the description sufficiently covers what the tool does and when to use it. Minor omission: does not mention default behavior of include_inactive false, but schema covers it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the single parameter 'include_inactive' well-described in the schema. Description does not repeat parameter details but adds no additional meaning beyond the schema, 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 'List the caller's active subscriptions' and enumerates return fields. It differentiates from sibling tools like subscribe and unsubscribe by focusing on listing, and the verb 'list' plus resource 'subscriptions' is specific and 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?

Explicitly advises using the tool to 'review what you're monitoring before adding more or to find an id to cancel,' providing clear when-to-use guidance and implicit alternatives (subscribe, unsubscribe).

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?

Since annotations are all false and provide no safety or behavioral hints, the description carries the full burden and delivers: it discloses the anonymous claim_token flow, the daily rate limit of 5 per identifier, the fact that it is free and doesn't count against quota, and that the team reads digests daily. This is far beyond what the annotations offer.

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

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

The description is long but front-loaded with the core action first, then use cases, exclusions, token lifecycle, and rate limits. Every sentence earns its place; there is no fluff or repetition of schema content.

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?

This tool has no output schema and all-false annotations, so the description must cover behavior and return semantics; it fully does. It explains scope ('ONLY for tools served by this Pipeworx connection'), the claim_token response, rate limiting, and how to describe issues, making it complete for a feedback 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%, so the baseline is 3, but the description adds meaningful guidance beyond the schema: it explains the message format ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), gives typical length ('1-2 sentences'), and shows the exact claim_token round-trip syntax. This elevates the parameter semantics above 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 opens with a specific action and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It explicitly enumerates feedback categories (bug, feature/data_gap, praise), clearly distinguishing this from sibling tools like ask_pipeworx and discover_tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit trigger conditions: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides a strong exclusion criterion: reports about other MCP servers should be filed with that server instead, and tells users that Pipeworx tool names are the ones this connection lists.

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 safety info; description adds data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). 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?

Concise and well-structured: action first, then use cases, then technical details. 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?

Despite no output schema, description explains what is returned (top tools, packs, call volume). Also covers caching and data source. Complete for a simple 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 covers 100% of parameters, and description adds context for window meaning (shorter for hot, longer for steady-state demand), exceeding schema detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns top tools, top packs, and call volume over a window. Uses specific verbs and distinguishes from siblings by focusing on trending/call volume data.

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?

Lists three explicit use cases and explains window context but doesn't mention when not to use or compare directly with sibling tools.

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

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

The description discloses key behavioral traits beyond annotations: Jaccard similarity filter (SEMANTIC ANCHOR), placeholder slug filtering (PARTITION FILTER), and fill check with realizable edge calculation. Annotations already mark it as read-only and idempotent, which the description aligns with, and no contradictions are present.

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 well-structured with sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). It front-loads the core purpose. While slightly long, the complexity of the tool justifies the length. A minor reduction in detail on edge cases could improve conciseness.

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 response structure (opportunities array with fields, partition_check object) and covers edge cases like skipped_low_similarity and placeholders_filtered. It also references polymarket_fill_risk for custom sizing, showing thoroughness. The tool's behavior is fully documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant context: it explains that no args triggers trending scan, event and topic modes have specific meanings, and provides examples. The description also details the partition check and fill check behavior tied to the parameters, adding 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's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes (no args, event, topic) with specific examples, making it easy to understand what the tool does relative to siblings.

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 instructs when to use each mode: no args for trending scan, event for specific market, topic for cross-event scan. It provides example inputs and explains the partition check and fill check. However, it does not directly compare with sibling tools like polymarket_edges or polymarket_edge_tracker, which could be 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?

Discloses caching behavior ('Cached 1h at the KV level'), response structure (by_segment, fed_candidates, _diagnostics), and explains why segments may be empty (funnel counters). Also notes the Fed bets exclusion reason. No contradiction with annotations (readOnlyHint, idempotentHint).

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 detailed and uses sectioning for the three model families and response segments. It front-loads the main purpose. While it is long, every sentence carries necessary information for a complex tool; structure is clear but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (9 parameters, no output schema), the description thoroughly explains output structure, model families, edge cases (placeholder filter, partition jumps), and diagnostic information for empty segments. It covers all aspects needed for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 9 parameters are described in the input schema (100% coverage). The description adds value by grouping parameters into 'TRADEABLE-EDGE KNOBS' and explaining rationale for defaults (e.g., slippage_pp default 0.3, min_partition_leg_kelly logic). This enriches understanding 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?

Clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' The verb 'scan' and resource 'Polymarket markets' are specific, and the description differentiates from sibling tools like polymarket_arbitrage by focusing on Pipeworx discrepancy.

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 targets 'what should I bet on today' use case and mentions that Fed bets are excluded from ranking due to unreliable signal. Providing knobs like min_liquidity and max_spread_pp gives guidance on filtering. However, it does not explicitly mention when not to use or list alternative tools by name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral details: it reads from daily snapshots, uses a 60-day TTL, explains that decay numbers come from daily closes not intraday, and that gaps mean no scan. 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 front-loaded with the purpose and structured with explicit sections (RESPONSE, LIMITS). Every sentence adds value, and while it is long, the detail is necessary given no output schema. It is well-organized and concise for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description thoroughly explains the return structure: tracked[], expired[], snapshot_dates[], including fields like trend, decay_pp_per_day, and lifespan_days. It also covers limits like the 60-day TTL. The description is fully complete for effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters having clear descriptions. The tool description adds default values and range for days (clamp 2-30) and options for window, but these are already present in the schema description. Thus, the description does not add meaning beyond the schema, leading to a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools by focusing on edge tracking and decay analysis.

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 context for when to use the tool: to differentiate fresh edges from old ones. It implies usage by stating 'a fresh wide edge and a 3-week-old wide edge are different trades.' While it doesn't explicitly exclude alternatives, it gives clear guidance on the telemetry aspect.

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

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

Annotations already mark it read-only and idempotent. The description adds critical behavioral context: partial basket fills convert arb into unhedged directional position (dominant loss mode), and clarifies the tool walks the order book ladder. 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 long but structured with capitalized mode markers and lists return fields for each mode. Every sentence adds value, though a slightly shorter version might be achievable without losing information. Still, it's well-organized and front-loaded.

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 enumerates all return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, etc.) and explains the risk of unhedged positions. It provides complete context for the tool's behavior and output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains default values (size_usd=1000, side defaults), interpretation differences between single-market and basket modes, and what returns are produced. This significantly aids correct parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and clearly distinguishes between single-market and basket modes. It names the specific resource and action, and the distinction from siblings is evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why (theoretical overround not capturable, partial fills cause directional risk). This provides clear when-to-use and risk context.

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, non-destructive behavior, and the description adds substantial behavioral context beyond those: unclassified legs are never paired, temporal_alignment null does not mean aligned, compatibility codes are enumerated, fees are gross because Kalshi fees are not modeled, and skipped comparison counters are exposed. This is exactly the kind of non-obvious behavior an agent needs to know before trusting the output.

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 it is organized with clear labels like TWO MODES, RESPONSE, and SAFETY FIELDS, and the core purpose is front-loaded. Most sentences carry needed information given the absence of an output schema, though there is some repetition around identical matcher behavior and mode symmetry that keeps it from being maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: raw probabilities, top_spreads_pp sign convention, per-entry flags, temporal_alignment null semantics, skipped_* counters, fees_note, and compatibility codes are all covered. An agent has enough information to call the tool and interpret its results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the baseline is already strong. The description adds valuable interaction semantics beyond the schema: the explicit ticker and slug override their topic-mapped side, both modes run the same matcher, and the topic list is spelled out with concrete shortcut names. This meaningfully clarifies how the parameters combine.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific resource and function: it reports the cross-venue spread between Kalshi and Polymarket for the same resolving question, and goes on to specify two input modes and the response shape. However, it never explicitly contrasts itself with sibling tools such as polymarket_arbitrage, so it stops short of full sibling differentiation.

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 two modes are clearly explained: topic shortcuts auto-fetch matching events, while explicit kalshi_event_ticker + polymarket_event_slug are for custom pairings, and the description notes that both modes run the identical matcher. It also warns that pre-mapped topics are not automatically tradeable and that safety fields should be read even when pairs are returned, though it does not mention when to prefer a sibling tool for 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is already clear. The description adds context about scope (anonymous IP, BYO key hash, account ID) and behavior when key is omitted (list all keys), which goes beyond annotations.

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

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

The description is three sentences, front-loaded with the action, and every sentence adds value. There is no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one optional parameter, clear annotations, no output schema), the description fully covers purpose, usage, behavior, scope, and pairing with related tools. It is complete and self-contained.

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 parameter description. The description adds the key insight: 'omit the key argument' to list all keys, clarifying the optional behavior that is not fully explained in 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 states 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' This clearly specifies the verb (retrieve/list) and resource (saved memories), and distinguishes from sibling tools like remember 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?

The description explains when to use: 'look up context the agent stored earlier... without re-deriving it from scratch.' It also provides exclusions and alternatives: 'Pair with remember to save, forget to delete.' Mentions scoping to identifier.

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. Description adds valuable behavioral details: what each alert carries (source, citation_uri, payload), filtering options, and the mark_read flag's effect on subsequent calls. 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?

Three sentences: first states core purpose, second lists key fields and filtering, third explains mark_read and polling alternative. Front-loaded, no wasted 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?

Description is complete given no output schema: explains return content (source, citation_uri, payload), covers all 5 parameters, mentions alternative URL for scripts. Could optionally mention default limit value explicitly, but not necessary. Well-rounded.

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. Description reinforces parameter usage: filter by type, since, limit, mark_read (flag to mark read), unread_only. Adds context like 'ISO timestamp' and 'default 50' for limit, and explains mark_read behavior. 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?

Description clearly states the tool pulls fired events from subscription feed, returns recent alerts with specific fields (source, citation_uri, payload). Distinguishes from sibling tools like list_subscriptions (focused on subscriptions themselves) and subscribe/unsubscribe (managing 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?

Explicitly says 'Pull fired events from your subscription feed' and 'Polls work fine; the same feed is also at GET registry.pipeworx.io/alerts.json for scripts and dashboards', indicating when to use and an alternative access method. Does not explicitly exclude scenarios but provides sufficient context for appropriate usage.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds: fans out to multiple sources, fallback logic, soft-fail for USPTO, and return structure with sources, counts, and URIs.

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 dense paragraph, front-loaded with use cases, efficient in wording, covers purpose, behavior, return structure, and alternatives 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?

Given complexity (multi-source, fallback, time windows, no output schema), description provides all needed context: what it returns, how fallback works, when not to use it (entity_profile).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 3 params with descriptions; description adds concrete examples (ISO vs relative dates), entity types (ticker/CIK), and usage recommendations. 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?

Description starts with concrete example queries and clearly states it's a change feed for a company in a time window via one parallel call. It explicitly distinguishes from sibling 'entity_profile'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: use 'entity_profile' for static profiles. Also explains fallback behavior (GDELT to GNews) and parameter suggestions (e.g., '30d' for 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?

Discloses scope (key-value per identifier), persistence (persistent for authenticated, 24h for anonymous), and aligns with annotations (write, idempotent, non-destructive). Adds value beyond annotations.

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

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

Four well-structured sentences, front-loaded with purpose, no redundant information—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?

Covers all aspects: what, when, how (key-value), scope, persistence, and companion tools. No gaps given the tool's 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 covers both parameters with examples; description adds real-world context (e.g., 'user_preference') and scenarios, enhancing understanding despite full schema 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 saves data for reuse across conversations/sessions, with specific examples like 'resolved ticker, target address'. It distinguishes from siblings like 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 'Use when you discover something worth carrying forward' and provides concrete scenarios. It also directs to pair with recall/forget for lifecycle management.

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 readOnly, openWorld, idempotent, and non-destructive annotations, the description discloses important behaviors: graceful degradation if GLEIF or OpenFIGI is unavailable, ambiguous matches returning figi_candidates, unresolved identifiers surfaced under `unresolved`, and source-labelled identifiers. This is substantial behavioral context that annotations alone would not provide.

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

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

The description is information-dense and front-loaded with examples and the 'Use FIRST' rule, but it is structured as one long run-on paragraph with some redundancy, such as restating accepted inputs that the schema already documents. Most content earns its place, but readability and concise organization are sacrificed.

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?

There is no output schema, so the description compensates by explaining return behavior: candidate lists when ambiguity exists, explicit unresolved handling, source-labelled identifiers, and drug-specific outputs like RxCUI and brand. It also covers edge cases such as non-US issuers, non-equity instruments, and degraded enrichment. The description is highly complete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, and the description adds significant parameter-level meaning: concrete examples (AAPL, 0000320193, ozempic), the constraint to pass the entity name only, the warning about trailing security-class words, and ISIN-to-LEI behavior. This goes well beyond the schema's simple property 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 explicitly states that the tool resolves user-spoken names to canonical/official identifiers that other tools require, and it enumerates the supported entity types (company and drug) with their identifier sources (EDGAR, GLEIF, OpenFIGI, RxNorm). This clearly differentiates it from siblings like compare_entities and entity_profile by centering on name-to-ID resolution.

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 an explicit usage rule: 'Use FIRST whenever you have a name but need an ID.' It also explains that the tool internally cascades through multiple lookup endpoints and replaces 2-3 manual lookups. It does not explicitly name sibling alternatives or state when not to use it, but the usage context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. The description adds value by revealing that it internally probes each entity with 'ai_visibility_check' and returns a ranked list with specific fields (score, confidence, signal density). This goes beyond annotations to explain the tool's internal behavior and output structure.

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 (4 sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, behavior, use case, and output format. There is no redundancy or fluff. The structure is well-organized and easy to scan.

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 moderate complexity (4 params, internal sub-tool call, no output schema), the description is complete. It explains the return format (ranked list with score, confidence, signal density), the role of parameters, and the use case. Annotations provide safety context, and the description fills the gaps left by the lack of 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%, but the description adds meaning beyond parameter descriptions. It notes that the first entity in the array is treated as the 'subject' for narrative purposes, and explains the 'context' parameter as disambiguating common names. This provides additional semantic context that helps an agent use the parameters correctly.

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: 'Compare AI visibility across multiple entities side-by-side'. It specifies the verb (compare/probe), the resource (AI visibility), and the outcome (ranked list). It distinguishes from sibling tools by explicitly mentioning that it calls 'ai_visibility_check' and frames it for competitive audits, differentiating it from single-entity checks or generic comparison tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear use case: 'Useful for competitive AI-marketing audits' and gives an example question. It implies when to use (multi-entity comparison) and suggests the first entity as subject. However, it does not explicitly state when not to use or directly contrast with sibling tools like 'compare_entities' or 'ai_visibility_check', leaving some implicit guidance.

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. Description adds critical behavioral details: partial failures degrade gracefully, bundlephobia first measurement can take 5-30 seconds, and sources_failed will list timed-out sources. 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?

Description is dense but well-structured. It front-loads the core purpose and then lists details. Could be slightly more concise but effectively uses space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description thoroughly lists return fields (summary block with specific metrics, per-advisory detail, links, alternative versions). Covers edge cases (partial failures, timing). Highly complete for a composite 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 covers both parameters with clear descriptions (package name, optional version). Description adds context: version defaults to latest, scoped packages accepted. This adds slight 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?

Description clearly states it is a composite check for npm package evaluation combining deps.dev and bundlephobia. It explicitly names the resources (license, advisories, version history, bundle size) and distinguishes from siblings by being npm-specific and composite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: when an agent asks about safety, popularity, size, or cost of adding an npm package. Also notes NPM-only in v1 and directs users to deps.dev:version 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?

Beyond annotations, describes embedding model, chunk strategy, character cap, offset feature, and truncation behavior. No contradiction with 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?

Three concise, front-loaded sentences covering purpose, usage, and technical details. 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?

Despite no output schema, description covers output format (passages, offsets, scores), technical constraints, and pairing context. Complete for a complex 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%, so baseline 3. Description adds value by providing query examples and confirming limit range, but largely repeats schema. Slight step above 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 does semantic search inside a fetched record, using specific verbs and resource. It distinguishes from siblings by naming ask_pipeworx_grounded and contrasting with using whole documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('when record is too big for prompt'), provides pairing advice, and mentions alternatives implicitly.

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 show idempotentHint=true, openWorldHint=true, non-destructive. Description adds behavioral details: OAuth requirement, phone verification, SMS cap, webhook auto-disable after failures. 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?

Single paragraph but front-loaded with core purpose. Contains all necessary information without unnecessary words. Could benefit from bullet points but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 params (nested), no output schema, the description covers all: required OAuth, all subscription types with examples, delivery channels with limitations, and return value. Leaves no ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with rich descriptions. The description adds even more: type-specific examples (e.g., sec_8k items, polymarket_edge topic), delivery options with details like webhook HMAC signing. Provides significant 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 'Create[s] a proactive monitoring subscription to a live-data event stream' and that it 'Returns the new subscription id.' The verb is specific (Create) and the resource is defined (proactive monitoring subscription). It 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?

Explicitly states requirement: 'Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions).' Also notes SMS cap (10/day) and phone verification. Lacks explicit when-not-to-use but context implies appropriate scenarios.

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, destructiveHint=false. Description adds context about returning categorized examples with tool shapes from a live catalog, and that it's an onboarding entry point, which is extra value beyond annotations.

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

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

The description is a single paragraph but well-organized: starts with example natural language queries, then explains return format, then usage instruction. It's informative though slightly lengthy; front-loading key points would improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by detailing return content: category-bucketed example questions with exact tool and argument shapes. Given low complexity (1 optional parameter), the description is complete and sufficient for the tool's purpose.

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% for the single optional 'topic' parameter (description lists values and effect). Description further explains that omitting gives full spread, and passing a topic focuses results, adding meaning beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns onboarding example questions categorized by topic, with specific verb 'returns' and resource 'category-bucketed example questions'. It distinguishes from siblings like ask_pipeworx by being the entry point for learning what to ask.

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 this FIRST' when not yet knowing what Pipeworx can do, and to learn how to call meta-tools. Provides when-not guidance implicitly by being the first step, and mentions optional topic parameter for focus.

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 key behavioral traits beyond annotations: ownership enforcement, soft deletion (deactivate), and availability of historical events via recent_alerts. Annotations (idempotentHint, destructiveHint) are consistent, and the description adds valuable 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?

Two sentences, no filler. Every sentence provides essential information: action, constraint, and effect. Highly concise and front-loaded.

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 1 required param, no output schema, and no nested objects, the description fully covers functionality, constraints, and side effects. Mentions related tool (recent_alerts) for further 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% with clear parameter description ('Subscription id (uuid) returned by subscribe'). The description does not add extra parameter semantics, but baseline is sufficient.

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 states 'Cancel a subscription by id' with a specific verb and resource. It clearly distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by describing the cancellation action.

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 that ownership is enforced (only cancel own subscriptions) and that the row is deactivated rather than deleted, providing context on when to use. It does not explicitly name alternatives or when not to use, but the guidance 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?

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds critical behavioral details: explains the meaning of could_not_verify (check did not happen, carries verification_error, must not be shown as evidence), distinguishes it from unsupported, and clarifies the two routing paths. This is essential context that annotations alone do not provide.

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

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

The description is long but highly structured and front-loaded with trigger phrases. Every sentence adds value: usage context, routing logic, return values, and caller warnings. No fluff or repetition; the length is justified by 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?

With no output schema, the description adequately describes return values (verdict types, actual value with citation, reasoning) and error semantics. It also covers the two processing paths and the replacements for sequential calls, making it self-contained for an agent to select and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds extra semantics for tolerance_pct, explaining how it overrides the implied tolerance and advising 1–2 for hallucination detection. This provides guidance beyond the schema, making the parameter more actionable.

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 fact-checking/claim verification tool with specific trigger phrases. It distinguishes between company-financial claims (SEC EDGAR/XBRL fast path) and other claims (grounded pipeline), which differentiates it from siblings like deep_research or ask_pipeworx_grounded.

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 usage guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also notes that it replaces 4–6 sequential calls, implying a consolidated alternative. However, it does not explicitly state when not to use it or name alternatives for exclusion.

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