chucknorris

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds value by detailing cost implications (BYO key for Anthropic), default model, and return structure (per-model fields + combined view). 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 a single, well-structured paragraph of 4 sentences. It front-loads the main action and includes every sentence with a distinct purpose (action, defaults, cost, return format, use cases). No superfluous text.

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

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

Given no output schema, the description adequately explains return values (per-model {score, confidence, signals, raw_response} + combined view). It covers all parameters, use cases, and annotations. Minor omission: no mention of rate limits or errors, but acceptable for a probe tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond schema by clarifying default model behavior, the role of _apiKey, and the optional context parameter for disambiguation.

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 specifies the verb (probe), resource (LLMs), and output (visibility score 0-100). It distinguishes from siblings like scan_competitor_ai_presence by focusing on per-model scoring and mentions use cases (AI-marketing audits).

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

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

The description explicitly lists use cases (pre-launch brand checks, competitive monitoring), providing context for when to use. However, it does not contrast with sibling tools or specify when not to use, leaving some ambiguity.

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

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

Annotations already indicate safe read-only behavior; description adds valuable context about routing to multiple tools, returning citations, and handling a wide range of factual queries, with 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?

Front-loaded with key instruction, well-organized with examples, but slightly verbose; overall each sentence adds value for an AI agent.

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

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

Given no output schema, the description explains output format (structured answer with citations) and covers usage, examples, and scope thoroughly, leaving no gaps.

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

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

Schema coverage is 100% with clear descriptions of aliases; description reinforces natural language input, adding no new parameter details but aligning well with the schema.

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

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

Clearly states the tool answers factual questions with authoritative structured data, explicitly distinguishes from web search, and provides specific examples of queries.

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

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

Explicitly instructs to prefer over web search, lists trigger phrases and example queries, and details the scope (3,745 tools, 884 sources), giving clear when-to-use guidance.

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

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

Discloses return format with refusal reasons (not_in_source, no_tool_match, etc.) and that it costs an extra LLM call. Annotations already show readOnlyHint, openWorldHint, idempotentHint, destructiveHint; description adds context without contradiction.

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

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

Well-structured with purpose first, then mechanism, return format, use cases, and cost trade-off. Slightly lengthy but all sentences earn their place. Could be slightly tighter.

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

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

Given complexity (3,745 tools, 884 sources, refusal reasons, extra LLM call), description covers behavioral traits, return format, differentiation from sibling, and appropriate use cases. Output schema absent but return structure described.

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

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

Schema coverage is 100% with 6 parameters all aliases for 'question'. Description mentions 'Your question in natural language' and lists aliases, but adds little beyond schema descriptions. Baseline 3 due to 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?

Clearly states 'Hallucination-resistant answer mode for high-stakes reads' and explains the mechanism: routes like ask_pipeworx, fills args, fetches data, extracts answer using only tool result. Distinguishes itself from ask_pipeworx by emphasizing grounded extraction.

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

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

Explicitly says 'Use whenever an answer will be quoted, cited, or acted on' and lists domains like financial verdicts, legal claims. Also advises preferring ask_pipeworx for casual lookups due to extra 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?

The description goes far beyond annotations by detailing fan-out behavior per category, response shapes, resolver contract with confidence levels, parent event extraction, news fields with fallback mechanisms, safety short-circuits for low-confidence or closed markets, and resolution-rule risk. Annotations (readOnlyHint=true, etc.) are consistent, and the description adds extensive 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 lengthy but front-loaded with the purpose. Every section adds necessary detail for a complex tool with many behaviors and edge cases. While it could be restructured for slightly better conciseness, the content is valuable and appropriately sized 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?

Despite lacking an output schema, the description fully explains return fields: result.market, analysis, evidence, market_match_confidence, parent_event, news fields, status, tradeability, and cancellation_rule. It covers multiple edge cases (low-confidence matches, closed markets, wide spreads, resolution-rule risks), making the description complete for agents to understand the tool's behavior.

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 for the 'market' parameter (accepts slug, URL, or question text) and 'depth' parameter (quick vs thorough with examples). For 'include_raw', the schema already explains its effect, so no additional value there. Overall, the description enriches parameter understanding 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 the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It uses a specific verb ('research') and resource ('Polymarket bet'), and the detailed examples distinguish it from siblings like polymarket_edges or polymarket_arbitrage, which focus on edge calculations or arbitrage rather than comprehensive data gathering.

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 provides use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also includes guidance on inspecting specific fields (e.g., market_match_confidence) and warns against acting on phantom matches. However, it does not explicitly state when not to use this tool or directly compare to alternatives, though sibling tools are listed separately.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds significant behavioral details: for company, it mentions specific data sources (SEC EDGAR/XBRL) and fiscal year handling (AAPL Sep, NVDA Jan, etc.); for drug, it lists FAERS data. This goes beyond annotations.

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

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

The description is front-loaded with common query patterns and then proceeds to explain purpose, usage, and details. While every sentence adds value, the description is somewhat verbose. However, it is well-structured and not redundant.

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

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

Given the tool's complexity (two entity types, multiple data sources), the description covers the core functionality, data sources, sorting, and output format (paired data + citation URIs). It also mentions it replaces 8–15 sequential lookups, providing context on efficiency. No output schema is present, but the description sufficiently describes the return format.

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

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

Schema coverage is 100% with descriptions for both parameters (type and values). The description adds semantic context by providing concrete examples (e.g., ["AAPL","MSFT"] for companies, ["ozempic","mounjaro"] for drugs) and explaining the difference in behavior between company and drug types. This adds value beyond the schema.

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

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

The description clearly states the tool's purpose: side-by-side comparison of 2–5 companies or drugs in one parallel call. It provides example queries and distinguishes from sequential lookups, making it immediately clear what the tool does and how it differs.

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

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

Explicitly tells when to use: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also gives context on what each entity type pulls (company: SEC data; drug: FAERS counts), helping the agent decide which tool 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?

Goes beyond annotations by detailing the decomposition process, parallel routing, output structure (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, explicit gaps), and expected latency (15-60s). 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?

Well-structured and front-loaded with core functionality, then process, usage, requirements, and timing. Every sentence adds value, though slightly verbose in places. Could tighten without losing clarity.

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

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

Comprehensive for a complex tool with no output schema: explains return format (structured findings packet with evidence, confidence, source, etc.), pre-verified facts, no fabrication, account and plan requirements, and latency. Fully covers behavioral and usage context.

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

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

Adds significant meaning beyond input schema: depth is explained with numeric values (quick=3, standard=5, thorough=8) and paid plan requirement; question parameter notes that 'broad/multi-part is fine — decomposition is the point.' The 100% schema coverage is enhanced with practical examples.

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

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

The description clearly states the tool does grounded multi-source research by decomposing questions into sub-questions, routing to 3,745 tools, and returning structured findings. It distinguishes itself from sibling ask_pipeworx by noting its use for broad/multi-part questions vs single lookups.

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

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

Explicitly states when to use: 'Use for broad or multi-part questions... use ask_pipeworx for single lookups — it's one LLM call instead of many.' Also notes account requirements and paid plan for 'thorough' depth, providing clear context for 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds crucial behavioral context: it returns top-N relevant tools with full input schemas and curated examples, ready to call directly. 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 information-dense but not verbose. It front-loads the primary purpose, then provides usage guidance, return value specifics, and invocation timing. Every sentence adds value without redundancy.

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

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

Given no output schema, the description fully covers what the tool returns (names, descriptions, schemas, examples) and its limitation (top-N, configurable via limit). It covers when to use and what to expect, making it complete for an agent.

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

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

Schema coverage is 100% with descriptions. The description further clarifies that query, task, q, search, and description are all aliases for the main query parameter. It provides concrete examples like 'look up FDA drug approvals' which adds valuable semantic context.

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

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

The description starts with 'Find tools by describing the data or task' which clearly states the action and resource. It lists specific domains (SEC filings, FDA drugs, etc.) and distinctively positions itself as a discovery tool among numerous sibling tools that perform specific actions.

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

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

It explicitly advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear usage context. It doesn't list negative conditions or alternatives, but the guidance is strong enough for correct invocation.

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

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

Annotations already indicate readOnly, idempotent, openWorld. The description adds rich behavioral context: fans out across multiple sources in parallel, soft-fails for patents (USPTO sunset), GDELT→GNews fallback, returns specific fields with ordering. 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 dense but well-structured, front-loading with common user queries and core purpose. Every sentence adds value, though it is somewhat lengthy. It sacrifices brevity for completeness, which is justified 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?

Despite no output schema, the description thoroughly lists all returned fields (cik, filings, fundamentals, patents, news, LEI) with details on sorting, URIs, and fallbacks. It also addresses edge cases (patent API sunset) and input restrictions. This is complete for an agent to understand the tool's capabilities.

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 providing examples ('AAPL', '0000320193') and clarifying constraints (only 'company' type supported, names not accepted). This goes beyond the enum and type descriptions in 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 provides a 'full cross-source profile of a US public company in ONE parallel call', listing specific sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and outputs. It explicitly distinguishes from sibling tools by stating 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and mentions 'resolve_entity' as an alternative for name resolution.

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

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

Explicit usage guidance: use when user asks for a holistic view, prefer over chaining lookups. Clear exclusion: 'names not supported (use resolve_entity first if you only have a name)'. The description also advises on input format (ticker or CIK) and mentions the upcoming person/place type.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description repeats 'delete' but adds no new behavioral traits beyond what annotations provide.

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

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

Two concise sentences that are front-loaded and contain no unnecessary words or repetition.

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

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

Given the tool's simplicity (single parameter, no output schema, no nested objects), the description fully covers purpose, usage, and sibling relationships.

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

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

Schema coverage is 100% and the single parameter 'key' is described in the schema. The description does not add additional meaning or constraints beyond what's already in 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?

Description explicitly states 'Delete a previously stored memory by key' with a specific verb and resource, clearly distinguishing it from siblings like 'remember' and 'recall'.

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

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

Provides explicit when-to-use scenarios (stale context, task done, clear sensitive data) and mentions complementary tools ('remember' and 'recall').

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

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

Describes fetching page, extracting title/description/key links, emitting standard markdown. Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds operational detail without contradiction.

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

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

Three sentences: purpose, mechanism, use cases. Front-loaded and efficient 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?

Covers purpose, behavior, and use cases adequately. No output schema, but description mentions output format (standard markdown blob). Sufficient for a simple tool.

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

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

Schema coverage is 100%; description adds minimal extra info beyond schema. For url, gives example format. For max_links, mentions default 25 and max 50, consistent with schema.

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

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

Clearly states verb 'generate' and resource 'llms.txt file for any URL'. Distinguishes from siblings by specifying use cases for AI crawlers like ChatGPT, Claude, Perplexity.

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

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

Explicitly lists three use cases (client indexing, own project, competitor auditing). No explicit when-not-to-use, but clear enough context for selection among siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by stating the return format (joke text and ID), which is beyond annotations. No contradictions.

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

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

The description is two short sentences with no wasted words, front-loading the core purpose. Every sentence adds value.

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

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

Given the low complexity (1 parameter), complete schema, rich annotations, and presence of an output schema, the description fully covers the needed context: what the tool does, what it returns, and how to use the parameter.

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

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

Schema coverage is 100% and the parameter description already explains the category parameter well. The description adds minimal new meaning beyond 'from a specific category,' so baseline 3 is appropriate.

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

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

The description clearly states 'Get a random Chuck Norris joke from a specific category. Returns joke text and ID.' This provides a specific verb and resource, and distinguishes itself from siblings like random_joke (which has no category filter) and list_categories.

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 implicitly suggests usage by mentioning 'from a specific category' and the parameter description advises to 'Use list_categories to see valid values,' but it lacks explicit guidance on when to use this tool versus alternatives like random_joke or search_jokes.

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, destructiveHint, so description adds minimal behavioral info but includes examples of categories.

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

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

Two concise sentences with no wasted words, front-loaded with action.

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

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

Tool has zero parameters, clear purpose, output schema exists, description fully adequate for understanding and using the tool.

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

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

No parameters defined; schema coverage 100%. Description does not need to add parameter info, baseline for 0 parameters is 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?

Description clearly states the verb 'list' and resource 'categories', provides examples ('nerdy', 'sport'), and distinguishes from sibling tool 'joke_by_category'.

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 suggests using with 'joke_by_category' to fetch jokes, providing clear context. No explicit when-not-to-use but sufficient 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 declare readOnlyHint=true and destructiveHint=false; description adds that it returns specific fields and hints at the 'include_inactive' parameter's effect. Provides useful behavioral context beyond annotations.

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

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

Two sentences, no waste. First sentence clearly states purpose and outputs; second sentence gives actionable guidance.

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

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

Complete for a simple list tool with one optional param and no output schema. Could mention pagination or limits but not critical.

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 already describes the parameter well. Description adds no new parameter detail but ties usage to parameter context ('before adding more'). Baseline score 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 specifies verb 'list' and resource 'subscriptions', and distinguishes from siblings 'subscribe' and 'unsubscribe' by focusing on reading active subscriptions with returned fields.

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: 'to review what you're monitoring before adding more or to find an id to cancel.' Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations indicate this is a write operation (readOnlyHint false) but with no destructive or idempotent hints. The description adds valuable behavioral context: rate-limited to 5 per identifier per day, free, not counted against quota, and that the team reads digests daily. No contradictions with annotations.

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

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

The description is a single paragraph but efficiently covers purpose, usage, constraints, and best practices. It is front-loaded with the core purpose but could be slightly more structured (e.g., bullet points) for readability. Earns its length without excess.

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

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

For a simple feedback submission tool, the description fully covers purpose, when to use, what to avoid, rate limits, and quota implications. The input schema is fully documented with 100% coverage. No output schema is needed. Complete and actionable.

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

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

Schema description coverage is 100%, so the schema itself documents all parameters. The description adds minimal extra meaning beyond reiterating types and providing examples for the 'type' enum. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates specific feedback types (bug, feature, data_gap, praise) and differentiates from sibling tools focused on queries or actions.

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

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

Explicitly states when to use each feedback type (e.g., 'Use when a tool returns wrong/stale data (bug)') and what not to do ('don't paste the end-user's prompt'). Also provides constraints like rate limits and quota exemption.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by stating it's self-aggregating from CF analytics-engine, no PII, and cached 5min-1h depending on window. Could mention more about what 'total call volume' includes or potential staleness limits, but overall sufficient.

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

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

Three sentences: first states purpose and output, second lists three use cases, third explains technical details. No wasted words; front-loaded with critical info. Highly efficient.

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

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

Given the tool's simplicity (one param, no output schema) and rich annotations, description covers all needed aspects: return format, use cases, caching, privacy. No gaps for an AI agent to safely 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?

Schema coverage 100% with one parameter having enum and description. Description enriches by explaining shorter windows surface 'what's hot right now' and longer windows show 'steady-state demand', adding decision guidance beyond the schema. Baseline 3, plus 1 for added context.

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

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

Description clearly states it returns top tools, top packs, and total call volume with time windows. Verb 'Returns' plus explicit resource (trending data on Pipeworx). Distinct from siblings like discover_tools or ask_pipeworx, as it focuses on aggregated trending signals rather than individual queries or tool discovery.

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

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

Lists three specific use cases: discovering hot data sources for current events, confirming canonical tool choice, and checking use-case alignment. Provides clear context for when to use this tool. Lacks explicit when-not-to-use or alternative tools, but the strong use-case list compensates.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds significant behavioral context: walks child markets, checks ordering, computes partition_check, uses Jaccard similarity, filters partitions, performs fill check against live CLOB depth, and explains realizable vs theoretical edge. 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 lengthy but well-structured: starts with requirement, then modes, then internal details, then fill check. Front-loaded with critical info. Some repetition and technical depth could be trimmed, but for a complex tool, the detail is justified.

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

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

Given the complexity (multiple modes, algorithms, edge cases) and no output schema, the description covers response fields (opportunities[], partition_check, fill_check), explains realizable vs theoretical edge, placeholder filtering, and Jaccard threshold. It references sibling tool for custom sizing, making it complete for agent use.

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

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

Schema coverage is 100% with brief descriptions. The tool description adds substantial value: explains the semantic difference between event and topic, gives formatting guidance (slugs vs URLs), and details the logic flow for each mode. This goes far beyond the schema.

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

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

The description clearly states it finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between event (single-event) and topic (cross-event) modes, providing specific examples and explaining the algorithm. This differentiates it from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

Explicitly requires one of event or topic, warns that no args fails. Recommends event for specific markets, topic for cross-event scanning. Explains cross-event catches patterns single-event misses. Mentions when not to trade via fill check and references sibling tool for custom sizing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: caching strategy ('Cached 1h at the KV level'), diagnostics for empty segments, and the rationale behind algorithmic choices (e.g., placeholder-slug filters, Kelly capping). No contradictions with annotations are present.

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

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

While the description is front-loaded with the purpose, it becomes extremely verbose with algorithmic details (e.g., full model descriptions, specific alpha values, filter logic). An AI agent may benefit from this detail, but it could be more concise by moving internal details to documentation.

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

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

Given the complexity (9 parameters, no output schema, rich annotations), the description thoroughly covers response structure (by_segment, diagnostics, Fed bets), tradeable-edge knobs, and edge cases (empty segments). It explains every opportunity's fields and caching behavior, leaving no critical gaps for invocation.

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

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

All 9 parameters have schema descriptions (100% coverage). The description adds meaningful context beyond the schema, such as explaining edge calculation ('Edge is evaluated NET of slippage'), filter purposes ('Tradeable-edge filter'), and interactions between parameters (e.g., min_partition_leg_kelly's behavior for partition arbs).

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It further qualifies the use case ('what should I bet on today') and distinguishes it from paging through markets. While it does not name sibling tools, the detailed scope and response structure effectively differentiate it from related tools like polymarket_arbitrage.

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

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

The description implies appropriate usage by focusing on opportunity discovery and providing tradeable-edge knobs (min_liquidity, max_spread_pp) that shape when results are returned. It does not explicitly state when not to use or name alternatives, but the context strongly guides correct invocation.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description goes beyond by detailing output fields (tracked[], expired[], snapshot_dates[]), computational details (decay from daily closes, not intraday), and constraints (60-day TTL, snapshot gaps). 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 relatively long but well-structured with sections (main question, args, RESPONSE, LIMITS). It front-loads the key purpose. Could be slightly more concise, but the detail is necessary given the tool's complexity.

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

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

With no output schema, the description fully explains the return structure and limitations. Parameter count is low (2) and fully covered by schema. Description addresses what an agent needs to know: output shape, computation method, data freshness, and constraints.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reaffirms parameter defaults and constraints (e.g., days default 14, max 30; window default '1wk') but adds no new meaning beyond the schema. Adequate but not additional.

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 function: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes between fresh and old edges, which implies a unique purpose among siblings.

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

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

The description explains what the tool does and its output structure, but does not explicitly state when to use it versus alternative tools like polymarket_edges or polymarket_arbitrage. However, the context of analyzing persistence over time is clear, so it provides adequate implicit guidance.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) are consistent with the description, which describes a read-only check. The description adds details about the operation: 'walks the ladder and returns...', explains return values for both modes, and warns about thin books and partial fills. 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 lengthy but well-organized with clear sections for single-market and basket modes. Every sentence adds value, though some parts could be tightened. It is front-loaded with the core purpose and requirements, making it easy for an agent to quickly understand the main intent.

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

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

Given the complexity of the tool (two modes, multiple return values, risk profiles), the description thoroughly covers all necessary aspects. It explains return values for both modes, clarifies edge cases (thin legs, forced directional risk), and provides context on when to use the tool. No output schema exists, so the description carries the full burden, and it succeeds.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond the schema: it explains the dual interpretation of size_usd (max spend on buys, target proceeds on sells for single-market; settlement notional for basket), the default behavior for side in basket mode (auto from partition sum), and the effect of each parameter on the output.

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

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

The description clearly states it performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth'. It distinguishes between single-market and basket modes, and explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by stating it should be used before acting on their signals.

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 'REQUIRES one of `market` (single-market mode) or `event` (basket/partition mode)' and provides specific guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Also explains the risks of partial fills and directional risk, telling the agent when not to rely on theoretical edge.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description details response structure, safety fields (compatibility_warning, temporal_alignment, skipped counters), and explains their meaning. It also clarifies that pre-mapped topics often yield warnings, setting realistic expectations.

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

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

The description is detailed but somewhat verbose, covering many edge cases and safety fields. It is front-loaded with purpose but could be more concise without losing clarity. Structured into two modes and response overview, but length may reduce quick comprehension.

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

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

Given no output schema, the description thoroughly covers the response: venue prices, matched spreads, and safety fields. It addresses edge cases like incompatible bet shapes or temporal misalignment, making it complete for a complex tool.

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

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

Schema coverage is 100%, with descriptions for all three parameters. The description adds value by listing the 10 topic shortcuts and explaining that explicit parameters override the topic-mapped side, but this is largely a summary of schema info. No additional nuance 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 computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It specifies two modes (topic shortcuts and explicit tickers) and distinguishes from sibling tools like polymarket_arbitrage by focusing on cross-venue comparisons.

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

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

The description provides explicit guidance on when to use the topic shortcuts vs explicit tickers, and warns that most pre-mapped topics return compatibility warnings. It explains scenarios where spreads are meaningful (temporal alignment, matched pairs) and when they are not. However, it does not directly compare with alternatives like polymarket_arbitrage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it returns joke text and ID, which is useful but not critical 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 concise sentence that efficiently conveys the tool's purpose and return value, with no extraneous words.

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

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

For a zero-parameter tool with an output schema, the description adequately explains the output (joke text and ID). No additional details are necessary.

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

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

No parameters exist, so baseline is 4. No further parameter information is needed.

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

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

The description clearly states a specific verb 'Get' and resource 'random Chuck Norris joke'. It distinguishes from sibling tools like joke_by_category (filtered) and search_jokes (search).

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

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

No explicit guidance on when to use this tool vs alternatives. The intended use case (random joke) is implied but not stated as a recommendation.

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

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

Annotations already indicate readOnly and idempotent. The description adds value by explaining scope (by identifier) and behavior (listing all keys if key omitted). No contradictions.

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

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

Three concise sentences, front-loaded with the primary action. Every sentence adds 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?

For a simple tool with one optional parameter and no output schema, the description is complete: it covers purpose, usage, scoping, and pairing with siblings. No gaps.

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

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

Schema covers key parameter at 100% coverage. Description adds semantics like 'omit to list all keys', which goes beyond schema definition, explaining the optional behavior.

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

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

The description clearly states the tool retrieves a value saved via remember, or lists all keys when omitted. It uses a specific verb and resource, and distinguishes well from sibling tools like remember and forget.

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

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

The description provides clear context on when to use the tool (to look up previously stored information) and how to use it (with optional key). It also mentions pairing with remember/forget, but does not explicitly exclude other tools.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable behavioral detail on mark_read flagging events as read, which is a side effect. 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 concise (two sentences) but packed with essential information: purpose, return contents, filter options, and polling guidance. No redundant 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 five optional parameters, no output schema, and read-only nature, the description provides sufficient context (return fields, polling works, external API alternative). No missing critical information.

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

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

Schema coverage is 100% with descriptions. Tool description enhances parameter meaning by providing examples ('sec_8k' for type), plain-language explanations (mark_read 'flag returned events read'), and clarifying timestamp usage.

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

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

Description clearly states 'pull fired events from your subscription feed' and specifies return fields (source, citation_uri, raw payload). Distinguishes from sibling tools like 'list_subscriptions' by focusing on alerts and providing 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 context for polling and mentions an alternative direct API endpoint ('GET registry.pipeworx.io/alerts.json'). However, does not explicitly state when to avoid using this tool or scenarios where alternatives are better.

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

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

Annotations provide readOnlyHint, openWorldHint, et cetera. The description adds significant behavioral context: it fans out to multiple sources, describes fallback logic, mentions API sunset soft-fail, and details the return format (changes[] grouped by source + total_changes + citation URIs). This goes beyond what annotations alone convey and does not contradict them.

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

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

The description is a single paragraph that efficiently packs a lot of information. It is front-loaded with example queries. Every sentence adds value (purpose, sources, fallback, parameters, return format, sibling distinction). It could be slightly improved with bullet points for clarity, but it is not verbose. A score of 4 is appropriate.

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

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

Given the complexity of the tool (multiple sources, fallback logic, soft-fail, return structure), the description is fairly complete. It explains the function, parameters, return format, and distinguishes from siblings. It could mention error handling beyond the noted fallback, but overall it provides sufficient context for an agent to use the tool correctly.

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

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

Schema coverage is 100% with each parameter having a description. The description adds value by explaining the 'since' parameter accepts ISO dates or relative shorthand (e.g., '7d', '30d'), and clarifies that 'value' can be ticker or CIK. It reinforces the enum constraint for 'type'. While the schema covers the basics, the description adds practical examples and context, 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 explicitly states it provides a 'change feed for a company in the last N days/weeks/months' and lists specific sources (SEC EDGAR, GDELT/GNews, USPTO). It distinguishes from the sibling tool 'entity_profile' by specifying that the sibling is for static profiles. This is a specific verb+resource with clear sibling differentiation.

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

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

The description gives concrete example queries ('What's new with X', 'latest on Y') and explicitly states when to use the alternative tool 'entity_profile' for static profiles. It also explains the fallback behavior (GDELT→GNews) and soft-fail for USPTO. This provides clear when-to-use and when-not-to-use guidance.

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

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

Discloses scoping by identifier and persistence differences (authenticated vs. anonymous). Annotations already provide idempotentHint=true and destructiveHint=false; description adds context beyond annotations. No contradictions.

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

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

Four sentences, each purposeful. Front-loaded with main purpose, followed by usage guidance, behavioral details, and pairing with siblings. 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 storage tool with no output schema, description covers key aspects: what, when, how it persists, and how to retrieve/delete. Complete for an agent to use correctly.

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

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

Schema covers both parameters with descriptions. Description adds examples of key-value pairs and explains they are stored as a pair, enhancing the schema's 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?

Description states a specific verb ('Save') and resource ('data the agent will need to reuse later') and distinguishes from siblings by mentioning 'recall' 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 ('when you discover something worth carrying forward') and provides examples. Also mentions alternatives: 'Pair with recall to retrieve later, forget to delete.'

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context: 'Each call cascades through several lookup endpoints internally — using resolve_entity replaces 2-3 manual lookups.' This explains the internal complexity without contradicting annotations. No mention of rate limits or auth, but annotations cover safety.

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 appropriately sized, front-loaded with examples, and every sentence serves a purpose. It efficiently conveys when to use, what inputs are accepted, and what outputs to expect, without redundancy.

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

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

Given the tool's complexity (two entity types, multiple output fields) and the absence of an output schema, the description provides comprehensive coverage of the return values (ticker, CIK, company_name, citation URI for company; RxCUI, ingredient, brand, citation for drug). It also explains the internal cascading behavior, making the tool fully contextualized.

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

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

Schema coverage is 100%, but the description significantly enriches parameter meaning. For 'type', it explains the two supported values and what each returns. For 'value', it details acceptable inputs per type (ticker, CIK, company name for company; brand/generic name for drug) and mentions auto-disambiguation for company. This adds substantial guidance 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 explicitly states the tool resolves user-spoken names to canonical identifiers, provides concrete examples ('What's the ticker for…' / 'find the CIK for…'), and clearly outlines supported entity types (company, drug) with their respective outputs. It distinguishes itself as the first tool to use when needing an ID, which differentiates it from potential siblings like entity_profile.

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

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

The description includes explicit guidance: 'Use FIRST whenever you have a name but need an ID.' It also implies when not to use (when you already have the ID). However, it does not explicitly mention alternatives or exclusions, though the context of other tools like entity_profile suggests when this tool is appropriate.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint true, destructiveHint false. The description adds valuable behavioral details: it probes with ai_visibility_check, ranks results, and returns a ranked list with score, confidence, and signal density. 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 two sentences with no wasted words. It front-loads the purpose and structure, efficiently conveying the tool's capability and usage.

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 specifies the return format: ranked list with score, confidence, signal density per entity. It covers all parameters and use context. For a tool with moderate complexity, this is complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond schema: clarifies that the first entity is treated as the 'subject' for narrative and frames the tool's competitive use case. However, it does not elaborate on the 'models' or '_apiKey' parameters beyond what schema already states.

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

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

The description uses a specific verb ('Compare') and clearly states the resource ('AI visibility across multiple entities side-by-side'). It details the method (probes with ai_visibility_check, ranks by score) and distinguishes itself from siblings like ai_visibility_check (single entity) and compare_entities (generic comparison).

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: 'for competitive AI-marketing audits' and gives a concrete example: 'does Claude know about us as well as our competitors?'. It implies not to use for single entity checks (use ai_visibility_check instead), though it does not explicitly state exclusions.

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

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

Annotations already indicate safe, idempotent, read-only behavior. Description adds critical behavioral details: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, sources_failed lists timeouts. 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?

Well-structured single paragraph with purpose first. However, it is somewhat long (multiple clauses) and could be slightly tightened without losing clarity, though still efficient.

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

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

No output schema, but description enumerates exact return fields (summary block, per-advisory detail, links, alternative versions). Also covers edge cases like scoped packages, partial failures, and timeouts, making it fully actionable.

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

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

Schema coverage is 100%. Description adds meaning: scoped packages accepted for 'package', and 'version' defaults to latest when omitted. Both parameters get useful context beyond schema definitions.

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

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

The description clearly states the composite check across deps.dev and bundlephobia for npm packages, with specific verb 'scan' and resource 'dependency'. It differentiates from siblings by noting NPM ecosystem only in v1.

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

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

Explicitly says 'Use whenever an agent asks 'is X safe / popular / small'' and notes limitations for other ecosystems, directing to deps.dev directly. Provides clear when-to-use and alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about return format (text and IDs) but does not disclose additional behavioral traits like pagination or rate limits. With annotations covering safety, the description adds moderate value.

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

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

The description is two concise sentences, front-loading the purpose and core functionality with zero wasted words. Every sentence earns its place.

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

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

Given the tool has only one required parameter and an output schema exists (stated in context), the description covers return fields (text and IDs). It is complete enough for a straightforward search tool, though it could mention the output structure.

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

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

Schema description coverage is 100% (the single 'query' parameter is fully described in the input schema). The tool description restates the parameter's purpose without adding new meaning, so baseline 3 is appropriate.

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

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

The description clearly states the tool searches Chuck Norris jokes by keyword and returns matching jokes with text and IDs. It uses a specific verb-resource pair ('Search Chuck Norris jokes') that distinguishes it from siblings like random_joke or joke_by_category.

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

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

The description implies usage for keyword-based search but does not explicitly state when to use this tool versus alternatives such as random_joke or joke_by_category. No exclusions or when-not conditions are provided.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds significant behavioral details: uses BGE-base-en embeddings with cosine similarity over 500-char overlapping windows, input cap of 200K chars with truncation flag, and returns character offsets and similarity scores. No contradiction with annotations.

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

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

The description is a single well-structured paragraph that front-loads the main action. Every sentence adds value: purpose, usage context, pairing hint, implementation details, and limits. No wasted words.

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

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

Despite no output schema, the description fully explains return values (top-N passages with offsets and scores), implementation details, and input limits. Given the tool's complexity and lack of output schema, the description provides complete context for an agent to use the tool correctly.

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

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

The input schema already covers all 3 parameters with descriptions (100% coverage). The description repeats the 200K char limit for 'text' and gives examples for 'query', but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states 'Semantic search INSIDE a fetched record' with a clear verb+resource. It explicitly differentiates from sibling 'ask_pipeworx_grounded' by explaining how they pair together, and the context of avoiding cramming large records into prompts.

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 'Use when the record is too big to cram into the prompt' and explains the tool saves context. It mentions pairing with ask_pipeworx_grounded, providing usage context, though it does not state explicit when-not-to-use scenarios.

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

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

Discloses behavioral traits beyond annotations: requires OAuth account, delivery channel limits (SMS cap, webhook auto-disable after 10 failures). Annotations indicate idempotent=true but description does not discuss idempotency; 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?

Well-structured with bullet points and examples, front-loading purpose and return. Slightly verbose with multiple examples, but all sentences add value. Could be trimmed slightly.

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

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

Covers main aspects: return value (subscription ID), type-specific parameters, delivery channels. Lacks explicit error scenarios (e.g., duplicates, invalid params) and full response structure. Acceptable given no output schema.

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

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

Schema coverage is 100% with descriptions, but description adds significant value by providing detailed examples and constraints for each type parameter and delivery channels. Goes beyond schema with specific use cases and formatting.

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

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

Clearly states it creates a subscription to a live-data event stream and returns the new subscription ID. Distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation. Verb 'Create' with specific resource 'proactive monitoring subscription'.

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 context on when to use (requires Pipeworx OAuth account, not for anonymous/BYO) and gives examples for each subscription type. However, does not explicitly mention alternatives like list_subscriptions or unsubscribe for managing 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?

Annotations already indicate readOnly, idempotent, non-destructive. Description adds value by explaining the output includes exact tool+argument shapes from live catalog, providing 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?

Description is somewhat long but front-loaded with common queries and every sentence adds useful context. Could be slightly more concise but structure 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 no output schema, description sufficiently explains return format (categorized example questions with tool shapes). Also covers use case, parameters, and context as an onboarding tool. Completes the 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 provides description for topic parameter; description further clarifies with specific examples of focus areas (finance, pharma, etc.) and behavior when omitted, adding meaning beyond schema.

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

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

Description clearly states tool returns category-bucketed example questions to help users discover what to ask Pipeworx. It distinguishes itself from sibling tools like ask_pipeworx by being an onboarding entry point.

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: call with no arguments for full spread or pass topic to focus. Also says 'Use this FIRST' when unfamiliar. However, does not specify when not to use or mention alternatives for already knowledgeable 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?

The description adds significant context beyond annotations: it explains that the operation is a deactivation (soft delete) rather than deletion, that ownership is enforced, and that historical events remain available. This complements the annotations (idempotentHint=true, destructiveHint=false) without contradicting them.

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

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

Two sentences, no redundant information, front-loaded with the core action. Every sentence adds value: the first states the main operation and parameter, the second explains ownership and the soft-delete behavior with a reference to a sibling 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 single-parameter tool with comprehensive annotations and no output schema, the description fully covers what the agent needs to know: what happens (subscription is deactivated), constraints (ownership), and downstream effects (history still accessible via recent_alerts). No gaps remain.

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

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

The input schema provides 100% parameter coverage, with the description for 'id' stating 'Subscription id (uuid) returned by subscribe.' The tool description does not add further semantic details about the parameter beyond what the schema already contains. Hence, it meets the baseline for 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 action ('Cancel a subscription'), the required parameter ('by id'), and specifies behavioral details (ownership enforcement, deactivation vs deletion). It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by mentioning that historical events remain accessible via '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 states ownership enforcement ('you can only cancel your own subscriptions'), which guides when to use the tool. It also implies that for viewing history of deactivated subscriptions, 'recent_alerts' is the alternative. However, it does not explicitly mention that the tool should not be used for others' subscriptions or provide direct comparisons to other tools.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive. The description adds details about the return format (verdict types, structured form, dollar values with citations, percent delta) and explains that it replaces multiple sequential calls, providing behavioral context beyond annotations.

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

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

Three concise sentences pack essential information: purpose, usage cues, supported domain, return structure, and efficiency gain. Every sentence serves a purpose 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?

Given the simple input schema and strong annotations, the description fully covers the tool's purpose, supported domain, output structure, and advantages. It leaves no unanswered questions for an agent deciding whether to invoke this tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by providing domain-specific examples and clarifying that the claim should be a natural-language factual statement, which helps the agent construct appropriate input.

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

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

The description clearly states the tool performs natural-language claim verification for company-financial claims, using specific example queries. It defines the scope precisely and distinguishes itself as a specialized alternative to general search tools.

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

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

The description advises using this tool when needing to fact-check user statements, and explicitly limits its scope to company-financial claims. While it does not list exclusions, the domain constraint serves as implicit guidance on 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.