Edmtrain

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: the default model is free, Anthropic requires BYO key and direct payment, and the return structure includes per-model and combined views.

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: first states the main purpose and output, second adds parameter details, third lists use cases. Every sentence adds value, with no wasted words.

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

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

For a tool with four parameters and no output schema, the description covers the main behavior, return format (per-model and combined), and use cases. It does not discuss limitations or edge cases, but given annotations and context, it is sufficiently 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?

All four parameters are fully described in the schema (100% coverage). The description adds value by explaining the default model, clarifying that _apiKey is optional and for Anthropic only, and providing examples for entity and context. This goes 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 action ('Probe one or more LLMs') and the resource ('what they know about a business / brand / product / topic'), and includes specific output (score 0-100). It distinguishes from sibling tools by focusing on visibility scoring across multiple models, unlike ask_pipeworx or deep_research.

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

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

The description provides usage context ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains when to optionally use Anthropic with a key. However, it does not explicitly mention when not to use this tool or suggest alternatives among siblings.

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

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

Annotations already establish read-only, idempotent, and open-world semantics, so the bar for additional behavioral disclosure is lower. The description adds valuable context beyond those annotations: it routes to a specific set of verified sources, fills arguments automatically, returns structured answers with stable pipeworx:// citation URIs, and works on every tier with one fast call. It does not discuss rate limits or failure modes, which would push it to 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 longer than average but front-loads the most critical guidance — 'PREFER OVER WEB SEARCH' and the scope statement — before examples and alternative routing. Nearly every sentence earns its place, though the trigger-phrase list ('what is', 'look up', 'find', etc.) is slightly redundant with the examples. It remains appropriately structured for a complex default-entry-point 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?

For a tool with no output schema, the description does explain the return shape: structured answer with stable citation URIs. It also covers scope, trigger conditions, tier availability, and step-up alternatives. It does not describe error behavior or how the tool handles ambiguous questions, but for the stated purpose of helping an agent select and invoke the tool, coverage is strong.

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

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

Schema coverage is 100% and all six parameters are documented as aliases for 'question'. The description's examples illustrate appropriate query content, but it adds no parameter-level meaning beyond what the schema already provides. Per the baseline for high schema coverage, this is correctly a 3.

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

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

The description opens with a strong directive — 'PREFER OVER WEB SEARCH' — and names the resource domain precisely (SEC filings, FDA drug data, FRED/BLS statistics, USPTO patents, etc.). It also distinguishes this tool from siblings by describing it as the default router to 5,689 tools, while explicitly naming ask_pipeworx_grounded and deep_research as alternatives for different use cases.

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

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

The description gives explicit when-to-use guidance: 'Use whenever the user asks...' with concrete example phrasings. It also states when to step up to alternatives — ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part questions — and clarifies that breaking-news questions should still use ask_pipeworx. This is exemplary routing guidance.

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

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

Beyond the annotations, the description discloses that this is an experimental edge, that candidate routing improvements may be live, that no candidate is currently active, and that it currently matches ask_pipeworx exactly. It also clarifies that it is a full working router with no fallback, adding meaningful context.

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

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

The description is three sentences and front-loads the core definition, then adds current status and usage guidance. The detail is mostly earned, though the specific retirement date and count of tools add minor noise and the final sentence partially restates the 'full router' idea.

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 is identical to a sibling, pointing to ask_pipeworx for arguments and response shape is reasonable. It conveys experimental status, current equivalence, and routing purpose, but an agent without prior knowledge of ask_pipeworx would need to consult that sibling for fuller details.

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

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

Schema coverage is 100%, with all six parameters documented as aliases for the single required 'question' field. The description adds only 'same arguments' as a reference to ask_pipeworx, so it does not materially exceed what the schema already provides.

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

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

The description states a specific verb and resource: it is a beta version of ask_pipeworx, an identical universal router with the same 5,689 tools, arguments, and response shape. It clearly differentiates itself from the stable ask_pipeworx sibling by noting candidate routing improvements may be active.

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

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

The description explicitly says to use it exactly like ask_pipeworx when you want the newest routing and explains that results are compared against the stable router. It gives clear context but does not explicitly enumerate when not to use it or directly name the stable alternative as the exclusion case.

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 well beyond the annotations by explaining the exact success return shape, the explicit refusal reasons, the verbatim evidence requirement, and the extra LLM call overhead. This gives the agent a precise model of grounding behavior and failure modes without contradicting the read-only/idempotent annotations.

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

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

The description is dense but well-ordered: core mode first, then return contract, then use cases, then cost tradeoff. Every sentence adds decision-relevant information, and there is no filler or restatement of the title.

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

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

With no output schema, the description fully explains the return contract, including refusal reasons and success fields. It also gives operational context: routing scale, evidence requirement, cost tradeoff, and the scenarios that justify using this tool. This is complete for an agent deciding whether and how to invoke it.

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

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

The input schema already documents the question parameter and all aliases at 100% coverage, so the description does not need to repeat parameter details. It focuses on behavioral semantics instead, which is acceptable given that the schema fully carries the parameter documentation burden.

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 a specialized answer mode: a grounded, hallucination-resistant read that routes through the Pipeworx toolset and extracts the answer only from fetched tool results. It distinguishes itself from the sibling ask_pipeworx by emphasizing the strict evidence/refusal contract and high-stakes use case.

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

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

It gives explicit when-to-use guidance: whenever an answer will be quoted, cited, or acted on, with concrete domains such as financial verdicts, legal claims, medical lookups, and public statements. It also states when not to use it by recommending ask_pipeworx for casual lookups and notes the extra LLM call cost.

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 provides extensive behavioral details beyond annotations: fan-out logic per classifier, resolver contract (confidence scores, alternatives), parent event extractor, news fallback mechanisms, safety short-circuits, illiquid spread warnings, and resolution-rule risk analysis. Annotations already declare readOnly and idempotent, and the description adds rich context.

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

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

Description is comprehensive but quite long. It is organized into sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.), which aids readability. However, some redundancy and excessive detail could be trimmed without losing essential information.

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

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

Given the tool's complexity (3 parameters, no output schema, rich annotations), the description covers all critical aspects: input handling, execution behavior, return shapes, edge cases (low confidence, closed markets, wide spreads, cancellation rules), and safety mechanisms. It compensates fully for the lack of an output schema.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the 'market' parameter accepts multiple formats (slug, URL, question text) and provides examples. For 'depth' and 'include_raw', the description reinforces and contextualizes the schema descriptions, making them more actionable.

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

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

Description clearly states the tool researches Polymarket bets, specifies inputs (slug, URL, question text), and outlines outputs (evidence packet + market-vs-model comparison). It distinguishes itself from siblings by being a dedicated research tool for Polymarket bets, with specific fan-out behavior.

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

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

Explicitly states when to use (e.g., 'should I bet on X', 'what does the data say about Y') and provides numerous examples. Does not explicitly mention when not to use or alternatives, but the specificity is high enough for effective selection.

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

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

The description discloses detailed behavior: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), specific metrics pulled (revenue, net income, etc.), handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with citation URIs. This enriches the annotations which already indicate read-only and idempotent nature.

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

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

The description is a single well-organized paragraph: user query examples, core function, preference guidance, data details, output format. Every sentence adds information without redundancy, making it highly efficient for an AI agent.

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

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

Despite no output schema, the description fully covers return values (paired data + citation URIs), sorting, and data sources. With only 2 parameters and clear input constraints, it provides a complete picture for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the data pulled for each type and providing concrete examples for values (tickers/CIKs for companies, drug names). This practical guidance goes beyond schema 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 clearly states the tool performs side-by-side comparisons of 2–5 entities (companies or drugs) in a single parallel call, with specific examples like 'compare X and Y' and 'rank these companies'. It distinguishes itself from sequential single-entity lookups, making purpose unmistakable.

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

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

The description explicitly advises to prefer this tool over sequential single-pack lookups when comparing entities, and provides trigger phrases like 'which is bigger' or 'head to head'. It does not list exclusions but the guidance is strong and clear, eliminating guesswork.

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?

Even though annotations already declare read-only/open-world/idempotent behavior, the description adds substantial operational context: parallel decomposition across 5,689 tools, gap[] reporting rather than invention, citation resolvability rules, semantic excerpting, contradiction scans, depth-specific hop behavior, and latency expectations. There is no contradiction with the annotations.

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

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

The description is long, but it is dense and information-rich with no filler. Every sentence contributes operational or selection-relevant detail. It is somewhat run-on and would benefit from bullets, but the front-loaded account requirement and the tight cause-effect progression of depth modes keep it effective.

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

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

For a complex tool with no output schema, the description fully covers what an agent needs: account prerequisites, return packet contents, gaps[] and contradictions[] semantics, citation guarantees, latency, and explicit exclusions for current news and simple lookups. Combined with the rich schema, it provides a complete operational picture.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it shows appropriate question shapes ('compare X and Y's regulatory + financial exposure') and clarifies how depth values influence second-hop gap recovery and lead chasing. It does not fully re-document the parameters, but it adds enough to make parameter selection easier.

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

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

The description states a clear verb and resource: deep, grounded multi-source research across Pipeworx's 1,489 structured data sources in one call. It also explicitly distinguishes itself from open-web search and from ask_pipeworx, so an agent can identify its unique role without opening schemas.

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

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

The description gives explicit when-to-use guidance: broad/multi-part structured-data questions for deep_research, single lookups for ask_pipeworx, and breaking/current-news topics for ask_pipeworx. It even covers the account/paywall condition and names the fallback tool for signed-out users.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details: returns top-N most relevant tools with names, descriptions, and full input schemas, each result ready to call directly. No contradictions, and it enriches understanding beyond annotations.

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

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

The description is a single paragraph that front-loads purpose and usage. It is efficient but could be slightly more structured. Every sentence adds value, no waste.

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

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

Given the tool has no output schema, the description fully explains the return format (names, descriptions, full schemas) and the use case. It covers the necessary context for an agent to use the tool effectively.

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

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

Schema coverage is 100% with all parameters described. The description does not add significant new meaning for parameters beyond stating that they are aliases and providing examples. The high schema coverage means the description is not required to elaborate, but it does not go above baseline.

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

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

The description clearly states the verb 'Find' and resource 'tools', and distinguishes itself from sibling tools by being a meta-tool for discovery. It explains that it returns relevant tools with full schemas, making its purpose specific and distinct.

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

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

The description explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for...' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear guidance on when to use and implies when not to (when you already know 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 indicate read-only, idempotent, open-world. Description adds detailed behavior: fans out across multiple sources, returns specific fields (cik, filings, fundamentals, patents, news, LEI), notes patents API may sunset (soft-fails), and limitations. 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 rich and front-loaded with examples, but slightly verbose. However, every sentence adds value, and the structure is logical. A minor reduction for length, but still highly effective.

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

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

Despite no output schema, the description thoroughly explains return fields (cik, company_name, recent_filings, fundamentals, patents, news, LEI) and limitations. Two required parameters are fully covered. Context is complete for a complex profile tool.

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

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

Schema coverage is 100%, but description adds significant context: 'Pass ticker "AAPL" or zero-padded CIK "0000320193" — names not supported (use resolve_entity first if you only have a name).' This clarifies input format and provides fallback guidance, exceeding schema alone.

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

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

The description clearly defines the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It provides multiple example queries and explicitly distinguishes it from chaining separate lookups, making the purpose unambiguous.

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

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

Explicit guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also states unsupported input: 'names not supported (use resolve_entity first if you only have a name).' Clearly defines when and when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds specific behavioral detail: events within ~75 miles when using lat/long. This goes beyond what annotations provide, though it could mention result ordering or default limit 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?

Two sentences, concise and front-loaded. Every sentence adds value: first states core function, second explains region specification and optional filters. No wasted words.

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

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

Given 9 optional parameters and no output schema, the description gives a complete overview of input modes and filters. References sibling 'locations' tool for location_ids. Could mention that results are a list of events, but that is implied. Nearly 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%, so baseline is 3. The description groups parameters (region specification, date window, name, festivals-only) but does not add significant meaning beyond the schema descriptions and examples. It provides a useful summary but no deep parameter insights.

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

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

The description clearly states the tool finds upcoming electronic/dance events, concerts, and festivals. It explicitly distinguishes region specification (lat/long vs location_ids) and mentions filtering options, leaving no ambiguity about its purpose.

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

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

The description provides clear when-to-use guidance for finding electronic events by region, with two methods of region specification. It does not explicitly mention when not to use (e.g., for past events or other genres), but the context is sufficient for typical use cases.

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

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

Description discloses destructive nature and motivation for deletion. Consistent with annotations (destructiveHint=true, idempotentHint=true). Adds context beyond annotations.

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

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

Two sentences: first states purpose, second provides usage guidance. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and behavioral 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 already describes the 'key' parameter. Description mentions 'by key' but doesn't add additional meaning or constraints beyond schema. Schema coverage is 100%.

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 deletes a memory by key. It uses specific verb 'Delete' and resource 'memory', and distinguishes from siblings 'remember' and 'recall'.

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

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

Provides explicit when-to-use scenarios: stale context, task done, clear sensitive data. Also mentions pairing with remember and recall. Lacks explicit when-not-to-use.

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

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

Annotations indicate readOnly, openWorld, idempotent, and non-destructive. The description adds that it fetches the page, extracts title/description/key links, and emits standard markdown format. This provides behavioral detail beyond annotations, though it doesn't discuss error handling or rate limiting.

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 front-loaded with purpose, then process, then use cases. Every sentence adds value without redundancy or fluff. The structure is efficient and scannable.

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

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

No output schema exists, but the description explains the output as 'a single text blob ready to drop at site-root/llms.txt', which is sufficient. For a simple generation tool with two params and clear annotations, the description covers input, process, and output completely.

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

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

Schema coverage is 100% with both parameters described. The description adds context for 'url' (site or landing page) and 'max_links' (default 25, max 50), plus the example format. This adds meaning beyond the schema's property descriptions.

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

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

The description clearly states the tool generates a 'production-ready llms.txt file' for AI crawlers, specifying the verb 'generate' and resource 'llms.txt'. It distinguishes itself from sibling tools by focusing on a specific AI indexing task, which none of the other 40+ siblings address.

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

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

The description lists three explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor. It implies when to use (when needing llms.txt) but doesn't explicitly state when not to use or mention alternatives. However, the context is clear enough for an AI agent.

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

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

Annotations already declare readOnlyHint and destructiveHint, making the safety profile clear. The description adds value by listing the exact fields returned (id, type, params, etc.) and the effect of the include_inactive parameter, without contradicting 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 concise sentences: the first states functionality and return values, the second gives usage guidance. Every sentence adds value with no fluff.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description fully covers its behavior, return format, and usage context. Annotations provide the remaining behavioral traits.

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 for the single parameter include_inactive, so the description need not add further semantics. The description implies its behavior (including inactive subscriptions) but does not repeat 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 'List the caller's active subscriptions,' which is a specific verb and resource. It distinguishes from sibling tools like subscribe and unsubscribe, which are for adding or removing subscriptions.

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

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

The description explicitly advises using this tool to review subscriptions before adding more or to find an ID for cancellation. This provides clear context for when to use it, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal behavioral context beyond scope (North American metros) and the fact it's a list. No contradiction, but little extra 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?

Two sentences, front-loaded with the verb 'List', and every sentence is informative with no unnecessary words. Highly concise and 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 simple one-parameter tool with comprehensive annotations and no output schema, the description is complete: it lists the return fields, explains usage with events, and defines scope. No gaps identified.

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 good parameter description. The description reinforces that the query filters by city/state keyword, adding no new details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists EDMtrain-supported metro locations with specific fields (id, city, state, lat/long). It distinguishes from the sibling 'events' tool by mentioning using location id with it.

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

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

The description provides clear usage context: use this tool to get location IDs for the events tool, and optionally filter by city/state. It also specifies geographic coverage (North American metros). It does not explicitly exclude alternatives, but the guidance 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?

Despite having useful annotations, the description adds substantial behavioral context beyond them: the claim_token workflow for later follow-up, rate limiting ('5 per identifier per day'), and cost implications ('Free; doesn't count against your tool-call quota'). It also reveals how feedback is processed ('team reads digests daily'), which helps set expectations. 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 comprehensive yet economical. Every sentence adds distinct value: purpose, usage triggers, exclusions, content guidance, claim_token mechanics, processing cadence, rate limit, and cost. It is front-loaded with the core purpose and structured as a logical flow from 'what' to 'how' to 'policy'. No fluff or redundancy.

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

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

Given the tool's moderate complexity (4 parameters, multiple feedback types, optional nested context, and a claim-token follow-up pattern), the description covers every angle: what to report, which MCP server scope applies, how to format issues, how to follow up, and what to expect in terms of processing and rate limits. It also explains the return value (claim_token) and later status updates 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 schema already describes all parameters at 100% coverage, providing a solid baseline. The description complements this by explaining the nuanced claim_token round-trip ('Filing without an account returns a claim_token; pass it back later... to read whether it was fixed') and clarifying that claim_token should be used alone with no other arguments. This goes beyond the schema's dry definition.

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

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

The description opens with a specific verb and object: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly defines the tool's scope (submitting feedback about Pipeworx tools) and inherently distinguishes it from sister research/inference tools like ask_pipeworx and discover_tools.

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

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

The description explicitly states when to use the tool ('Use when a tool returns wrong/stale data... when a tool you wish existed isn't in the catalog... or when something worked surprisingly well') and, critically, when NOT to use it ('ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead'). It also provides clear submission guidance about describing issues in terms of Pipeworx tools and not pasting end-user prompts.

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

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds valuable behavioral context: source (CF analytics-engine), no PII, cache duration (5min-1h), enriching 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?

Description is concise: one lead sentence plus bullet-like uses and two extra context lines. No redundancy, each sentence earns its place.

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

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

Lacks output schema but describes return items (top tools, packs, call volume). Mentions caching and data source. For a simple tool, sufficiently complete though format detail missing.

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

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

The single parameter 'window' has enum values. Description adds guidance on when to use shorter vs. longer windows, which is meaningful insight beyond the schema's enum listing.

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

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

The description clearly states the tool returns top tools, packs, and call volume over a recent window. The verb 'returns' and specific outputs distinguish it from 37 sibling tools by focusing on aggregation and trending.

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?

Three explicit use cases are listed (discovering hot data, confirming canonical choice, seeing alignment). Does not mention when to avoid or sibling alternatives, but context is well-defined for an aggregator.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds detailed behavioral traits: scanning top markets, semantic similarity filtering (0.30 Jaccard), placeholder filtering, partition sum checks, fill check against live CLOB depth. Fully consistent 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?

Despite length, the description is well-structured with clear sections (modes, semantic anchor, partition filter, response, fill check, related tool). Every sentence adds essential information without redundancy. Front-loaded with purpose.

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

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

No output schema, so description fully describes response fields (opportunities[], partition_check with subfields). Covers edge cases (skipped_low_similarity, placeholders, fill check conditions). Provides complete guidance for correct tool usage.

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

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

Schema coverage is 100% with decent descriptions. The tool description significantly enhances parameter understanding by providing concrete examples (slugs, seed questions) and explaining behavior differences (single-event vs cross-event). Also notes that full URLs are accepted for event.

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

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

The description clearly states the tool finds arbitrage opportunities via specific methods (monotonicity violations + partition-sum checks) and distinguishes two modes (event/topic). It implicitly differentiates from siblings by referencing polymarket_fill_risk for custom sizing.

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

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

Explicitly tells when to call with no args (trending scan), pass event, or pass topic. Recommends event for specific markets and explains cross-event mode catches patterns missed by single-event. Also advises to avoid trading when realizable_edge_pp ≤ 0, guiding decision-making.

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

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

Annotations (readOnlyHint, openWorldHint, etc.) are complemented by extensive behavioral details: caching strategy (1h at KV level), diagnostic output (_diagnostics), edge calculation methodology, and the note on Fed bet unreliability. No contradictions with annotations.

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

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

The description is long (~500 words) but necessary for the tool's complexity. It is front-loaded with the core purpose, then structured by segments, knobs, and diagnostics. Every sentence adds value, though it could be slightly more concise.

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

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

Despite lacking an output schema, the description fully explains the return structure (by_segment, fed_candidates, _diagnostics) and each field within opportunities. Given the tool's complexity and zero required parameters, this is exceptionally 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?

All 9 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds value by explaining the interplay between parameters like min_kelly and min_partition_leg_kelly for partition arbs, and providing context on slippage and tradeable-edge knobs.

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

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

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, using specific verbs and resources. It distinguishes from siblings by focusing on edge detection with three distinct model families, making it unique among tools like polymarket_arbitrage or edge_tracker.

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 the tool is built for 'what should I bet on today' and that agents can discover opportunities without paging hundreds of markets. It provides context on when Fed bets surface but are excluded, though it does not explicitly contrast with sibling tools or provide when-not-to-use guidelines.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds extensive behavioral details: data source (daily snapshots), response structure (tracked, expired, snapshot_dates), limits (60-day TTL, decay from daily closes), and interpretation of negative values.

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

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

The description is well-structured with a clear overview first, then detailed response breakdown. It is somewhat verbose but justified by 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 is provided, but the description thoroughly documents all output fields (tracked[], expired[], snapshot_dates[]) and their semantics, making the tool sufficiently understandable.

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

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

Both parameters are fully described in the input schema (100% coverage). The description only repeats and lightly clarifies the defaults and clamping, adding minimal extra meaning.

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

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

The description clearly states that the tool provides 'edge persistence and decay telemetry' and answers when an edge has existed and if it is shrinking. It is distinct from siblings like 'polymarket_edges' which likely gives current edges.

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

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

The description implies when to use the tool (to see edge history) and contrasts different aged edges, but does not explicitly name alternatives or state when not to use it.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and warns that partial basket fills convert arb into unhedged 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 dense but well-structured, starting with core purpose, then separating modes with 'SINGLE-MARKET:' and 'BASKET:' headings. 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?

Despite no output schema, the description fully details return fields for both modes, including edge cases like thin_legs[] and forced_directional_risk. It also explains interpretation, making the tool self-contained.

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

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

Schema covers 100% of parameters, but the description adds meaning: explains how parameters like market/event/size_usd behave differently in single-market vs basket mode, gives defaults, and clarifies units (settlement notional for basket).

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 checks 'realizable-vs-theoretical edge' against live order book depth, distinguishes between single-market and basket modes, and explicitly references sibling tools (polymarket_arbitrage, polymarket_edges) to position its role.

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

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

The description provides explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', along with warnings about partial basket fills and thin books.

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 well beyond annotations by detailing safety fields (compatibility_warning with two cases, temporal_alignment, skipped_cross_type counters), explaining how mismatches are handled, and warning that most topics yield warnings. Annotations already indicate read-only and idempotent behavior, and the description adds rich behavioral context.

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

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

The description is structured with clear sections for purpose, modes, response, and safety fields. It is somewhat verbose but every sentence provides significant value. Front-loading the purpose and using bullet points would improve conciseness, but the current format is acceptable.

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 compensates by explaining the response structure (leg-by-leg prices, matched spreads, safety fields). It covers inputs, behavior, and outputs adequately for an agent to understand what the tool returns. Minor missing detail on the format of 'top_spreads_pp' but overall sufficient.

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

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

The input schema covers 100% of parameters with descriptions. The description adds value by explaining the two modes (topic vs. explicit ticker/slug), enumerating possible topic values, and clarifying how explicit parameters override topic-mapped sides. This context enhances understanding of parameter interaction beyond schema alone.

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

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

The description clearly states 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' specifying the verb (calculates spread), resource (spread between two venues), and scope (same question). It distinguishes from sibling tools like polymarket_arbitrage by focusing on venue comparison rather than intra-market analysis.

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

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

The description explains two modes (topic shortcuts and explicit parameters) and includes warnings about pre-mapped topics often returning compatibility warnings, guiding when the tool may not be useful. However, it does not explicitly contrast with alternative tools for similar tasks, relying on context to infer usage boundaries.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds scoping detail (anonymous IP, BYO key hash, account ID) and listing behavior on omit. 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?

Three concise sentences with zero wasted words. Core action front-loaded, then context and pairing. Ideal length.

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

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

No output schema, but description covers retrieval and listing. Missing return format (e.g., value type or list structure), but pairing with remember reduces ambiguity. Sufficient for a simple tool with good sibling 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 100% and description adds meaning: explains that omitting key lists all saved keys. This enriches the schema's 'omit to list all keys' hint.

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

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

Description clearly states verb+resource: 'Retrieve a value previously saved via remember, or list all saved keys'. It distinguishes from siblings by naming remember and forget as complementary tools.

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

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

Explicitly states when to use ('look up context the agent stored earlier') and how it is scoped. Names alternatives (remember to save, forget to delete), providing 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 read-only, non-destructive, and idempotent. The description adds beyond that: explains the persisted feed nature, mark_read behavior (write-like but non-destructive), and return structure. 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?

Every sentence serves a purpose: first sentence states core function, second details returns, third covers filtering, fourth explains mark_read, fifth mentions alternative access. No wasted words.

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

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

With no output schema, the description explains return fields (source, citation_uri, raw payload) and provides polling context. It covers all key aspects but omits pagination details beyond limit. Adequate for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds examples (e.g., type 'sec_8k'), explains mark_read effect, and clarifies limit range. This provides meaning beyond the schema.

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

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

The description clearly states the tool pulls fired events from the subscription feed, specifying the verb 'Pull' and the resource 'subscription feed'. It distinguishes from siblings by detailing the returned fields (source, citation_uri, raw payload) and filtering options.

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

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

Provides clear context for usage: filtering by type and since, marking events read, and polling. Mentions an alternative access method (GET registry.pipeworx.io/alerts.json). However, it does not explicitly contrast with sibling tools like 'events' or 'list_subscriptions'.

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

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

The description adds detailed behavioral context beyond annotations: fans out to multiple sources (SEC, GDELT/GNews, USPTO), uses fallback, returns structured data with citation URIs. Annotations declare readOnly and idempotent, and the description reinforces safe, non-destructive behavior with no contradiction.

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

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

The description is well-structured, front-loading purpose with example queries, then detailing behavior, sources, and comparison. Every sentence provides meaningful information without redundancy. Length is appropriate for the tool's complexity.

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

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

Given no output schema, the description fully specifies expected return structure (changes grouped by source, total_changes, citation URIs) and covers limitations (USPTO, fallback). This makes the tool's behavior predictable enough for an AI agent to understand exactly what it returns.

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

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

Despite 100% schema coverage, the description adds substantial value: explains `since` format with examples (ISO, relative shorthands), clarifies `value` accepts ticker or CIK, and confirms `type` is limited to 'company'. This enriches beyond the schema's brief descriptions.

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

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

The description clearly states it provides a change feed for a company over a window, lists example queries, and explicitly distinguishes from the sibling tool entity_profile by noting when to use each. The verb 'change feed' and resource 'company' are specific, and the examples clarify intent.

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

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

The description gives explicit guidance on when to use this tool ('What's new with X' queries) versus entity_profile ('static profile'), includes fallback behavior (GDELT to GNews), and notes limitations (USPTO soft-fail). This provides clear context for appropriate usage.

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

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

Annotations indicate idempotentHint=true, no destructiveness. Description adds context: scoped by identifier, 24-hour retention for anonymous, pairing with recall/forget. No contradiction.

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

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

Concise yet informative, front-loaded purpose, each 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 2 params, full schema coverage, no output schema, and good annotations, the description covers usage, persistence, and pairing completely.

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

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

Schema coverage is 100% with clear descriptions for key and value. Description adds naming convention examples and clarifies that value is any text, going slightly 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 'Save data the agent will need to reuse later' across conversations/sessions. It uses specific verbs and resource (key-value pair) and distinguishes from sibling tools like recall and forget.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward'. Provides examples (ticker, address, preference). Also explains scope and persistence differences for authenticated vs anonymous users.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond these. It explains that unresolved identifiers are explicitly listed under 'unresolved' rather than omitted, that LEI/FIGI enrichment degrades gracefully when sources are unavailable, that each call cascades through multiple endpoints internally, and that ISINs resolve via GLEIF to legal entities. These details accurately disclose expected behavior without contradicting annotations.

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

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

The description is well-structured with clear sections (example queries, purpose, supported types) and the purpose is front-loaded. However, it is quite verbose, with five example queries and a long company description that includes many parenthetical details. While the detail is useful for a complex tool, it could be tightened without losing meaning, so it doesn't earn a 5.

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

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

There is no output schema, so the description must explain return behavior. It does so thoroughly: it states that identifiers are labelled with their source, unresolved identifiers are explicitly listed, and graceful degradation is described. It also explains the drug return includes a pipeworx citation. For the tool's complexity, the description is complete enough to set accurate expectations.

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% with descriptions for both 'type' and 'value', the description adds significant meaning. It elaborates that a company value can be a ticker, CIK, ISIN, or name, and explains the ISIN-to-LEI mapping. For 'type', it details what each enum value returns (e.g., company returns CIK, ticker, LEI, FIGI; drug returns RxCUI, ingredient, brand). This goes well 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 identifies the verb 'resolve' and the resource 'user-spoken NAME to canonical/official identifiers'. It distinguishes itself from sibling tools by stating it provides identifiers that 'other tools require as input', and explicitly says 'Use FIRST whenever you have a name but need an ID'. Supported types (company, drug) are enumerated with specific output identifiers, leaving no ambiguity about the tool's purpose.

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

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

The description gives an explicit usage directive: 'Use FIRST whenever you have a name but need an ID.' It also notes that it replaces 2-3 manual lookups, implying efficiency. However, it does not name alternative sibling tools or explicitly state when not to use this tool, so it falls short of the 5 bar which requires explicit when-not or named alternatives.

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

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

Discloses that it probes each entity, treats the first as subject, and returns ranked list with score, confidence, signal density. No contradictions with annotations (readOnly, idempotent, openWorld). Does not detail rate limits or error behavior.

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

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

Three sentences, front-loaded with main purpose, then details and use case. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description explains the return structure (ranked list with scores). All parameters are covered, and the tool's behavior is fully explained 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%. The description adds value by explaining the first entity is the subject, default models, and optional API key condition. This goes beyond the schema descriptions.

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

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

The description clearly states it compares AI visibility across multiple entities, uses ai_visibility_check for probing, and ranks results. It distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities.

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

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

Provides a specific use case ('competitive AI-marketing audits') with an example question. Does not explicitly state when not to use or contrast with alternatives, but the context is clear.

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

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

Annotations already indicate idempotent, read-only, non-destructive behavior. Description adds critical behavioral context: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed will list timeouts. This goes beyond annotations and fully informs the agent about potential delays and fallback 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?

Description is a single paragraph but dense with information. It is front-loaded with the main purpose and lists return fields. Could be slightly more concise, but overall efficient given the tool's complexity.

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

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

No output schema provided, but description comprehensively explains the return value: a summary block with specific fields, per-advisory details, links, and alternative versions. Also covers partial failure handling and timing caveats. Provides a complete picture for an agent to understand what the tool returns.

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

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

Schema description coverage is 100% (both parameters well-described). Description adds no additional semantics beyond what's in the schema; it mentions version defaults to latest, which is already in schema. Baseline 3 is appropriate.

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

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

Description clearly states the tool performs a composite check for npm packages, fanning out across deps.dev and bundlephobia. The verb phrase 'Composite "should I add this npm package to my project" check in ONE call' is specific and distinguishes it from sibling tools which are about different domains like AI visibility, betting research, etc.

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

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

Explicitly states when to use: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me". Also notes NPM ecosystem only in v1 and mentions fallback for other ecosystems via deps.dev:version directly. Missing a clear 'when not to use' statement, but provided guidance 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?

Description adds significant behavioral detail beyond annotations: uses BGE-base-en embeddings with cosine similarity over 500-char windows, 200K char cap with truncation flag, and returns character offsets and similarity scores. No contradiction with annotations (all hints are 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?

Concise, front-loaded with purpose, every sentence adds value. No wasted words.

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

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

Completes the picture given no output schema: explains return format (passages with offsets and scores), scaling limits, embedding model, and pairing with sibling tool. All relevant behavioral details are covered.

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 description adds marginal value by reinforcing parameter meanings and providing usage examples. However, it doesn't add new constraints or format details beyond schema.

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

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

The description clearly states it performs semantic search inside a fetched record, distinguishing it from siblings by noting it pairs with ask_pipeworx_grounded and conserves context by returning only relevant passages.

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

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

Explicit usage guidance: use when the record is too large for the prompt, and pairs with ask_pipeworx_grounded for grounding over passages instead of whole documents.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds behavioral detail such as the requirement for authentication, the return of a subscription id, and the one-time webhook secret. It also notes the SMS cap and phone verification, providing useful context beyond annotations.

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

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

The description is well-structured with clear sections for purpose, requirements, types, and delivery. While it is somewhat lengthy, each sentence adds essential information. The front-loading of the main purpose and then detailing specifics is effective.

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

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

Given the tool's complexity with nested objects and no output schema, the description adequately covers prerequisites, type-specific filters, delivery options, and behavioral constraints. It provides enough context for an AI agent to understand setup and invocation, though it could mention the response format more explicitly.

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 schema already describes parameters. However, the description adds significant value by explaining type-specific params with concrete examples and detailing delivery sub-fields with constraints (e.g., E.164 format for SMS, verification requirement). This enhances understanding beyond the schema descriptions.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream. The verb 'subscribe' and resource 'alerts' are specific, and the purpose is distinct from sibling tools like list_subscriptions, unsubscribe, and recent_alerts.

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 requires a Pipeworx OAuth account and mentions that anonymous/BYO cannot persist subscriptions. It provides examples for each supported type and delivery constraints like the SMS 10/day cap. However, it does not explicitly state when not to use this tool or compare it to alternatives, missing a perfect score.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: returns example questions from a live catalog, uses category buckets, and specifies that no argument gives full spread while topic focuses the response. 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 well-structured and front-loaded with common user intents. Every sentence adds value, but it is somewhat long. Could be slightly more concise, but it earns its length with comprehensive 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?

For a simple tool with one optional parameter and no output schema, the description thoroughly covers purpose, usage, and output content. It explains what is returned (category-bucketed examples with tool shapes) and how to invoke with or without topic. Complete for agent 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 coverage is 100% with one optional parameter. The description adds meaning beyond the schema by listing example topic values (finance, pharma, etc.) and explaining that omitting topic yields a cross-category spread. This helps the agent understand parameter use.

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

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

The description clearly states the tool is an onboarding entry point that returns category-bucketed example questions with exact tool+argument shapes. It uses specific verbs like 'returns' and 'call', and distinguishes itself from siblings by being the first tool to use when unsure about Pipeworx capabilities.

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

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

Explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you'. Provides clear instructions: call with no arguments for full spread, or pass a topic parameter to focus. Also mentions it helps learn how to call meta-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 indicate non-read-only, idempotent, and non-destructive. The description adds valuable context: ownership enforcement, deactivation (not deletion), and persistence of historical events. This goes beyond annotations and fully discloses the behavioral traits.

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

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

Two concise sentences, front-loaded with the core purpose. Every sentence provides essential 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?

The description covers ownership, persistence behavior, and links to 'recent_alerts' for history. For a simple tool with one parameter and no output schema, this is complete and provides sufficient 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 'id' parameter. The description does not add extra parameter-level details beyond the schema, which is acceptable given full coverage. Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Cancel a subscription by id') and the resource (subscription). It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by specifying the operation and ownership enforcement.

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 ownership enforcement ('you can only cancel your own subscriptions'), guiding when to use. It also explains the effect (deactivation, not deletion) and references 'recent_alerts' for historical events. However, it does not explicitly state when not to use or name alternative tools.

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

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

The description provides extensive behavioral detail beyond the annotations. It explains the exact verdict values, the meaning of 'could_not_verify' (with a warning that it is not evidence), the distinction between 'unsupported' and failure states, and the return format including citations. It also discloses the two distinct processing paths. This far exceeds the annotations' readOnly/openWorld/idempotent hints and adds critical decision-making context.

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

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

The description is long but information-dense, and the structure is logical: trigger phrases, usage, processing details, return values, and special caller warnings. It includes an 'IMPORTANT for callers' section that highlights critical edge cases. While a few phrases could be tightened (e.g., the long list of non-financial claim types), every sentence contributes to understanding. Slightly verbose but 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?

The description is remarkably complete for a tool with no output schema. It explains the input (claim), the parameter options, the return verdicts, the evidence format, the citation mechanism, and the failure modes (could_not_verify, unsupported). It also contextualizes the tool within the larger workflow by noting it replaces multiple sequential calls. No significant gaps are apparent.

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

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

The input schema already provides 100% coverage for both parameters, with clear descriptions for 'claim' and 'tolerance_pct'. The tool description adds some context about the tolerance behavior (default capped at 5, overrides implied wording) but does not significantly enrich the parameter semantics beyond what the schema already states. The baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool's purpose: natural-language claim verification against authoritative sources. It provides specific trigger phrases ('fact check', 'verify the claim'), distinguishes the tool from siblings by focusing on factual validation, and even explains the internal routing logic (SEC EDGAR vs grounded pipeline). This goes far beyond a tautology and provides a rich, specific verb+resource definition.

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

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

The description explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also clarifies that non-financial claims automatically fall through to the grounded pipeline, and notes that it replaces 4–6 sequential calls. However, it does not explicitly name sibling tools as alternatives or provide when-not-to-use scenarios, so it stops short of a perfect 5.

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