Hagstova Fo

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

Annotations indicate read-only, idempotent, and open-world hints; description adds significant behavioral detail: probes multiple models, scores 0-100, returns per-model breakdown, requires Anthropic key for that model, and explains cost implications. No contradictions.

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

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

Three sentences efficiently cover purpose, model options, and output structure with no redundant information. Front-loaded with key action and outcome.

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 clearly indicates return format (per-model {score, confidence, signals, raw_response} + combined view). Parameters are fully described with schema and supplemented text. Use cases and warnings about API key are included, making it self-sufficient for an AI agent.

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

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

Schema coverage is 100%, but description adds value by explaining defaults (Workers AI Llama-3.3-70b free), that _apiKey is passed through to Anthropic, and that context helps disambiguate. This goes beyond schema descriptions.

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

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

The description clearly states the tool probes LLMs to score brand visibility with a specific verb (Probe) and resource (LLMs). It distinguishes from siblings like scan_competitor_ai_presence by focusing on general AI visibility audits rather than competitor-specific scanning.

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

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

The description explicitly lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains default model vs. BYO key for Anthropic. It does not explicitly state when not to use or compare to alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the base safety profile is documented. The description adds significant context: it routes questions to 5,564 tools across 1,462 sources, returns structured answers with citation URIs, and handles a wide set of queries. It does not, however, detail rate limits or auth requirements, which would push it to a 5.

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 key purpose, but it is somewhat long and includes parenthetical examples and detailed sibling comparisons that could be condensed. Every sentence earns its place, but the length reduces scannability slightly.

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 (broad domain, many siblings, no output schema), the description covers purpose, usage guidelines, behavioral traits, and parameter semantics thoroughly. The absence of an output schema is compensated by clear examples of what the tool returns (structured answers with citation URIs).

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

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

Schema coverage is 100% with 6 parameters, all aliases for the same 'question' field. The description adds value beyond the schema by explaining that the parameter accepts natural language requests and giving concrete examples of questions they could ask, which clarifies the semantic scope of the input.

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 primary function: routing questions to a vast set of authoritative sources and returning structured answers. It lists specific data domains (SEC filings, FDA drugs, etc.) and distinguishes itself from siblings by recommending alternatives for specific use cases (e.g., ask_pipeworx_grounded for high-confidence answers).

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 the AI when to prefer this tool over web search, provides example queries, and includes step-up guidance to sibling tools (ask_pipeworx_grounded, deep_research) with clear conditions for each. It also notes that this tool works on all tiers and is a fast default, giving the agent strong 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 already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint (false). The description adds valuable operational context: it is a full working router under experimental edge, with candidate routing improvements applied live when under test, and currently matches the stable version. No contradiction with annotations.

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

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

The description is moderately concise, packing key information about beta purpose, current state, and usage into a few sentences. It is front-loaded with the core identity. Slightly verbose due to specific numbers and dates, but every sentence adds value; could be tightened slightly without losing meaning.

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

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

Given the tool's complexity (router to 5,564 tools) and rich annotations, the description covers what it does, when to use, current state, and fallback behavior. There is no output schema, but the description implies the response shape matches ask_pipeworx. Completeness is high for an experimental variant of a well-known sibling.

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

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

Schema description coverage is 100%, with all parameters (question and aliases) already documented in the input schema. The description does not add further parameter meaning, but the schema fully covers the single required parameter and its aliases, so baseline 3 is appropriate.

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

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

The description clearly identifies the tool as a beta version of ask_pipeworx, a universal router to 5,564 tools. It uses specific verb 'ask' and resource 'Pipeworx Beta', and distinguishes it from sibling ask_pipeworx by labeling it experimental with candidate routing improvements.

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 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router to decide merges. It also notes that currently no candidate is active, making it identical to the stable version, guiding the agent on when to choose this tool over 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=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: the extraction logic, explicit refusal reasons (e.g., 'not_in_source', 'no_tool_match'), and the extra LLM call cost. Minor gap: does not mention data truncation handling beyond the refusal field.

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

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

The description is detailed but efficient for the complexity, covering purpose, cost, safety guarantees, and usage. Could slightly improve by starting with the core use case more directly, but it remains well-structured.

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

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

Given the annotations and rich schema, the description fully covers the tool's role as a grounded answer mode for high-stakes queries, including refusal behavior and trade-offs, without needing an output schema.

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

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

The input schema has 100% coverage, listing all 6 parameters with descriptions. The description notes that all accept a free-form question but does not add additional semantics like formatting expectations 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 is a 'hallucination-resistant answer mode for high-stakes reads' that extracts answers only from tool results, distinguishing it from its sibling 'ask_pipeworx' which lacks this guarantee.

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

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

Explicitly advises use for high-stakes queries (financial, legal, medical) where facts must be cited, and recommends preferring 'ask_pipeworx' for casual lookups due to extra cost, providing clear when-to-use and when-to-avoid 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?

The description extensively discloses behavior: fan-out patterns, response shapes, safety short-circuits, market cancellation rules, and more. It goes well beyond the annotations (readOnlyHint, idempotentHint, etc.) without contradiction.

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

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

The description is lengthy but appropriately so for the tool's complexity. It front-loads the core purpose and then systematically covers edge cases. A bit verbose but every section 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 lack of output schema, the description provides comprehensive context: market matching, parent event extraction, news fields, safety mechanisms, resolution rules, and tradeability warnings. It enables correct agent invocation.

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

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

All three parameters have schema descriptions (100% coverage). The description adds practical examples for 'market', explains 'depth' and 'include_raw' in context, and clarifies when to use enriched payloads.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input formats and output goals, distinguishing it from sibling tools like polymarket_edges.

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

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

Explicit usage cues are given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' The description also explains when to inspect confidence fields and how closed markets are handled, though it could mention when not to use the tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value: explains that company type pulls latest 10-K financials and handles off-calendar fiscal years, and drug type pulls FAERS and FDA data. No contradiction with annotations.

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

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

Description is somewhat long but packs essential information. Front-loads purpose and usage hints. A few minor redundancies but overall efficient for the complexity.

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

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

No output schema, but description explains return format: paired data, citation URIs, sorted by primary metric. Covers both entity types in detail. For a tool with simple parameters and no nested objects, it is very complete.

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

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

Schema coverage is 100% (both parameters described). Description adds examples ('AAPL','MSFT' for company; 'ozempic','mounjaro' for drug) and constraints (maxItems 5). Explains what data each type pulls, adding meaning beyond schema.

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

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

The description clearly states the tool provides side-by-side comparison of 2-5 companies or drugs. Uses specific verbs like 'compare' and refers to the resource (companies/drugs). Distinguishes from sibling tools like entity_profile by emphasizing parallel call vs sequential lookups.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides natural language examples like 'which is bigger / better / larger'. Clearly indicates when to use this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds significant behavioral context: it returns findings with evidence, confidence, source, fetched_at, pipeworx:// citations, gaps[], contradictions[] for certain depths, semantic excerpting, hop field, and timing expectations (15-90s). The only minor gap is not explicitly stating that results are non-deterministic over time, though openWorldHint=true covers that.

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

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

The description is comprehensive but slightly verbose at ~350 words. Key information is front-loaded (account requirement, alternative, core function), but the fine details on hop mechanics and citation behavior could be condensed. Every sentence serves a purpose, though some technical depth might overwhelm an 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?

For a complex tool with 2 parameters, no output schema, and rich annotations, the description is remarkably complete. It covers prerequisites, alternatives, decomposition behavior, return format, citations policy, timing, depth behaviors, and edge cases (gaps for unsupported topics). The absence of an output schema is compensated by the description's detailed explanation of the findings packet structure.

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

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

Schema coverage is 100%, and the description adds substantial meaning beyond enum labels: for depth, it details the exact behavior difference (quick=3 facets single hop, standard=3 with gap recovery + contradictions, thorough=6 with paid iterative chasing). For question, it clarifies natural language queries with broad/multi-part decomposition as the point, which the schema doesn't convey.

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

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

The description clearly states the tool performs grounded multi-source research across Pipeworx's 1462 structured data sources, decomposing questions into facets and routing to 5,564 tools in parallel. It distinguishes from siblings by explicitly contrasting with ask_pipeworx (single lookup, news), and lists specific use cases like comparing regulatory and financial exposure.

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 (broad/multi-part questions over structured data) and when-not-to-use (single lookup use ask_pipeworx, breaking news/current events prefer ask_pipeworx). Includes alternative tool names with reasoning, plus prerequisites (free account, sign-in, paid plan for thorough depth).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns top-N relevant tools with full schemas and curated examples, ready to call directly without a second lookup. No contradiction with annotations.

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

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

Description is concise and well-structured. It front-loads the main purpose, provides domain examples, and includes a clear usage directive. Every sentence serves a purpose 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 the return format (top-N tools with names, descriptions, full input schemas, and curated examples) and states results are ready to call. This provides sufficient context for a discovery tool.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions the 'query' parameter with aliases and the 'limit' parameter, but does not add significant extra meaning beyond what the schema already provides (e.g., limit default and max are already in schema).

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

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

The description explicitly states 'Find tools by describing the data or task' and provides a detailed list of covered domains (SEC filings, financials, FDA drugs, etc.). It distinguishes from sibling tools by positioning itself as a discovery meta-tool to be called first.

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 instructs to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' clearly indicating when to use. It does not explicitly state when not to use, but the guidance is sufficient for most scenarios.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds context beyond annotations: details the fan-out across multiple sources, lists specific return fields, mentions soft-fail for USPTO API sunset, and specifies input requirements. 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 moderately long but every sentence adds value. It is front-loaded with example queries, then states purpose, then details behavior. Could be slightly more concise, but it's 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 complexity (multiple source aggregation) and lack of output schema, the description provides comprehensive information about return fields (CIK, filings, fundamentals, patents, news, LEI), including edge cases like USPTO sunset. It adequately covers all needed context for 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 coverage is 100%, so baseline is 3. Description adds value beyond schema by explaining the 'type' enum constraints and providing examples for 'value' (ticker or CIK). It also clarifies that names are not supported, which is not explicit in the schema description.

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: 'full cross-source profile of a US public company in ONE parallel call'. It uses specific verbs ('profile') and resources ('entity'), and distinguishes from siblings like resolve_entity by noting that names are not supported.

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

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

Explicitly advises when to use: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also tells when not to use: 'names not supported (use resolve_entity first if you only have a name).'

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. Description adds context about clearing sensitive data, which is consistent with annotations. No contradictions.

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

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

Two sentences, efficient and zero waste. 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?

For a simple tool with one parameter, no output schema, and good annotations, the description covers purpose, usage, and pairing. Complete.

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

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

Schema coverage is 100% with description for the 'key' parameter. Description adds no extra meaning beyond the schema, so 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?

Description states 'Delete a previously stored memory by key' – specific verb and resource, and distinguishes from sibling tools 'remember' and 'recall'.

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

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

Explicitly specifies when to use: 'when context is stale, the task is done, or you want to clear sensitive data.' Also mentions pairing with sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context that the tool fetches the page, extracts title/description/links, and emits markdown, which is consistent and informative 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 front-loads the purpose, provides process details, and ends with use cases. It is reasonably concise but could be slightly more structured (e.g., 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?

Given the tool's simplicity (2 params, no output schema) and rich annotations, the description fully covers input, process, output, and use cases. It is complete and leaves no ambiguity.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions max_links and extraction of links, adding marginal value over the schema descriptions. It does not introduce new parameter constraints or format details.

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: generate an llms.txt file for a given URL, specifying the output format and use cases. It distinguishes itself from sibling tools by its unique function.

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

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

The description provides explicit use cases (getting sites indexed, drafting own llms.txt, auditing competitors). It lacks 'when not to use' or alternative tool references, but the given guidance is sufficient for the specific tool.

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

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

Description adds context (returns specific fields, caller's subscriptions) on top of annotations that already declare read-only and idempotent behavior. 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?

Two sentences: first covers purpose and output, second gives usage guidance. No superfluous words; concise and front-loaded.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description fully covers purpose, return fields, 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 of the single optional parameter. Description does not add further meaning to the parameter.

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

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

Clearly states it lists the caller's active subscriptions and enumerates the return fields (id, type, etc.), distinguishing it from sibling tools like subscribe/unsubscribe.

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

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

Provides explicit contexts for use: before adding subscriptions or to find an id for cancellation. Lacks exclusion guidance but is otherwise helpful.

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

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

With annotations all false, the description carries the full burden of behavioral disclosure. It richly details the claim_token return/read flow, rate limit (5 per identifier per day), free usage, no quota impact, daily digests, and roadmap influence. It also advises describing issues in terms of Pipeworx tools rather than pasting end-user prompts, which is a behavioral constraint beyond the schema.

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 block of text but is well-front-loaded with the core purpose. Every sentence adds value: usage conditions, exclusions, token flow, rate limits, and impact. While it is longer than average, the complexity of the tool (dual submission/retrieval, multiple feedback types) justifies the length, and the structure flows logically. A small deduction for being slightly dense rather than concise.

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

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

Despite having no output schema and neutral annotations, the description covers all critical context: behavior, usage boundaries, rate limiting, cost, token retrieval, and how the feedback is processed. The claim_token mechanism is explained sufficiently for an agent to understand both how to submit and how to follow up. No significant gap is apparent.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it clarifies how to use claim_token by showing the exact invocation pattern, and it adds the instruction to describe issues in terms of Pipeworx tools/packs and not paste end-user prompts. This goes beyond the schema's parameter descriptions, earning a 4.

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

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

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' which clearly states the primary action (sending feedback) and the resource (Pipeworx team). It also covers the secondary use of reading replies via a claim_token, making the full purpose unambiguous. This clearly distinguishes it from sibling tools like ask_pipeworx or research tools, as it is the only feedback submission/review 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 explicit when-to-use guidance: bug, feature/data_gap, or praise. It also gives a clear exclusion by stating it is ONLY for tools served by this Pipeworx connection and directs users to file issues with other MCP servers elsewhere. The 'Not sure? Pipeworx tool names are the ones this connection lists' further clarifies how to determine applicability.

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, destructiveHint. Description adds 'self-aggregating signal derived from CF analytics-engine, no PII' and 'cached 5min-1h', which enriches understanding beyond annotations.

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

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

Concise, well-structured: purpose first, then bulleted use cases, then data details. Every sentence adds value. No redundancy.

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

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

With only one optional parameter, no output schema, and rich annotations, the description covers purpose, usage, behavior, and caching. Complete for its complexity.

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

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

Schema coverage is 100%, and description adds context by explaining how window length affects results (shorter windows surface hot trends, longer show steady-state demand). This adds meaning beyond the enum description.

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

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

Clearly states it returns top tools, packs, and call volume over configurable windows (24h, 7d, 30d). Distinguishes itself by focusing on trending/aggregate data, unlike sibling tools that handle specific queries or actions.

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

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

Lists three specific use cases (discovering hot data sources, confirming canonical tools, detecting alignment). Does not explicitly state when not to use or mention alternatives, but the use cases are concrete and the tool's scope is clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint. Description adds rich behavioral detail: monotonicity checks, partition-sum verification (sum≈1), Jaccard similarity threshold (≥0.30), placeholder filtering, fill check with CLOB depth, and conditions for suggesting trades. 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?

Well-structured with front-loaded purpose, then detailed breakdown of modes and special behaviors. Some redundancy (e.g., explaining partition_check in two places) but every sentence adds essential information for an agent to use the tool correctly. Slightly verbose but justified by 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?

For a complex arbitrage detection tool with no output schema, the description thoroughly explains all aspects: input modes, algorithmic details (monotonicity, partition sum, Jaccard similarity, placeholder filter), output structure (opportunities array, partition_check fields), and fill check behavior. Covers edge cases like realizable_edge ≤ 0 and thin legs. 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?

Both parameters (event, topic) are fully documented in schema with descriptions. The description adds significant value: explains event slug format and examples, topic as seed question, semantic anchor for topic, partition filter logic, and output structure. Complements schema completely.

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

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

Description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes (trending_scan, event, topic) and provides specific use cases, differentiating from sibling tools like polymarket_edges and 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?

Explicitly advises when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. Explains cross-event mode catches patterns single-event misses. Lacks explicit 'when not to use' for sibling comparisons but still provides clear 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 goes far beyond annotations (readOnlyHint, openWorldHint, idempotentHint) by revealing caching behavior ('Cached 1h at the KV level'), internal model details (e.g., lognormal barrier, GDELT ratios), placeholder-slug filters, Fed bet exclusion rationale, and diagnostic fields. This level of detail fully informs the agent of the tool's behavior.

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

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

The description is lengthy but well-structured: it opens with a clear purpose, then organizes content by model families, output fields, knobs, and response structure. While verbose, every section adds necessary detail for a complex tool with no output schema.

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

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

Given the tool's complexity (9 parameters, no output schema), the description is exceptionally complete. It explains the three response segments, diagnostic fields, caching, edge calculations, and tradeable-edge knobs. No critical aspect is left ambiguous.

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 coverage, the description does not need to repeat parameter details, but it adds value by contextualizing 'Tradeable-Edge Knobs' and explaining how parameters like min_kelly and max_spread_pp interact with the output segments. 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 the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It explicitly names the target use case ('what should I bet on today') and distinguishes itself from sibling tools like polymarket_arbitrage by focusing on edge detection with specific model families.

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 strong usage context ('agents discover opportunities without paging hundreds of markets'), but does not explicitly state when to avoid this tool or compare with siblings. However, the detailed explanation of output segments and knobs implicitly guides appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and not destructive. The description adds valuable behavioral details: data comes from daily snapshots with 60-day TTL, gaps exist when scans don't occur, decay is computed from daily closes (not intraday), and trend/decay calculations are based on absolute edge_pp_net. 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 thorough but not overly verbose. It starts with the core purpose, then details the response structure and limits. Every sentence provides distinct value, though the response format explanation is quite detailed. Could be slightly more concise, but it's well-organized.

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

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

Given no output schema, the description comprehensively explains the response: tracked[], expired[], snapshot_dates[] with field meanings (first_seen, trend, decay_pp_per_day, lifespan_days). It also covers data freshness (60-day TTL), snapshot gaps, and computation details. Parameter semantics are clear. No missing 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 description coverage is 100% for both parameters. The description adds context: default values (14 days, '1wk'), range for days (clamp 2-30), and clarifies that window is a snapshot family. This goes beyond the schema's 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's purpose: edge persistence and decay telemetry from daily snapshots. It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes from the sibling polymarket_edges tool by focusing on time-series analysis rather than raw edge values.

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

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

The description explains that a fresh wide edge and a 3-week-old wide edge are different trades, implying the tool is for assessing edge quality over time. It doesn't explicitly specify when not to use, but the context makes it clear this is for historical decay analysis rather than current edge discovery.

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, open-world, idempotent, non-destructive. Description adds rich behavioral detail: walks the ladder, returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict; per-leg fill details, thin_legs, forced_directional_risk in basket mode. Warns about partial basket fills converting arb into directional positions.

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 relatively long but well-structured: starts with purpose, then requirements, then explains both modes in detail, ending with usage guidance. Each sentence adds value and the front-loading is effective. A slight trim could improve conciseness, but it is appropriate for the complexity.

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

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

Given the tool's complexity (two modes, 4 parameters, no output schema), the description is fully self-contained. It explains inputs, outputs (lists return fields for both modes), behavioral nuances, and warnings. No gaps remain for an agent to misinterpret.

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 beyond schema: explains default for side in basket mode (auto based on partition sum), distinguishes size_usd interpretation between single-market (spend/target) and basket (settlement notional), and mentions clamping range. However, schema already covers basics 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 clearly states it's a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It ties directly to sibling tools like polymarket_arbitrage and polymarket_edges, making its purpose and differentiation explicit.

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 instructs 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why (theoretical overround not capturable, partial fills create directional risk). Provides clear when-to-use and when-not-to-use 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?

Beyond annotations (readOnlyHint, idempotent, not destructive), the description details safety fields such as compatibility_warning, temporal_alignment, and skipped_cross_type/subtype counters. It explains potential mismatches (bet shape inequivalence, temporal misalignment) and clarifies that the tool explicitly states when no arbitrage exists.

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

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

The description is dense but well-organized: purpose first, then modes, response format, and safety fields. Each sentence adds value, though the length is slightly above what is strictly necessary. It earns a 4 for efficient communication without wasted text.

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 (multiple modes, cross-venue logic, safety warnings), the description is highly complete. It covers return values (per-venue prices, spreads, compatibility fields) since there is no output schema. Examples in the input schema further aid understanding.

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

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

Schema description coverage is 100%, so the schema already documents each parameter's meaning. The description reinforces the two modes and lists valid topic values, but does not add significant depth beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It specifies two modes (topic shortcuts and explicit event tickers) and distinguishes it from sibling tools like polymarket_arbitrage. The verb 'compute' and resource 'spread' are specific and unambiguous.

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

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

The description explicitly explains when to use the tool (to compare prices across venues) and provides guidance on two modes with their appropriate contexts. It warns that real spreads are rare and pre-mapped topics often return compatibility warnings, effectively telling the agent when not to rely on the results.

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

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

Adds critical behavioral info beyond annotations: PxWeb enforces cell limits, so query dimensions must be narrowed. The description also specifies the exact JSON structure, which is not in annotations.

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

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

Two sentences, front-loaded with main action, then critical details with zero unnecessary text.

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?

Fully explains the tool's role, includes all necessary details for an API call, and points to a related tool (table_meta) for completing the workflow. No output schema needed as return format is described.

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 reinforces the body format and path example. Adds context about cell limits and relationship to table_meta, which enriches parameter understanding.

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

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

Clearly states the tool POSTs a PxWeb query to a Hagstova Føroya table and returns observations as json-stat2. Distinguishes from sibling table_meta by specifying data retrieval vs metadata.

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 body format and warns about PxWeb cell limits, advising to narrow selections using codes from table_meta. Lacks explicit 'when not to use' but gives strong 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds extra behavioral context: 'Scoped to your identifier (anonymous IP, BYO key hash, or account ID).' This goes beyond annotations and 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?

The description is concise (4 sentences) and front-loaded with the primary action. 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?

Given the simple tool (1 optional parameter, no output schema), the description explains behavior well. It could mention return value format (e.g., string or list) but is still fairly complete.

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

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

Schema coverage is 100% with a clear description for the 'key' parameter. The tool description reinforces the parameter behavior ('omit to list all keys') and adds scoping context, adding value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It uses a specific verb ('Retrieve') and resource ('value previously saved'), and distinguishes from sibling tools like remember and forget.

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

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

The description explicitly says when to use the tool: 'Use to look up context the agent stored earlier... without re-deriving it from scratch.' It also provides context on scoping and pairs with remember/forget, giving clear guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: each event carries source, citation_uri, and payload; mark_read behavior; and polling suitability. 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?

The description is concise and front-loaded with the main action. Each sentence adds essential information without repetition. No unnecessary filler.

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

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

Despite no output schema, the description details what each event carries (source, citation_uri, payload), filtering options, and the mark_read trick. It also mentions an alternative API endpoint, making it complete for this tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning: it specifies 'type' example ('sec_8k'), 'since' as ISO timestamp, and explains the 'mark_read' flag's effect. This enriches parameter understanding.

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

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

The description starts with 'Pull fired events from your subscription feed,' providing a clear verb+resource combination. It distinguishes itself from siblings like 'list_subscriptions' (which lists subscriptions themselves) by focusing on the actual alert events.

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

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

The description explicitly mentions that polling works fine and provides an alternative URL for scripts and dashboards, giving usage context. It does not explicitly state when not to use this tool versus others, but the context is sufficient.

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 fan-out to multiple sources, fallback behavior (GDELT to GNews), and USPTO soft-fail due to API sunset. Annotations already indicate readonly and idempotent; description adds valuable behavioral context without contradiction.

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

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

The description is front-loaded with example queries and every sentence provides unique value. It is appropriately sized for the tool's complexity, neither verbose nor too brief.

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 (multiple sources, fallback, return format), the description covers all essential aspects: inputs, behavior, return structure (changes array, total count, citation URIs), and version caveats. No output schema needed as return format is described.

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

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

Schema coverage is 100%; the description adds meaning with detailed explanation of the `since` parameter (ISO date and relative shorthand, example recommendations), and clarifies that `type` only supports 'company'. This 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's purpose as a change feed for a company over a time window, with example queries. It distinguishes itself from the sibling tool `entity_profile` by specifying when to use each.

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

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

Explicit usage guidance is provided: when to use (e.g., 'What's new with X') and when not to use (use `entity_profile` for static profiles). Alternatives are named.

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 idempotent and non-destructive write. Description adds scoping by identifier, persistence details (24-hour for anonymous), which are useful beyond annotations. No contradictions.

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

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

Three sentences, efficient, front-loaded with purpose. Every sentence adds value.

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

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

For a simple key-value storage tool with good annotations and schema, the description covers usage, context, behavior, and ties to sibling 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 covers both parameters with descriptions. Description does not add new detail beyond schema, so baseline score of 3 applies.

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

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

Description clearly states the tool saves data for later reuse, with specific verb 'save' and resource 'data as key-value pairs'. It distinguishes from siblings like recall and forget.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward'. Mentions pairing with recall and forget. Provides context on persistence based on authentication, but lacks explicit when-not scenarios.

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

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

The description discloses significant behavioral details beyond the annotations: identifiers are labeled with source, unresolved identifiers are explicitly listed under `unresolved`, enrichment degrades gracefully if external sources are unavailable, and internal cascading is mentioned. This is rich context despite the readOnlyHint already being present.

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

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

The description is front-loaded with examples and purpose, but it is a long, dense paragraph. Most sentences provide value, though there is minor redundancy with the schema (e.g., repeating accepted input types). Breaking it into bullet points would improve scannability, but it is not overly padded.

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 what identifiers are returned, how unresolved ones are handled, enrichment sources and degradation behavior, and internal cascading. This is highly complete for a tool of this complexity.

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

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

Although schema coverage is 100%, the description substantially enriches parameter semantics by specifying accepted input forms (ticker, CIK, ISIN, company name for company type; brand or generic name for drug type) and explaining special cases like ISIN-to-LEI mapping. This adds meaning beyond the schema's basic descriptions.

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

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

The description clearly states the tool's purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It provides concrete trigger examples, distinguishes from siblings by emphasizing identifier resolution, and is specific about supported entity types.

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 guidance is given: 'Use FIRST whenever you have a name but need an ID.' It also explains when to use company vs. drug types, accepted input formats, and notes that using this tool replaces 2-3 manual lookups, making alternatives implicit.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. Description adds output structure (score, confidence, signal density) and notes it probes via ai_visibility_check, providing operational insight 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?

Three concise sentences: first states main purpose, second explains mechanism and result, third gives example use case. No wasted words, 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?

Despite no output schema, description fully covers input parameters (4, with required entities), behavior (comparison via ai_visibility_check), and return type (ranked list with metrics). Sufficient for confident tool selection and invocation.

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

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

Schema provides full parameter descriptions (100% coverage). Description adds key context: first entity treated as 'subject', models may require Anthropic key. Adds meaning beyond schema.

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

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

Description clearly states it compares AI visibility across multiple entities side-by-side, distinguishes from single-entity tool ai_visibility_check. Verb 'Compare' + resource 'AI presence' with specific ranking outcome.

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 use case: competitive AI-marketing audits. Implies when to use (comparison) but does not explicitly exclude cases like single-entity analysis or 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?

Discloses that it fans out to two external services (deps.dev and bundlephobia), handles partial failures gracefully, and notes that bundlephobia's first measurement may take 5-30 seconds. This adds substantial behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint).

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 (around 120 words) and well-structured, front-loading the core function, then usage, return content, and limitations. Every sentence contributes meaningful information 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 that there is no output schema, the description adequately covers return fields (summary block, advisory details, links, alternative versions), behavior on partial failures, and ecosystem scope. It is complete enough for an agent to understand what to expect, though the exact format could be slightly more explicit.

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?

While the input schema already describes both parameters with 100% coverage, the description adds value by clarifying that scoped packages (e.g., '@types/node') are accepted and that the version defaults to the latest if omitted. This is useful nuance beyond the schema.

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

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

The description clearly states the tool's purpose as a composite npm package evaluation check, combining license, security advisories, version history, and bundle size analysis. It distinguishes from sibling tools by focusing exclusively on npm dependency analysis.

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

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

Explicitly advises using the tool when an agent asks about safety, popularity, or size of an npm package, and mentions that ecosystem alternatives exist (PyPI, Maven, Cargo, Go fall under deps.dev). Provides clear when-to-use and when-not-to-use 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?

Discloses embedding model (BGE-base-en), windowing (500-char overlapping), character cap (200K with truncation flag), and return fields (offsets, similarity scores). Annotations already declare safety; description adds rich behavioral detail beyond them.

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?

Front-loaded with core purpose, then succinctly adds details in two sentences. Every sentence adds value (usage guidance, technical details, pairing). 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?

With 3 parameters and no output schema, the description explains behavior, constraints, output contents (passages, offsets, scores), and pairing. 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?

Schema coverage is 100%. Description adds defaults, ranges (1-20, default 5), examples for query, and reinforces the 200K cap for text. Provides value beyond schema without redundancy.

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 verb ('search') and resource ('inside a fetched record'). Provides specific context: semantic search over text, returning passages with offsets and scores. Distinguishes from sibling 'ask_pipeworx_grounded' by explaining pairing, implying different use.

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

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

States when to use: when record is too large for prompt. Mentions pairing with ask_pipeworx_grounded as alternative workflow. Does not explicitly say when not to use, but context suffices.

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, destructiveHint, etc. The description adds value by explaining the tree structure (folders type 'l', tables type 't', id ends '.px') and behavior for empty vs. non-empty paths, which is 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 three sentences: purpose, details, and next steps. Every sentence is necessary and there is no redundancy. It is 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?

For a simple browsing tool with one parameter and rich annotations, the description is complete. It explains input behavior, output format (implicitly), and how to proceed, covering all needed context even without an output schema.

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

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

With schema description coverage at 100%, baseline is 3. The description adds context like 'Empty path returns the database list; drill into 'H2'' and examples, enhancing meaning beyond the schema's 'Sub-path under the API base'.

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: browsing the Statistics Faroe Islands PxWeb subject tree. It specifies the verb 'browse' and the resource 'subject tree', and distinguishes it from sibling tools like query_table and table_meta by noting that the output path is used to call 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?

The description provides clear usage guidance: empty path for database list, drilling into 'H2' for folders/tables, and using the returned path for subsequent tools. It does not explicitly list exclusions or alternatives, but the context is strong.

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 side effects (create, returns id), account requirement, delivery channel constraints (SMS verification, 10/day cap, webhook auto-disable after 10 failures). Annotations are consistent (write, non-destructive, idempotent). Adds context well 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?

Front-loaded with purpose, then logically organized into requirements, types, and delivery channels. No superfluous sentences; each part adds necessary detail for a complex tool.

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

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

Covers return value, type details, and delivery options well. Missing output schema means agent must infer exact response shape, but description provides key fields. Could mention error handling or validation constraints, but overall adequate.

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

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

Schema coverage is 100%, but description adds richer examples and explains type-specific parameters (e.g., items codes, topic, series_id). Some redundancy with schema, but provides practical usage context.

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

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

Clearly states 'Create a proactive monitoring subscription to a live-data event stream' with specific verb and resource. Distinguishes from sibling tools like list_subscriptions and unsubscribe by action and output (returns subscription id).

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?

Specifies requirement for Pipeworx OAuth account and lists supported types with examples. Implicitly shows when to use (to start monitoring), but lacks explicit when-not-to-use or alternatives beyond mentioning account limitations.

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 confirm safe, read-only, idempotent behavior. Description adds valuable behavioral details: returns live-catalog examples, no arguments gives full spread, and includes meta-tool learning. No contradictions.

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

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

Description is front-loaded with synonyms and purpose, then details return structure and usage. While comprehensive, it is slightly verbose but each sentence adds distinct value. Could be trimmed slightly but well structured.

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

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

With one optional parameter and comprehensive annotations (readOnly, openWorld, idempotent), the description fully covers when to use, what it returns, and how to call. No output schema needed as return values are described in prose.

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

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

Schema coverage is 100% with description for the 'topic' parameter. Description adds usage patterns (omit for full spread, pass topic to focus) that go beyond the schema's enum-like description.

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

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

The description clearly states the tool returns category-bucketed example questions with exact tool+argument shapes. It is explicitly positioned as the onboarding entry point, distinguishing it from siblings like ask_pipeworx or entity_profile.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and advises passing topic to focus. It provides clear context but does not enumerate alternative tools for specific scenarios.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that it returns dimensions with codes and value lists, but does not disclose error behavior, rate limits, or authentication needs. 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?

Two sentences, front-loaded with purpose and essential format requirement. No fluff; every sentence is 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?

For a simple tool with one parameter and no output schema, the description adequately explains what it does, what it returns, and how it relates to query_table. Lacks error handling info but acceptable for this complexity.

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

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

Schema coverage is 100% with one parameter described generically. Description adds critical format constraint (path must be full and end in '.px') and provides an example, adding value beyond the schema description.

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

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

Clearly states it fetches dimension definitions and coded values for a specific domain (Hagstova Føroya PxWeb table). Links to sibling query_table by noting it is required input for building a query body, distinguishing its role from that 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?

Implies usage before query_table to obtain metadata, but does not explicitly state when to use vs alternatives or provide when-not conditions. Offers format guidance (path ending in '.px') but lacks exclusion 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?

Adds details beyond annotations: ownership enforcement, row deactivation, historical events preserved. Consistent with annotations (readOnlyHint=false, destructiveHint=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 clear sentences, no fluff, efficiently conveys all necessary 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?

Covers purpose, ownership, effect, and historical impact. Complete for a single-parameter tool with no output schema.

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

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

Schema coverage is 100%; description adds context by noting id is 'returned by subscribe', linking to another tool.

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

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

Description uses specific verb 'Cancel' and resource 'subscription', clearly distinguishing 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?

States ownership enforcement and effect (deactivation, not deletion), but does not explicitly mention when not to use or compare to alternatives.

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

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

Annotations already signal read-only, open-world, idempotent, and non-destructive behavior. The description goes far beyond this by disclosing critical behavioral nuances: the distinction between `could_not_verify` (verification failure) and `unsupported` (no source coverage), the inclusion of `verification_error{stage,detail}`, the directive to never treat `could_not_verify` as evidence, and the internal routing logic. This is rich transparency that adds significant value.

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

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

The description is a single dense paragraph but every sentence contributes useful information, from example intents to error semantics to pipeline replacement. It could be slightly more structured with line breaks, but it is not redundant or padded. For a complex tool, this length is justifiable.

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 carries the burden of explaining return values: it lists all verdicts, mentions the literal value with `pipeworx://` citation, and explains reasoning. It also covers both categories of claims (company-financial and all other) and clarifies failure modes. Given the tool's complexity, the description is complete enough for an agent to know what to expect.

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

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

The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds extra semantic value for `tolerance_pct` by explaining its default behavior (implied by wording, capped at 5) and giving a concrete use case (1–2 for hallucination detection). The `claim` parameter is not further elaborated, but the schema examples cover it, so this exceeds the baseline.

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

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

The description clearly identifies the tool as a natural-language claim verifier, with explicit examples of user intents ("fact check", "verify the claim that…"). It distinguishes the tool from siblings by describing its internal routing (SEC EDGAR fast path for company financials, grounded pipeline for all other claims) and its unique verdict output, making it unmistakable what this tool does.

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 states to use the tool "whenever the agent needs to check whether something a user said is factually correct," providing clear context. It also explains when the internal fast path applies vs. the general grounded pipeline, but it does not explicitly name alternative tools or state when NOT to use it, so it falls short of a 5.

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