Npi Registry

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds crucial behavioral context: default free model, BYO key for Anthropic with direct payment, and the structure of the return value. No contradictions with annotations.

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

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

The description is a single concise paragraph, front-loaded with the main purpose. Every sentence adds value, explaining defaults, optional behavior, return structure, and use cases 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 the tool's moderate complexity (4 parameters, no output schema), the description adequately covers inputs, behavior, return values, and use cases. The annotations provide strong safety guarantees, so the description is complete for an agent to use correctly.

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

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

Schema coverage is 100% with descriptive parameter descriptions. The tool description further enriches meaning by explaining the default model, when the _apiKey is needed, and how context helps disambiguate. Adds significant 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 probes LLMs for knowledge about an entity and returns a visibility score. It uses specific verbs ('probe', 'score') and distinguishes from sibling tools by focusing on visibility auditing rather than general Q&A or research.

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

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

The description lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) but does not explicitly state when to avoid this tool or contrast it with alternatives like compare_entities or deep_research. Provides clear context but no exclusions.

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

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

Annotations already provide readOnly, openWorld, idempotent hints. The description adds that it routes questions internally, returns structured answers with citation URIs, and is fast. No contradictions; description enriches agent understanding beyond annotations.

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

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

The description is fairly long but every sentence adds value. It starts with a bold usage directive ('PREFER OVER WEB SEARCH'), which is front-loaded. Could be slightly more concise, but it is well-structured and informative.

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 (routing to many sources, no output schema), the description covers all essential aspects: functionality, use cases, examples, alternatives, and citation format. It is complete for an agent to understand and invoke correctly.

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

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

Schema has 6 parameters all aliases for 'question' with 100% description coverage. The description adds general context about natural language questions but no new parameter-specific semantics beyond what the schema provides. 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 the tool routes questions to 5,563 tools across 1,462 sources for structured data with citations. It distinguishes from siblings by naming alternatives (ask_pipeworx_grounded, deep_research) and saying 'START HERE'. The purpose is clear, specific, and distinct.

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: 'PREFER OVER WEB SEARCH' with a list of domains (SEC filings, FDA, etc.) and query patterns. Also tells when to step up to ask_pipeworx_grounded or deep_research. This is comprehensive and actionable.

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

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

The description goes beyond annotations by disclosing that results are compared against a stable router for experimental evaluation, that it's a 'full working router' not a stub, and that it 'falls back to nothing.' This addresses the behavioral ambiguity of a beta tool. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description confirms with 'identical universal router' phrasing. No contradiction.

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

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

The description is a single paragraph of three sentences, each serving a distinct purpose: first defines the tool's identity and scope, second explains the current experimental state, third gives clear usage guidance. Every sentence adds essential information with zero redundancy or filler. The structure is front-loaded with the most critical comparison to the stable sibling.

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 that this tool has no output schema, high parameter coverage, and rich annotations, the description covers all essential aspects: identity, scope, relationship to sibling, current state, usage instructions, and behavioral guarantees. It does not need to describe return values as the response shape is 'identical' to the stable parent tool. The description is complete for an agent to select and invoke this 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 description coverage is 100% with comprehensive aliases documented. The description adds minimal value beyond the schema as it focuses on the tool's behavioral context rather than parameter details. Given the high coverage, the baseline is 3, but the description earns a 4 because it explains the relevance of the parameter ('Your question or request in natural language') and clarifies alias behavior, adding marginal contextual value.

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

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

The description explicitly states this is a 'beta version of ask_pipeworx' that serves as an 'identical universal router' with the same tools, arguments, and response shape. It clearly distinguishes itself from the stable sibling 'ask_pipeworx' by describing the candidate routing improvements and current inactive state. The specific verb 'ask' combined with 'universal router' clearly defines the action and 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?

The description provides explicit guidance: 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router to decide what merges. It also clarifies when not to expect differences ('No candidate is active right now') and states there is no fallback. This directly helps the agent decide between siblings.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint (all appropriate). The description adds significant behavioral context: exact refusal reasons (not_in_source, no_tool_match, etc.), the multi-step routing process, and the return structure (answer, evidence, confidence, source, fetched_at, refusal_reason). This exceeds annotation coverage, fully disclosing safety and failure modes.

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

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

The description is front-loaded with the high-value claim ('Hallucination-resistant answer mode'), then efficiently explains the routing, extraction, return format, use cases, and cost tradeoff in just a few sentences. Every sentence adds a distinct piece of information – no fluff, no repetition.

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 high complexity (routing across 5,563 tools, structured refusal, evidence extraction) and the lack of output schema, the description compensates fully by documenting the return format, refusal reasons, and use cases. It provides all behavioral and output details an agent needs to properly invoke and handle this 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% – all 6 parameters are documented as aliases for 'question'. The description adds context that the question is 'in natural language' and that the tool will use the question to route and extract answers. There is no new information beyond the schema aliases, but the schema already fully covers the parameters, so a 4 is justified (baseline 3 + 1 for the natural language hint).

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 verb ('Extracts the answer using ONLY what the tool result contains') and resource ('Hallucination-resistant answer mode for high-stakes reads'). It distinguishes from sibling 'ask_pipeworx' by explaining exactly how this variant differs (strict evidence extraction vs. casual lookup) and lists specific use cases (financial verdicts, legal claims, etc.).

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 tells when to use this tool ('whenever an answer will be quoted, cited, or acted on') and when not to ('prefer ask_pipeworx for casual lookups'). It also explains the cost tradeoff ('costs one extra LLM call vs ask_pipeworx'), giving the agent clear decision criteria.

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 (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) already indicate safe, non-destructive behavior. The description adds substantial behavioral context: market resolution via slug/URL/text, classifier fan-out with specific sources, response shapes (market analysis, evidence, resolver contract), safety (low-confidence short-circuit, closed market handling, wide-spread markers), and resolution-rule risk parsing. No contradictions with annotations.

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

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

The description is very long but well-structured with labeled sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.) and uses dashes for bullet points. However, it is verbose and could be more concise. Every sentence adds value, but the length may hinder quick scanning.

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

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

Given the complexity of the tool (multi-resource fan-out, classification, resolution), the description covers all critical aspects: input formats, classifiers with examples, response shapes for market, analysis, evidence, resolver contract (match confidence, alternatives, suggestions), parent event extraction, news fallback, safety edge cases (low confidence, closed markets, wide spreads), and resolution rules. No output schema exists, but the description explains returned fields sufficiently.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning: for 'market', it explains it can be a slug, URL, or question text; for 'depth', it defines 'quick' vs 'thorough' with default; for 'include_raw', it explains the trade-off and use cases. This enhances the schema descriptions.

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

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

The description begins with a clear verb-resource-action statement: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies that it resolves markets, classifies bets, and returns evidence packets with comparisons. Usage examples ('should I bet on X') and the classifier list further clarify the purpose.

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

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

The description explicitly states when to use the tool ('Use for should I bet on X...') and provides classifiers and fan-out examples. It explains safety mechanisms (low-confidence matches, closed markets) and resolution rules. While it doesn't explicitly state when not to use it, the context from sibling tools implies differentiation.

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

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

Annotations already indicate read-only, open-world, and idempotent behavior. The description adds substantial detail: specific data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. It does not discuss error handling or response format but provides good transparency.

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

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

The description is a single dense paragraph that front-loads with query examples. It contains no filler and every sentence adds value, though it could be slightly more structured (e.g., bullet points) for easier parsing. Still concise enough for an AI agent.

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 covers essential aspects: entity types, data sources, sorting, citations, and efficiency gains. It lacks details on error scenarios and response structure but is complete for typical use.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds significant meaning: for type it explains what data each enum value retrieves, and for values it gives concrete examples (tickers for company, drug names for drug) and reinforces the 2-5 limit.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs in a single call, with explicit example queries. It distinguishes from siblings by emphasizing preference over sequential lookups, and the sibling list includes entity_profile which is a single-entity tool.

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

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

The description provides clear guidance on when to use the tool (comparing 2-5 entities) and strongly recommends it over sequential lookups. It does not explicitly cover when NOT to use, such as limits beyond 5 entities, but the 2-5 range is stated.

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 (readOnlyHint, openWorldHint, idempotentHint), the description discloses account requirement, paid tier, parallel decomposition, return format (findings packet with verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, gaps[], contradictions[]), hop field, citation_uri condition, semantic excerpting, and expected latency (15-90s). 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 every sentence adds essential information. It is front-loaded with the critical account note and sign-in alternative. Despite the length, it is efficiently written with no filler, making it as concise as possible given 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 fully explains the return value structure: findings with evidence, confidence, source, timestamps, citations, gaps, contradictions (for standard/thorough), hop field, and citation_uri conditions. It also covers error cases (empty gaps[]) and performance expectations, leaving no ambiguity for an agent selecting or invoking the tool.

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

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

Schema coverage is 100%, yet the description adds meaningful context: for 'question' it clarifies that broad/multi-part questions are fine and decomposition is automatic; for 'depth' it explains the number of facets, gap-recovery hop, contradictions scan, and the paid requirement for 'thorough'. This goes well beyond the schema descriptions.

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

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

The description clearly states that the tool performs 'grounded multi-source research across Pipeworx's 1462 STRUCTURED data sources' in a single parallelized call. It explicitly distinguishes itself from siblings like ask_pipeworx (for single lookups or breaking news) and from open-web search, making the verb+resource+scope very specific.

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

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

Provides explicit guidance: use ask_pipeworx instead if not signed in, for single lookups, or for breaking/current-news topics. Also details when to choose each depth level, including the paid plan prerequisite for 'thorough'. This covers when-to-use, when-not-to-use, and alternatives.

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

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

Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns top-N relevant tools with names, descriptions, schemas, and that results are ready to call directly. No contradictions, and it adds useful 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?

The description is a single paragraph that efficiently states the purpose, lists domains, and explains output. It is front-loaded and every sentence adds value, though it could be more structured with bullet points.

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

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

No output schema exists, but the description compensates by detailing the return format (names, descriptions, schemas). It explains the tool's role as a first-step discovery tool. The limit parameter is noted in schema but not elaborated in description. Overall, it is sufficiently complete for a discovery tool with good annotations.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds value by explaining that results include schemas and are ready to call, but does not add meaning beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool finds tools by describing data or task, with a specific verb and resource. It distinguishes itself from siblings by being a discovery tool, and lists many domains it covers, making its purpose unambiguous.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear when-to-use guidance and implies it is for exploration before specific tools.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds rich behavioral details: the tool fans out across multiple datasources (SEC EDGAR, XBRL, USPTO, news, GLEIF), specifies return fields (cik, company_name, recent_filings with URIs, fundamentals sorted by period_end, patents with a sunset note, news via fallback chain, LEI), and mentions error handling ('soft-fails until reactivated' for patents). This exceeds what annotations alone 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 but not overly long for the complexity it explains. It front-loads with examples, then states the core behavior, then details the return components. Each sentence serves a purpose, though the list of return fields could be slightly more structured (e.g., bullet points). Still, it earns its length given the tool's scope.

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 there is no output schema, the description reasonably covers what the tool returns by listing fields and their sources. It mentions recent filings (up to 5 with URIs), fundamentals (specific keys and sort order), patents (with sunset caveat), news, and LEI. It does not describe the exact JSON structure, but the level of detail is adequate for an agent to understand what to expect. A perfect score would require output shape or an example.

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%—both parameters are documented in the input schema. The description adds value by clarifying that 'type' currently only supports 'company', and 'value' expects a ticker or zero-padded CIK (not names), and repeats the resolution fallback. While the schema already contains these constraints, the description provides additional context about the CIK format and the limitation on names.

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 numerous concrete examples like 'Tell me about X', 'research Acme', and specifies the exact scope: 'full cross-source profile of a US public company in ONE parallel call.' It clearly distinguishes itself from sibling tools by stating it should be preferred over chaining individual lookups for a holistic view, and explicitly contrasts with 'resolve_entity' for name 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 explicit guidance on when to use this tool ('ALWAYS PREFER over chaining single-pack... when user asks for a holistic view') and when not to use it ('names not supported — use resolve_entity first if you only have a name'). This directly helps an agent decide between this and sibling tools like resolve_entity or deep_research.

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 destructiveHint=true and idempotentHint=true; the description adds use-case context but no further behavioral traits like error handling or side effects.

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 concise sentences with all key information front-loaded. 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?

Sufficient for a simple tool with one parameter and no output schema. Mentions related tools and usage 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 a clear description for the only parameter. The tool description adds no extra meaning beyond 'memory key to delete'.

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

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

The description clearly states the action (delete a stored memory by key) and distinguishes it from siblings by referencing 'pair with remember and recall'.

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

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

Provides explicit when-to-use scenarios (stale context, task done, clear sensitive data) and references related tools, but does not mention 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?

Annotations already indicate read-only, idempotent, non-destructive. Description adds details: fetches page, extracts title/description/key links, emits single text blob. Contradiction false.

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

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

Two sentences plus a bulleted list of use cases, no redundancy. Purpose is 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?

Tool is simple with rich annotations and schema. Description covers purpose, behavior, output, and use cases. No missing information.

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

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

Schema coverage is 100% with descriptions for both parameters. Description does not add extra meaning beyond what schema provides, so baseline 3.

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

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

The description clearly states it generates an llms.txt file for a URL, explaining extraction and output format. It distinguishes from siblings like scan_competitor_ai_presence by focusing on file generation.

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

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

Explicitly lists three use cases: indexing client sites, drafting own project files, auditing competitors. Provides clear context for when to use, but no explicit when-not-to or alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds no behavioral context (e.g., response format, performance) beyond what annotations provide. A score of 3 reflects adequate but not enhanced transparency given annotation presence.

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 immediately conveys the core purpose. No extraneous information; every word earns its place.

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

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

Given the tool's simplicity (single parameter), presence of output schema, and thorough annotations, the description suffices. It covers what the tool does and the key constraint. Minor improvement could mention that it returns a full provider object, but output schema handles that.

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%: the input schema already describes the 'npi' parameter as '10-digit NPI'. The tool description repeats this without adding further details (e.g., format or validation rules). Thus, no additional semantic 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 the action ('Fetch') and the specific resource ('provider by 10-digit NPI'), including a precise constraint (10-digit). This distinguishes it from sibling tools like 'entity_profile' that might retrieve provider info by other means.

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 guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this is the tool for NPI-based lookups or that 'entity_profile' might be used for other identifiers. The agent receives no help in disambiguating tool 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 already indicate safety (readOnlyHint, no destructiveHint). The description adds value by listing specific return fields, but lacks details like pagination or rate limits. 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 two concise sentences: purpose and return info first, then usage guidance. No wasted words, front-loaded with key details.

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

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

Given the simple tool (1 optional param, no output schema), the description covers purpose, usage, return fields, and integrates annotations. It is fully sufficient for an agent to invoke correctly.

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

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

Parameter include_inactive is fully described in schema (100% coverage). The tool description adds no extra 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?

The description clearly states the verb 'list' and resource 'subscriptions', specifies returned fields, and distinguishes it from siblings like subscribe/unsubscribe by focusing on listing active subscriptions.

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

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

The description advises when to use: 'to review what you're monitoring before adding more or to find an id to cancel'. This provides clear context, though it could be more explicit about 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?

Annotations only indicate readOnlyHint=false, but the description adds substantial behavior: the claim_token flow for later retrieval, a 5-per-day rate limit, 'free and doesn't count against quota', daily reading by the team, and the roadmap impact. This far exceeds what structured annotations provide and reveals the tool's full life cycle.

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 ~150 words but every sentence earns its place: types, exclusions, claim_token usage, rate limit, and content guidance. It is front-loaded with the core purpose and uses punctuation and examples effectively for readability. No fluff or repetition.

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 4 optional params, 0 required, and no output schema, this description covers all nuances: feedback categories, optional context structure, claim_token retrieval, rate limiting, and the critical scope boundary (only Pipeworx connection tools). An agent will know exactly when and how to invoke it, and what to expect in return.

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 semantic baseline is met. The description adds critical extra guidance for claim_token (pass it back later with no other arguments to read status), which is a behavioral constraint not in the schema. Slight benefit over baseline, though the schema already documents each parameter well.

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 verb-resource pair ('Tell the Pipeworx team') and enumerates concrete feedback types (broken, missing, needs to exist). It distinguishes Pipeworx feedback from sibling tools by explicitly limiting it to tools served by this connection, making the purpose unmistakable.

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

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

It gives explicit when-to-use scenarios (bug, feature/data_gap, praise) and an explicit exclusion (other MCP servers' tools), plus guidance on what to write (describe in terms of Pipeworx tools/packs, don't paste the end-user prompt). This is exemplary usage direction with clear alternatives and boundaries.

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 convey readOnly, idempotent, non-destructive. Description adds valuable context: data source (CF analytics-engine), no PII, cached 5min-1h. Provides transparency beyond annotations without contradiction.

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

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

Concise three-sentence structure with front-loaded main action. Every sentence adds value: result, use cases, data source/caching. No fluff.

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

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

For a simple read-only tool with one optional parameter, the description covers purpose, usage guidance, parameter semantics, and data source/caching. No output schema needed given the simplicity and annotations.

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 window parameter. Description adds semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This enhances understanding beyond the enum values.

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, packs, and call volume over configurable windows. Verb ('returns') and resource ('Pipeworx trending data') are specific. Distinct from sibling tools like ask_pipeworx and deep_research, which have different purposes.

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

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

Explicitly lists three concrete use cases (discovering hot sources, confirming canonical choice, seeing alignment). Does not directly state when not to use, but use cases imply boundaries. Caching behavior mentioned adds guidance on data freshness.

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?

Despite annotations already indicating read-only, idempotent, and non-destructive behavior, the description adds rich behavioral context: semantic anchor (Jaccard similarity), partition filter (placeholder slugs), fill check against live CLOB depth, and realizable edge warnings. No contradictions with annotations.

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

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

The description is well-organized with sections for each mode and detailed subpoints. Every sentence adds value, covering modes, parameters, internal checks, output, and limitations. Despite length, it is information-dense and efficiently structured.

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

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

Given the tool's complexity and lack of output schema, the description thoroughly covers all aspects: modes, parameters, internal logic (Jaccard, partition filter, fill check), output fields, and links to related tools. It leaves no significant 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?

The input schema already describes each parameter, but the description adds significant meaning: examples of slugs, explanation of how event walks child markets and checks partition, and how topic searches related events. It clarifies the internal logic and output.

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 two modes (trending_scan, event, topic) and contrasts with sibling tools like polymarket_fill_risk.

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

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

The description provides explicit when-to-use guidance for each parameter: no args for trending scan, event for specific market, topic for cross-event scanning. It also directs users to polymarket_fill_risk for custom sizing, effectively differentiating from alternatives.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: caching behavior ('Cached 1h at the KV level keyed on all knobs'), response structure details (by_segment, diagnostics), and edge case handling (e.g., Fed bets excluded from ranking). This 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?

While lengthy, the description is well-structured with clear sections and front-loaded purpose. Every sentence provides useful information without redundancy. It could be slightly more concise, but the density of information 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?

The description fully addresses the tool's complexity (9 parameters, no output schema) by explaining response segments, model families, diagnostics, and parameter interactions. It covers edge cases like empty segments and Fed bets. No gaps are evident.

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

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

Schema coverage is 100% with each parameter described. The description adds extra context such as 'Polymarket has zero trading fees as of 2024 but bid/ask + thin depth typically eats 20-50bp per trade' for slippage_pp, and explanations of how filters interact (e.g., min_partition_leg_kelly details). This enhances 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?

The description clearly states it scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by explicitly framing itself as a discovery tool for 'what should I bet on today'.

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

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

The description provides context for when to use the tool (discovery of opportunities) but does not explicitly state when not to use it or compare it to alternatives like polymarket_edge_tracker for tracking historical edges or polymarket_arbitrage for pure arbitrage. Usage guidance is implied rather than explicit.

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 (readOnlyHint, openWorldHint, idempotentHint), description details response structure (tracked[], expired[], snapshot_dates[]) with field meanings, computational assumptions (daily closes of edge_pp_net, net default slippage, not intraday), and data gaps behavior. No contradictions with annotations.

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

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

Description is long but well-structured: starts with purpose, then explains response in three arrays with clear labels, and ends with limits. It is front-loaded with the core question. Slight verbosity in the middle but necessary for clarity.

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 and 2 well-documented parameters, the description provides a complete picture: what the tool returns (tracked, expired, snapshot_dates), field meanings, and limitations (60-day TTL, decay computation). No gaps remain for an agent to invoke correctly.

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

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

Schema coverage is 100% with both parameters fully described in schema (defaults, ranges). Description adds no new semantic value beyond restating the schema's info (e.g., days lookback and window family). 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 it provides edge persistence and decay telemetry, answering a specific question: 'how long has this edge existed and is it shrinking?' It distinguishes from sibling tool polymarket_edges by focusing on time-series and decay, not just current edges.

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

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

The description implies when to use this tool versus alternatives (e.g., polymarket_edges for current edges) by focusing on history and decay. It provides limits like 60-day snapshot TTL, but doesn't explicitly list when-not-to-use or name alternatives directly.

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 behavioral traits: walks the ladder, returns specific fields (verdict, thin_legs, forced_directional_risk). Warns about partial basket fills and thin books. Annotation readOnlyHint is consistent.

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?

Information-dense but slightly verbose. Front-loaded with purpose and key warnings. Uses capitalization for emphasis, but could be more streamlined.

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

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

Comprehensive: covers two modes, parameters, return fields (including edge cases like verdict, thin_legs). No output schema, so description compensates fully. Includes risk warnings.

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?

Adds meaning beyond schema: explains single-market vs basket modes, default sides, interpretation of size_usd differently per mode. Schema coverage 100%, but description provides essential 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?

Clear and specific: checks realizable-vs-theoretical edge against live CLOB depth. Distinguishes single-market vs basket modes. Differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by stating when to use it before them.

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: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains why (partial fills convert arb into directional risk).

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

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

Description extensively discloses behavior beyond annotations: explains compatibility_warning conditions, temporal alignment, skipped cross types, and that spreads are meaningless if alignment is false. Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, and description adds rich operational details.

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

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

Description is dense with information but well-structured: purpose, modes, response, safety fields. While slightly verbose, every sentence contributes value, and critical info is front-loaded (purpose and modes first). Minor redundancy in safety fields section could be trimmed.

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?

Tool complexity is high with no output schema. Description covers modes, response fields, safety warnings, and temporal alignment, but lacks a concrete output example or detailed explanation of return values beyond 'leg-by-leg prices' and 'top_spreads_pp'. Still, it provides sufficient context for typical use.

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

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

Schema coverage is 100% with descriptions for all 3 parameters. Description adds significant meaning: explains the two modes (topic vs explicit), how they interact (overrides), provides examples, and clarifies that topic is a shortcut. This exceeds mere schema repetition.

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 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It specifies the verb (compute/retrieve spread), resource (cross-venue spread), and distinguishes two modes (topic shortcuts vs explicit tickers), effectively differentiating it from siblings like polymarket_arbitrage.

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

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

Description provides clear usage context: two modes for matching events, and warns that most pre-mapped topics return compatibility_warning, implying explicit mode is often needed. However, it does not explicitly state when not to use or mention alternatives among 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 and idempotentHint. The description adds value by clarifying scoping (anonymous IP, BYO key hash, account ID) and the behavior of omitting the key to list all keys. 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 three sentences, each contributing essential information: main action, use case, scoping, and complementary tools. No filler or redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: purpose, usage, scoping, and related tools. 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% as the single parameter 'key' is described in the schema. The description rephrases the same info ('omit the key argument') without adding new meaning beyond context. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves a value saved via remember or lists all keys if no key is provided. It uses specific verbs ('Retrieve', 'list') and identifies the resource (saved keys/values). It distinguishes from siblings 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 the tool: to look up context stored earlier without re-deriving it. It mentions scoping and pairing with remember/forget. However, it does not explicitly state when not to use it or compare to other siblings beyond the memory triad.

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, but the description discloses mark_read side effects, aligning with idempotentHint. No contradiction; description adds transparency about the optional state change.

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 (5 sentences) and front-loaded with the main action. It efficiently covers purpose, parameters, and output 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?

Despite no output schema, the description explains return fields. It covers filtering, state management, and alternative access. Lacks pagination details but sufficient for a read 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%, and description adds value by giving examples (e.g., 'sec_8k'), explaining the timestamp format, stating default limit (50), and clarifying the mark_read behavior.

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 pulls fired events from a subscription feed and returns recent alerts with specific fields. It lacks explicit sibling differentiation but is specific enough to understand the tool's role.

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 guidance on filtering by type and timestamp, using mark_read for state management, and mentions polling. Does not explicitly exclude scenarios or compare to siblings, but offers practical 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?

The description discloses multiple behavioral traits beyond annotations: parallel call to multiple sources, fallback behavior, soft-fail for USPTO, date parsing options, and structured output format with grouped changes and citation URIs. This adds significant context beyond the readOnlyHint and other 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, starting with example queries and proceeding logically through sources, parameters, and return format. Every sentence adds necessary context, though a slight tightening 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 the complexity of the tool (multiple sources, fallback, date parsing), the description is highly complete. It explains sources, fallback logic, date format, output structure, and provides a clear alternative tool, fully equipping an agent to use it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by providing examples for the `value` parameter (ticker or CIK), explaining the only accepted `type` (company), and recommending typical monitoring periods for `since`. These enrich the schema definitions.

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 the tool provides a change feed for a company in a recent time window, using example queries like "What's new with X". It distinguishes from sibling tool `entity_profile` by specifying that the latter is for static profiles regardless of window.

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 guidance, including example queries and a specific alternative (`entity_profile`). It also provides parameter advice (e.g., 'Use "30d" or "1m" for typical monitoring') and explains fallback logic (GDELT preferred, GNews when rate-limited).

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds important behavioral details beyond annotations: scoped by identifier, persistent vs anonymous sessions, 24-hour retention for anonymous. No contradictions.

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

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

The description is three sentences, each serving a distinct purpose: purpose/usage, when to use, and behavioral details. No redundant or extraneous text. Front-loaded with the core action.

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

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

Given the simple tool (2 params, no output schema), the description covers all necessary context: purpose, usage triggers, scope, persistence, and pairing with other tools. No gaps.

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

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

Schema coverage is 100% with parameter descriptions. The description adds value by giving key naming conventions (e.g., 'subject_property') and clarifying value as 'any text'. This provides contextual guidance beyond the raw schema.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later'. It provides concrete examples of what to store (resolved ticker, target address, preferences) and explicitly distinguishes from siblings 'recall' and 'forget'.

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

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

The description gives explicit guidance on when to use: 'Use when you discover something worth carrying forward'. It also tells what not to do indirectly by specifying it's for data the agent needs to reuse. Pairs with recall and forget, providing a complete usage 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 declare the tool read-only, open-world, idempotent, and non-destructive, but the description adds substantial behavioral detail: it explains the cross-source identity spine (CIK, LEI, FIGI), that unresolved identifiers are explicitly listed under `unresolved`, and that enrichment degrades gracefully when GLEIF/OpenFIGI are unavailable. This goes far beyond what annotations provide.

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

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

The description is long but every sentence carries unique information – query examples, purpose, usage directive, supported types, return details, fallback behavior, and internal cascading. It is well-structured and front-loaded with the most important points, with 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 lacking an output schema, the description gives a detailed account of what is returned for each type: CIK/ticker/company name/LEI/FIGI with source labels and unresolved handling, and RxCUI/ingredient/brand with a citation. It covers fallback behavior and scope, making the tool's behavior fully predictable.

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 important parameter semantics: it documents that ISIN is an accepted input format for `value` (missing from the schema) and explains that an ISIN resolves to the legal entity via GLEIF mapping. It also clarifies input formats with concrete examples, adding real 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 starts with multiple query examples and immediately states the core purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It explicitly says 'Use FIRST whenever you have a name but need an ID,' making the tool's function unambiguous and distinguishing it from general search or entity profile 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 clear when-to-use guidance: 'Use FIRST whenever you have a name but need an ID' and gives concrete query patterns. However, it does not explicitly mention when not to use this tool or name alternatives like search or entity_profile, so it stops short of a full 5.

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

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

Description explains probing process, ranking, and output details (score, confidence, signal density) beyond what annotations provide. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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 concise sentences with front-loaded purpose. Every sentence adds value without redundancy.

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

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

Covers purpose, method, parameters, return value (ranked list with specific fields). No output schema but description sufficiently explains expected results. Complete for a tool with 4 parameters.

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?

Adds meaningful context beyond schema: first entity treated as subject for narrative, default model is workers-ai, anthropic requires API key. Schema coverage is 100%, but description enriches each parameter's usage.

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

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

Specific verb 'Compare AI visibility' with clear resource 'multiple entities side-by-side'. Distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison) by specifying the use of ai_visibility_check probes and ranking.

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 use case for competitive AI-marketing audits with a concrete example question. However, does not explicitly state when not to use or mention alternatives beyond the example.

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, idempotent, not destructive. The description adds significant behavioral details: partial failure handling, bundlephobia timeout (5-30s), and graceful degradation with sources_failed.

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 well-structured. The first sentence summarizes the tool's purpose. However, some parts (e.g., listing output fields) could be slightly more concise. Still efficient overall.

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

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

Despite no output schema, the description fully explains the return structure (summary, per-advisory, links, alternative versions) and behavior on failure. Adequate for a tool with 2 parameters and no nested objects.

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 describes both parameters with 100% coverage. The description adds that version defaults to latest when omitted, providing minor extra context 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 performs a composite check for adding npm packages, combining deps.dev and bundlephobia. It distinguishes itself from siblings by specifying the exact use case and 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 states when to use: when an agent asks about safety, popularity, size, or cost of an npm package. Also notes limitations (NPM only in v1) and alternatives 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?

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, so the description's additional note about filter requirements adds useful context without contradicting annotations. The tool's safety profile is effectively communicated.

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

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

The description is two sentences: the first states the general purpose, the second adds a critical usage constraint. No wasted words, front-loaded with key information.

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

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

Given the high schema coverage, existence of an output schema, and annotations, the description is adequately complete. It covers the essential constraint. Minor improvement could be adding why the filter requirement exists, but not necessary.

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?

With 71% schema description coverage, the schema documents most parameters well. The description adds no new parameter information beyond listing suggested filter fields, which is already implicit in 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 the tool searches for providers using any combination of fields. It specifies the resource ('providers') and the action ('search'), distinguishing it from sibling tools like 'get_provider' which likely retrieves a single record.

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

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

The description provides clear context that the NPI Registry requires at least one filter, listing acceptable fields. While it does not explicitly mention when not to use this tool or name alternatives, the requirement gives practical usage 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 indicate readOnlyHint, openWorldHint, idempotentHint, and not destructive. The description adds valuable behavioral details: uses BGE-base-en embeddings with cosine similarity over 500-char overlapping windows, a 200K char cap with truncation flag, and every passage includes character offsets for verification. This goes well beyond the annotations.

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

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

The description is concise (under 100 words), front-loaded with the core purpose, and every sentence adds value without repetition or fluff. It efficiently conveys the mechanism, limits, and usage guidance.

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 rich annotations and schema, the description is fully adequate. It explains the embedding/chunking details, the document size cap, and the return format (passages with offsets and scores), even though there is no output schema. It also clarifies integration with ask_pipeworx_grounded.

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. The tool description adds examples for the query parameter, notes the cap for text, and explains the limit meaning. This adds marginal value beyond the schema, justifying a slight upgrade from baseline 3.

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

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

The description clearly states the tool does semantic search inside a fetched record, with a specific verb and resource. It differentiates from sibling tools like search and ask_pipeworx_grounded by explaining its use case (searching inside a retrieved document) and pairing with the latter.

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 tells when to use this tool: when a record is too large to fit in the prompt, saving context. It also mentions pairing with ask_pipeworx_grounded. However, it does not provide explicit when-not-to-use or alternative scenarios, slightly reducing the score.

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

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

The description adds behavioral details beyond annotations: it requires OAuth, mentions SMS daily cap, phone verification, and webhook auto-disable after 10 failures. Annotations already mark it as not readOnly, not destructive, and idempotent; the description complements these without contradiction, providing useful operational context.

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

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

The description is front-loaded with the main action and returns value, then covers requirements, types, and delivery details in a logical order. Although it is somewhat lengthy, every sentence contributes meaningful information, and the structure is clear and scannable.

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

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

Given the tool's complexity (3 parameters, nested objects, enum values, multiple delivery options) and no output schema, the description explains the return value, prerequisites, type options, and delivery constraints. It misses explicit mention of idempotency behavior but is otherwise complete for practical use.

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

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

With 100% schema description coverage, the description adds significant value by providing concrete JSON examples for each subscription type (e.g., sec_8k with item codes, polymarket_edge with topic) and detailed delivery channel behavior (e.g., webhook signing, SMS cap). This enriches the schema information.

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 creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It distinguishes itself from sibling tools like list_subscriptions (for listing) and unsubscribe (for removal) by specifying the creation action and resource type.

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

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

The description provides clear context: requires a Pipeworx OAuth account, differentiates delivery channels (feed always on, email/sms optional with constraints), and mentions alternative ways to pull alerts (recent_alerts or GET endpoint). It does not explicitly state when not to use it versus siblings, but the purpose and prerequisites are well covered.

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 behavioral context on return structure (category-bucketed examples with exact tool shapes) and that it draws from a live catalog.

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 includes many alternative phrasings and details but remains well-organized and front-loaded with purpose. Slightly verbose for maximum conciseness but no wasted sentences.

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

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

Complete description covering purpose, usage, return format, parameter semantics, and when to invoke. Given no output schema, it sufficiently explains what the tool returns.

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

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

Schema has full coverage for the optional 'topic' parameter. Description enhances with examples ('finance', 'pharma', 'betting') and clarifies that omitting gives a cross-category spread.

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 as an onboarding entry point for new users, listing what Pipeworx can do and returning category-bucketed example questions. It distinguishes itself from siblings by being a meta-tool for learning.

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 to use it first when unfamiliar or to learn about meta-tools. Provides context like 'call with no arguments for full spread' and optional topic filtering, but does not directly contrast with every sibling.

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 that the row is deactivated (not deleted) and that historical events remain via recent_alerts, which goes beyond the annotations (readOnlyHint=false, destructiveHint=false). This provides clear insight into the tool's non-destructive mutation behavior.

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

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

Three concise sentences with no unnecessary words. Every sentence provides essential information: action, ownership constraint, and effect on data. Front-loaded with 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 has only one parameter, no output schema, and well-covered annotations, the description fully addresses what the agent needs: purpose, ownership, and behavioral impact (soft deactivation). No gaps remain.

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

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

The input schema has 100% coverage with a description for the 'id' parameter. The description only repeats 'by id' without adding additional semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description clearly states 'Cancel a subscription by id,' which is a specific verb and resource. It distinguishes itself from sibling tools like 'subscribe' and 'list_subscriptions.'

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

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

The description explicitly states ownership enforcement: 'you can only cancel your own subscriptions.' This provides a clear precondition, though no explicit when-not-to-use or alternative tools are mentioned. The context is sufficient given the sibling 'subscribe.'

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

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

Annotations already declare readOnly/openWorld/idempotent, but the description adds substantial context: the dual execution paths (SEC vs grounded), the verdict taxonomy, and the crucial distinction between could_not_verify (didn't run) and unsupported (no source exists). This goes well beyond the safety hints and helps the agent interpret results correctly.

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 trigger phrases and purpose, and every sentence carries useful information. However, it is quite long and the list of example phrases could be trimmed without losing meaning. Still, for a multi-path tool, the length is mostly justified.

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 covers what to expect: verdict types, actual value with citation, reasoning, and detailed explanations of could_not_verify and unsupported. It also explains the fallback routing, making it complete for an agent to decide on this tool.

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

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

Schema coverage is 100% with detailed parameter descriptions (claim example, tolerance_pct range and default). The tool description adds a bit about percent-delta math and hallucination detection, but this is largely redundant with the schema. No significant new semantic value beyond what the schema already provides.

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

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

The description opens with explicit trigger phrases and states the verb-resource pair: 'natural-language claim verification against authoritative sources.' It clearly distinguishes itself from siblings by noting it replaces 4–6 sequential calls and returns a verdict, unlike search or deep_research.

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

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

It explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also provides routing rules for company-financial vs. other claims and warns about could_not_verify semantics, giving clear when-to-use and when-to-be-cautious guidance.

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