Cactus

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds clarity on return structure (per-model score, confidence, signals, raw_response) and cost implications (BYO key for Anthropic), enhancing behavioral transparency without contradiction.

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

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

The description is concise and front-loaded with the core action. It uses bullet-like structure in the return format description. A few minor redundancies exist (e.g., 'Useful for...'), but it remains efficient and informative.

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

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

Given the absence of an output schema, the description fully explains the return format (per-model objects with score, confidence, signals, raw_response, and combined view). It also covers all parameters and their roles, making the tool self-contained 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 description coverage is 100%, so baseline 3. The description adds meaning beyond the schema: it explains the default model, the purpose of `_apiKey` as a pass-through, and how `context` helps disambiguate. This adds value.

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

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

The description clearly states the tool's purpose: probing LLMs for knowledge about an entity and scoring visibility. It specifies the verb 'probe', the resource 'LLMs', the output 'score', and distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on per-model scoring.

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

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

The description provides clear usage context: AI-marketing audits, pre-launch brand checks, competitive monitoring. It explains when to use the default model vs. Anthropic with an API key. However, it lacks explicit exclusions or comparisons to similar tools like 'scan_competitor_ai_presence'.

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, non-destructive. Description adds that it routes to 4,991 tools, fills arguments, returns structured answers with stable citation URIs, which enriches understanding beyond annotations.

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

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

Front-loaded with key instruction ('PREFER OVER WEB SEARCH'). Well-structured with usage guidance, examples, and sibling differentiation. Somewhat verbose but each 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 tool's complexity (6 params, many siblings, no output schema), the description covers purpose, usage, and behavior thoroughly. Does not detail return format but this is acceptable given annotations and context.

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

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

Schema coverage is 100%, so schema already documents parameters well. Description adds that the 'question' parameter accepts natural language, but this is minimal extra value beyond the schema's description and 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?

Specific verb+resource: routes factual questions to structured data sources. Distinguishes from siblings like ask_pipeworx_grounded and deep_research by stating when to use each.

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

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

Explicitly states when to use ('PREFER OVER WEB SEARCH') and when not to (use grounded for hallucination-resistance, deep_research for broad queries). Provides example queries and clear context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context such as experimental nature, candidate routing improvements, and source-preference ranking, which are not captured by annotations. There is 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 concise, well-structured, and front-loaded. It conveys all essential information in a few sentences without unnecessary detail, earning its place.

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

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

Given the tool's complexity (beta version, many siblings, high schema coverage, no output schema), the description is complete. It explains the tool's purpose, usage, and differences from the stable version, leaving no significant gaps.

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

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

The input schema has 100% coverage with descriptions for all parameters (question and its aliases). The description adds a subtlety about source-preference ranking but does not add new parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as a beta version of ask_pipeworx with identical routing, specifying the verb 'ask' and resource 'Pipeworx Beta'. It distinguishes itself from the stable version by mentioning candidate routing improvements and source-preference ranking, making the purpose unambiguous.

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

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

Explicit guidance is provided on when to use this tool: 'when you want the newest routing', it is a full working router, and it can be used exactly like ask_pipeworx. The description also clarifies that results are compared with the stable router, and notes the source-preference ranking behavior.

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

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

Adds significant behavioral detail beyond annotations: describes the extraction method, refusal reasons (not_in_source, etc.), and cost trade-off. Annotations (readOnlyHint, etc.) are consistent, and the description enhances transparency.

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

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

The description is front-loaded with the key differentiator and well-structured, but slightly verbose. Each sentence adds value; minor improvements could tighten it.

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 explains the return object and refusal reasons. It covers workflow, use cases, and cost, making it complete for this complex tool with many siblings.

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 aliases for 'question'. The description mentions 'Your question in natural language' but adds no new semantic details beyond the schema. Adequate but not extra helpful.

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

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

The description clearly states it is a 'hallucination-resistant answer mode for high-stakes reads' and distinguishes it from the sibling tool 'ask_pipeworx' by detailing its grounded extraction process and return format (answer, evidence, confidence, etc.).

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

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

Explicitly provides when to use (quoted/cited/acted-on answers) and when not to (casual lookups, preferring ask_pipeworx), with concrete examples like financial verdicts and legal claims, and mentions the extra LLM call cost.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds substantial context: fan-out behavior, response shapes, resolver contract, fallback for GDELT, blocking on low-confidence matches, handling closed markets, wide-spread warnings, and resolution-rule risk. 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 very long (multiple paragraphs) and uses headings to structure information. While every sentence adds value, it could be more concise. The length is justified by the tool's complexity, but conciseness could be improved without losing essential details.

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

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

Given the complexity and absence of output schema, the description is extremely complete. It explains response shapes, resolver contract, parent event extraction, news fields, safety mechanisms, wide market handling, and resolution-rule risk. It covers potential pitfalls and provides thorough guidance for an AI agent.

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

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

Schema coverage is 100%, but the description adds significant meaning beyond the schema: for `market`, it explains input types (slug, URL, question text) with examples; for `depth`, it defines 'quick' and 'thorough' with defaults; for `include_raw`, it explains when to enable. This is excellent parameter documentation.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the verb (research, pull) and resource (Polymarket bet), and distinguishes it from siblings like `polymarket_edges` or `polymarket_arbitrage` by focusing on single-bet research with fan-out.

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: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also provides extensive guidance on interpreting results (e.g., inspecting market_match_confidence). However, it does not explicitly mention when NOT to use or name alternatives, though sibling tools cover other scenarios.

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

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

Annotations declare readOnly, openWorld, and idempotent hints. Description adds value beyond annotations by detailing handling of off-calendar fiscal years, result sorting by primary metric, and return format with citation URIs. 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?

Description is informative but slightly verbose; however, it is front-loaded with key directives and 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?

Despite no output schema, description explains return format (paired data + citation URIs). Covers examples, entity types, and edge cases (fiscal years). Complete for a comparison tool.

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

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

Schema coverage is 100%, but description adds significant meaning: explains that 'values' expects tickers/CIKs for companies and drug names, and specifies data sources (SEC EDGAR/XBRL for companies, FAERS for drugs).

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

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

Description starts with common comparison phrases and clearly states it performs side-by-side comparison of 2-5 companies or drugs in one parallel call. It distinguishes itself from sibling tools by explicitly preferring over sequential single-pack 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 (comparing, ranking, head-to-head) and gives alternatives by saying 'ALWAYS PREFER over sequential single-pack lookups'. Also mentions it replaces 8-15 sequential lookups, providing clear context.

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

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

Adds rich behavioral details beyond annotations: decomposition, parallel routing, findings packet structure (verbatim evidence, confidence, source, citation, gaps, contradictions), hop field, excerpting behavior, timeout expectations. Annotations declare readOnlyHint=true, idempotentHint=true, consistent with description.

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

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

Description is long but well-structured with sections (account, purpose, usage, detailed behavior, timing). Every sentence is informative; could be slightly more terse but justified by tool 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, description thoroughly explains the return format (findings packet with specific fields, contradictions, gaps). Covers behaviors for different depths, timeouts, and limitations. Highly complete for a complex tool with few parameters.

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

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

Schema covers both parameters (100% coverage). Description adds meaningful context: for 'depth' explains the number of facets, hops, and contradictions per enum value; for 'question' specifies natural language and multi-part suitability.

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

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

The description clearly states the tool performs grounded multi-source research across Pipeworx's structured data sources in a single call, distinguishing it from sibling tools like ask_pipeworx by specifying it is not open-web search and is best for broad/multi-part questions.

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 provides when-to-use (broad/multi-part structured data questions) and when-not-to-use (single lookup → ask_pipeworx; breaking news → ask_pipeworx). Also mentions account requirements and fallback if not signed in.

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 reveals behavioral traits beyond annotations: it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' Annotations already note readOnly, idempotent, nondestructive; the description adds lookup behavior and return structure.

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

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

The description is front-loaded with the tool's purpose, followed by usage guidance and specifics about return values. It is concise without unnecessary repetition, though the list of domains could be trimmed slightly. Overall efficient at 5 sentences.

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

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

Given the tool's simplicity (search with optional limit), the description covers purpose, usage guidelines, parameter aliases, and return format. No output schema exists, but the description explains what is returned. Parameter count and aliases are fully addressed, making it complete enough 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?

The input schema covers 100% of parameters with descriptions. The description adds value by providing usage examples ('analyze housing market trends', 'look up FDA drug approvals') and clarifying that multiple parameter aliases (task, q, search, description) map to the query parameter. This aids correct invocation.

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 specifies the tool's purpose: 'Find tools by describing the data or task.' It lists many domains (SEC filings, financials, etc.) and distinguishes from sibling tools by stating it is for browsing/discovery before making specific calls. The verb 'discover' and resource 'tools' are explicit.

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

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

Explicitly states 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear context for when to use it. It does not explicitly say when not to use it or mention alternatives, but the preceding instruction is sufficient for an AI agent.

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

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

Annotations already indicate safety (readOnlyHint, idempotentHint, non-destructive). The description adds valuable behavioral context beyond annotations: it fans out across multiple data sources (SEC, XBRL, USPTO, news, GLEIF), returns specific fields (e.g., up to 5 filings, LATEST 10-K fundamentals), and notes a known deprecation (USPTO PatentsView API sunset May 2025, with soft-fail behavior). 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 dense but well-structured. It front-loads with example queries, then states the preference, then lists the capabilities. Every sentence adds value. While it could be broken into bullet points for easier parsing, it is not overly verbose and fits the typical usage pattern. Score 4 because it is slightly long but still efficient.

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

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

Given there is no output schema, the description compensates by detailing what is returned (CIK, company_name, recent_filings with URIs, fundamentals sorted, patents with deprecation note, news via GDELT→GNews fallback, LEI). It covers input constraints (ticker/CIK only, names not supported) and the parallel call behavior. Minor missing details (error handling) but overall complete for a multi-source profile tool of moderate complexity.

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

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

Schema coverage is 100%, so the description doesn't need to repeat schema information. However, it adds significant meaning: explains that 'value' can be a ticker or zero-padded CIK, clarifies that names are not supported and suggests using resolve_entity. It also confirms the 'type' field is currently limited to 'company'. This goes beyond the schema's basic descriptions, helping the agent use the parameters correctly.

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

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

The description clearly states the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It uses specific verbs ('get profile', 'research') and lists the exact resources queried (SEC EDGAR, XBRL, USPTO, news, GLEIF). The example queries like 'Tell me about X' make it immediately understandable, and it distinguishes itself from sibling tools by emphasizing it is a holistic alternative to chaining single-pack 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?

The description explicitly recommends this tool over alternatives: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also provides clear when-not-to-use guidance: 'names not supported (use resolve_entity first if you only have a name).' While it doesn't compare to every sibling (e.g., compare_entities, bet_research), the guidance for its primary use case is strong and actionable.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. Description confirms deletion but adds no extra behavioral details (e.g., error behavior, idempotency implications). Adequate but minimal.

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 fluff. First sentence states purpose, second provides usage guidance. Front-loaded and efficient.

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

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

Covers purpose and usage adequately for a simple tool with one parameter and no output schema. Could mention confirmation or absence of return value, 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% with description 'Memory key to delete'. Description does not add additional meaning or context 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 'Delete a previously stored memory by key', specifying the verb 'delete' and resource 'memory by key'. It distinguishes from sibling tools by mentioning 'Pair with remember and recall'.

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

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

Explicitly lists when to use: 'context is stale, task done, clear sensitive data'. Does not explicitly state when not to use, but conditions are clear enough.

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, and non-destructive. Description adds that it fetches the page, extracts information, and outputs markdown. No contradictions, but could mention potential network issues.

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 covering purpose, process, output, and use cases. No redundancy, each sentence adds value. Front-loaded with the main action.

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

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

For a simple tool with two params and no output schema, the description adequately covers what the tool does and when to use it. Missing only minor details like error behavior or prerequisites.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add additional meaning beyond the schema for parameters; it only restates their purpose.

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

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

Description clearly states the tool generates an llms.txt file for a URL, distinguishing it from siblings like ai_visibility_check and scan_competitor_ai_presence by focusing on file generation. Use cases are explicitly listed.

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 three explicit use cases for when to use the tool, but lacks guidance on when not to use it or alternatives. Still, the context is clear and helpful.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds behavioral context: null fields on unresolvable inputs and 'Keyless, plain-text API', which are not in annotations.

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

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

Two sentences: first defines purpose and outputs, second adds nuance about null handling and API type. No wasted words, front-loaded with core information.

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

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

For a single-parameter tool with full schema coverage and informative annotations, the description fully covers input, output, null behavior, and API characteristics. No missing details for agent invocation.

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

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

Schema description coverage is 100% for the single parameter. The description restates the input types and adds example values, supplementing the schema without adding significantly new semantics.

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

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

The description clearly states it is a 'one-shot lookup' for chemical identifiers, specifying input types and output fields. It distinguishes itself from sibling tools like 'resolve' or 'entity_profile' by being a specialized NCI CACTUS chemical lookup.

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 use for chemical identifier resolution, but does not explicitly state when to use versus alternatives (e.g., 'resolve', 'search_within'). No exclusions or when-not-to-use guidance 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 declare readOnlyHint, idempotentHint, and not destructive. The description adds that it returns active subscriptions by default (with optional inactive) and lists the specific fields, providing useful context beyond the annotations.

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

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

Two concise sentences, front-loaded with purpose and followed by usage guidance. No extraneous words.

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

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

Given the tool's simplicity (list, one optional parameter), the description is fully adequate. It specifies return fields and covers the parameter's effect, 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 a clear description for the only parameter. The description further clarifies the default behavior (active only) and mentions return fields, adding marginal value over 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 identifies the tool as listing the caller's active subscriptions, enumerating the return fields. It distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on review and retrieval.

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: 'review what you're monitoring before adding more or to find an id to cancel.' This provides clear context for appropriate usage and implicitly excludes scenarios like subscribing or unsubscribing.

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

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

Discloses that feedback is read by the team daily, affects roadmap, is rate-limited, and free. Annotations indicate it's not read-only (readOnlyHint=false) and not destructive, which is consistent with sending feedback. 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?

Single, well-structured paragraph. Front-loaded with purpose, then use cases, guidelines, impact, and limitations. 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?

Complete for a feedback submission tool. Covers all essential aspects: purpose, when to use, what to include, constraints, and outcome. No output schema needed; description is self-sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by advising on message length and content (1-2 sentences, 2000 chars max) and by reinforcing the enum choices. Does not repeat schema but provides practical usage context.

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

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

The description clearly states the tool's purpose: sending feedback to Pipeworx team about bugs, missing features, or praise. It distinguishes itself from sibling tools (e.g., ask_pipeworx, discover_tools) by being a feedback mechanism, not an information retrieval or analysis tool.

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

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

Explicitly describes when to use each feedback type (bug, feature, data_gap, praise). Provides specific instructions: mention Pipeworx tools/packs, avoid pasting end-user prompts. Also states rate limits (5 per identifier per day) and that it's free and doesn't count against quota.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral details: data source (CF analytics-engine), no PII, aggregated (pack, tool, count), and caching behavior (5min-1h depending on window). No contradictions with annotations.

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

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

Description is concise (5 sentences), front-loaded with the main purpose, and uses bullet points for use cases. Every sentence adds value with no redundancy.

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

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

The tool has one optional parameter, no output schema, and simple semantics. The description states what is returned (top tools, top packs, total call volume) but doesn't specify the structure (e.g., JSON format). However, given the low complexity, this is acceptable. Caching info and aggregation details provide sufficient completeness.

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

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

The single parameter 'window' is fully described in schema (enum, default). The description adds semantic context: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This goes beyond the schema's basic description, providing guidance on choosing a window. Given 100% coverage, baseline 3, and the addition is helpful but not extensive.

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 that the tool returns trending call volume data (top tools, top packs, total call volume) over a recent window. The verb 'Returns' and specific resource ('trending data') make the purpose explicit. Distinguishes itself from siblings by focusing on aggregated trending signals rather than individual 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 lists three concrete use cases (discovering hot data sources, confirming canonical tool, aligning use case). While it doesn't explicitly say when NOT to use, the use cases provide clear guidance for when this tool is appropriate. No alternatives mentioned, but the sibling list makes the distinct role clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context beyond annotations: it details the algorithms (monotonicity violations, partition-sum checks), the fill check against live CLOB depth, the semantic anchor for cross-event pairs (Jaccard similarity), the partition filter (placeholder slugs), and the response structure. 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 lengthy but every sentence adds essential information. It is well-structured: starts with the core purpose, explains modes sequentially, details algorithms and filters, and ends with response explanations and fill check. It is front-loaded with the most critical information and uses efficient formatting (backticks, lists). There is no fluff; each part contributes to understanding the 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?

Given the tool has 2 optional parameters, no output schema, and no nested objects, the description is remarkably complete. It covers all operational modes, input examples, algorithmic logic, response structure, fill check procedure, and even references a sibling tool for custom sizing. The absence of an output schema is compensated by a textual description of the response fields.

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

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

Schema coverage is 100% with both parameters documented. The description adds significant meaning beyond the schema: it explains the functional difference between event and topic modes, provides examples of valid values (slugs, seed questions), and describes how the tool behaves in each mode. This empowers the agent to choose correctly and format inputs.

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: to find arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It uses specific verbs like 'Find' and 'Call' and distinctly identifies the resource (Polymarket markets). It differentiates itself from sibling tools (e.g., polymarket_edges, polymarket_fill_risk) by specifying its unique algorithmic approach and modes.

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

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

The description explicitly explains when to use each mode: no args for trending scan, event for a specific market (recommended), topic for cross-event scanning. It provides examples of valid arguments and describes the behavior in each mode. It also advises when not to trade based on fill check results and points to polymarket_fill_risk for custom sizing, offering clear guidance on alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, making safety clear. The description adds substantial behavioral context: caching at 1h KV, edge calculation details, diagnostic sections for why segments are empty, and 24h-move warnings. No contradictions with annotations.

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

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

The description is front-loaded with purpose and segments, but is extremely long with detailed model family explanations (e.g., 'lognormal barrier from 90d FRED log-returns'). While informative, it could be more concise by summarizing model families or moving details to external docs. Every sentence earns its place, but overall length hurts 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?

Despite no output schema, the description thoroughly covers the response structure: top-level by_segment, fed_candidates, _diagnostics, and per-opportunity fields (edge_pp_net, kelly_fraction, etc.). It explains caching and filter logic. Given complexity (9 parameters, no output schema), the description is exceptionally complete.

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

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

Schema description coverage is 100%, baseline 3. The description adds meaning beyond schema by explaining tradeable-edge filters (min_liquidity, max_spread_pp) in context of execution feasibility, and provides behavioral notes like slippage_pp rationale. However, some parameters (limit, window) are already clear from schema, so not all add extra value.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, with a specific purpose of 'what should I bet on today'. It distinguishes from siblings by its focus on edge opportunities with specific segments (model_driven, structural_arbitrage, concentrated_longshot). The verb 'scan' and resource 'Polymarket markets' are precise.

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 it: 'agents discover opportunities without paging hundreds of markets'. It provides knobs (min_liquidity, max_spread_pp) for filtering tradeable edges. However, it does not explicitly mention when not to use it or name alternatives like polymarket_arbitrage or bet_research, which would strengthen the guidelines.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds valuable context: daily snapshots, response structure (tracked, expired, snapshot_dates), limits (60-day TTL, snapshot start time), and decay calculation details.

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

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

The description is dense but front-loaded with the core question. Every sentence adds value, though it could be slightly more concise with some technical details like 'decay_pp_per_day'.

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 explains the response structure (tracked, expired, snapshot_dates) and covers limitations (TTL, snapshot start). It provides complete context for understanding the tool's output.

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

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

Schema coverage is 100%, but description adds meaning with default values (days=14, window='1wk'), limits (days max 30), and explains that window is a snapshot family and gaps indicate no scans. This enhances understanding beyond the schema.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' and answers a specific question about how long an edge has existed and if it is shrinking. It distinguishes itself from siblings like 'polymarket_edges' by focusing on historical tracking rather than current edges.

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

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

The description implies usage for analyzing historical edge persistence, contrasting fresh and aged edges, but does not explicitly state when to use or not use this tool versus alternatives. No alternatives or exclusions are mentioned.

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. The description adds rich behavioral detail: 'walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict.' It warns about forced_directional_risk and explains how partial basket fills are dangerous. 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 well-structured with clear headings (SINGLE-MARKET, BASKET) and bullet-point-like lists. However, it is somewhat verbose, particularly in the warning section which could be slightly tighter. Still, every sentence serves a purpose 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 enumerates all returned fields clearly and explains the verdict system. It covers both modes, usage guidance, and risks. However, it could explicitly state that the output is a JSON object with a specific structure, but the listed fields are sufficient for an agent to understand what to expect.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema. It explains the two modes (single-market vs basket), how size_usd is interpreted differently (max spend/buy vs target proceeds; settlement notional for basket), and default behavior for side. This extra context is crucial for correct parameter 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?

The description opens with a clear, specific verb-resource pair: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It immediately distinguishes single-market and basket modes and explicitly states this tool should be used before acting on polymarket_arbitrage or polymarket_edges signals, clearly differentiating it from its 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?

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why (theoretical overround not capturable on thin books) and describes the risk of partial basket fills converting an arb into an unhedged directional position. No ambiguity about when not to use.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds extensive behavioral context: compatibility_warning scenarios, temporal alignment explanation, and meaning of safety fields. Goes far beyond annotations to disclose limitations and edge cases.

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 thorough but somewhat verbose (~300 words). Front-loaded with core purpose, but includes many details that could be condensed. Structure is logical: modes, response fields, safety fields.

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 sufficiently explains response structure (each venue's leg-by-leg prices, top_spreads_pp, safety fields). Covers compatibility_warning cases, temporal alignment, and skipped leg counters. Leaves minimal ambiguity.

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

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

Schema coverage is 100%, but description adds meaning by explaining the two modes, providing examples, and clarifying that explicit tickers override topic-mapped sides. Lists the 10 topic shortcuts.

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 computes cross-venue spread between Kalshi and Polymarket for the same resolving question. Differentiates from sibling tools like polymarket_arbitrage which focus on within-venue opportunities. Specific verb 'compute spread' and resource 'cross-venue spread'.

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?

Describes two modes (topic shortcuts and explicit tickers) and provides context on when to use, including warnings that most pre-mapped topics return compatibility_warning. However, does not explicitly compare to alternative tools or state when not to use.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds scoping details (anonymous IP, BYO key hash, account ID) and the relationship with sibling tools. This goes beyond annotations, though it doesn't cover all edge cases like missing key handling.

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

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

Two sentences with zero wasted words. The first sentence states the action and conditions; the second provides context and pairing. Information is front-loaded and directly useful.

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 simplicity of the tool (single optional parameter, no output schema), the description covers the main use cases and behavior. It lacks error handling or return format details, but for a retrieval tool in a memory system, this is acceptable.

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 is simple with 100% coverage. The description adds meaning by explaining the effect of omitting the key (list all saved keys) and clarifies the purpose of 'key' as a memory key to retrieve. This adds value beyond the schema's basic description.

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

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

The description clearly states the verb 'Retrieve' and resource 'value previously saved via remember', and distinguishes between two modes: retrieving a specific key or listing all keys. It also implicitly distinguishes from sibling tools 'remember' (save) and 'forget' (delete) by mentioning them in context.

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

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

The description explains when to use the tool: 'to look up context the agent stored earlier... without re-deriving it from scratch.' It does not explicitly state when not to use, but the context is clear enough for an AI agent to decide. The pairing with 'remember' and 'forget' provides guidance.

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

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

The description states that setting mark_read:true flags returned events as read, which implies a write operation, but annotations include readOnlyHint: true, creating a direct contradiction. According to scoring rules, a contradiction warrants a score of 1.

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

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

The description is a single paragraph that front-loads the main purpose and is reasonably concise, though it could be slightly more structured with bullets for clarity.

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

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

Without an output schema, the description sufficiently covers return values (source, citation_uri, raw event payload), filtering options, and polling compatibility. It provides comprehensive context for a retrieval 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 parameters are fully described in the schema. The description adds value by explaining the mark_read behavior ('flag returned events read so the next call only shows newer ones') and clarifying the 'since' parameter expects an ISO timestamp.

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

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

The description clearly states the tool pulls fired events from a subscription feed and returns the most recent alerts with specific fields (source, citation_uri, raw event payload). It distinguishes itself from siblings by focusing on retrieval and read operations.

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 mentions that polls work fine and provides an alternative endpoint for scripts/dashboards, giving context for appropriate usage. However, it does not explicitly state when not to use this tool versus other sibling tools.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, which the description complements by detailing actual data sources (SEC EDGAR, GDELT→GNews fallback, USPTO with sunset status), fan-out parallelism, and return format (changes grouped by source, total_changes, citation URIs). It also explains the `since` parameter's ISO/relative format behavior. No contradictions with annotations.

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

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

The description is a single well-structured paragraph that front-loads usage examples, then states core function, details sources/behavior, parameter specifics, and usage guidance. Every sentence adds value—no redundancy or fluff. Length is appropriate for the tool's complexity.

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

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

Given no output schema, the description fully specifies the return structure ('changes[] grouped by source + total_changes count + pipeworx:// citation URIs'). It covers multiple data sources, fallback logic, parameter formats, and distinction from sibling tool. The description is self-contained and sufficient for correct invocation.

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

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

Schema coverage is 100%, but the description adds significant meaning: for `since`, it lists accepted formats (ISO, relative shorthand like '7d', '30d', '3m', '1y') and suggests typical values ('30d' or '1m'). For `value`, it clarifies ticker or CIK formats. For `type`, it confirms only 'company' is supported. This exceeds the schema's basic field descriptions.

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

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

The description starts with example queries that clarify intent ('What's new with X'), then states the core function: 'change feed for a company in the last N days/weeks/months in ONE parallel call.' It lists the data sources (SEC, GDELT/GNews, USPTO) and explicitly contrasts with sibling tool entity_profile, which provides static profile. Purpose is specific, resource-oriented, and clearly differentiated.

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 this tool (for recent changes news) and provides the alternative: 'Use entity_profile instead when you want the static profile... regardless of window.' It also explains the fallback behavior (GDELT preferred, GNews on rate limit/5xx) and the soft-fail for USPTO. Clear context and exclusions 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 indicate idempotentHint=true (overwrite same key) and non-destructive. Description adds scope ('scoped by your identifier') and retention details (24 hours for anonymous, persistent for authenticated). Could mention overwrite behavior explicitly, but still adds value beyond annotations.

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

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

Four sentences, front-loaded with the core purpose, then usage guidance, then behavioral details. Every sentence adds value with no redundancy, making it concise and well-structured.

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

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

Given no output schema, the description covers purpose, usage, parameters, and behavioral traits (scope, retention) completely. For a simple write tool, it provides sufficient context for correct invocation without 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%, so baseline is 3. The description adds examples for keys ('subject_property') and explains value as 'any text — findings, addresses, preferences, notes', which helps the agent understand the intended use beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later'. It uses a specific verb ('save') and resource ('data'), and distinguishes it from siblings like 'recall' and 'forget' by mentioning them as tools to pair with.

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 provides when to use: 'Use when you discover something worth carrying forward'. It also tells the agent what to do (pair with recall/forget) and notes persistence differences between authenticated and anonymous sessions, offering clear context for use vs. 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, openWorldHint, idempotentHint, and destructiveHint. The description adds 'Keyless, plain-text API', providing useful context about authentication and interface. It does not contradict annotations and offers behavioral context beyond the structured data.

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 zero waste. It front-loads the tool identity and immediately details the functionality. 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 no output schema, the description lists all possible representations, so users know what to expect. It does not describe return format or error handling, but for a simple conversion tool with open world hint, this is sufficient.

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

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

Schema coverage is 100% with descriptions for both parameters. The description lists the possible representations and input types, but the schema already includes examples. The description adds little beyond the schema, meeting the baseline for high 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 'NCI CACTUS chemical identifier resolver' and specifies the action: convert one chemical identifier into a single representation. It lists input types and output options, distinguishing it from sibling tools like 'resolve_entity' which likely handles generic entity resolution.

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

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

The description implies usage for chemical identifier conversion but does not explicitly state when to use this tool versus alternatives such as 'resolve_entity'. It lacks exclusions or comparative guidance, relying on the user to infer from the specificity.

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 false. The description adds rich behavioral details: internal cascading lookups, exact return fields for each type, and citation URIs, going beyond annotations without contradiction.

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

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

The description is front-loaded with natural language queries, followed by a clear purpose and usage directive, then detailed breakdown of supported types. Every sentence adds value; no redundancy or fluff.

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

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

Despite lacking an output schema, the description fully compensates by detailing return values for each type, input formats, and citation URIs. Combined with strong annotations, the agent has all necessary context.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant extra meaning: for 'value' it explains auto-disambiguation for companies and examples for drugs, and indirectly clarifies output context, justifying a 4.

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

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

The description clearly states the tool resolves names to canonical identifiers (ticker, CIK, RxCUI) with specific examples. It distinguishes itself by advising 'Use FIRST whenever you have a name but need an ID,' differentiating from siblings like 'resolve' and 'identify'.

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

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

The description explicitly tells when to use this tool ('Use FIRST whenever you have a name but need an ID') and details supported entity types and input formats. It does not explicitly list when not to use it, but the directive is sufficient for most cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows it's safe. The description adds context about probing multiple entities and optional models/API keys, but doesn't disclose failure modes or rate limits.

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 (3 sentences), front-loaded with the main action, and avoids unnecessary details. 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?

Despite lacking an output schema, the description clearly states what is returned (ranked list with score, confidence, signal density per entity). It also explains the sub-call to ai_visibility_check, making the tool's behavior fully transparent.

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 important semantics: entities array has ordering (first is subject, rest competitors), and models/_apiKey are optional. This clarifies intent beyond the schema's basic types.

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 compares AI visibility across multiple entities side-by-side, using ai_visibility_check to produce a ranked list. It differentiates from sibling tools like ai_visibility_check (single entity) and compare_entities by focusing on 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 provides a use case (competitive AI-marketing audits) and an example question. It hints at alternatives by mentioning ai_visibility_check for single probes, but doesn't explicitly state when not to use this tool or list other 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?

The annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds critical behavioral details beyond annotations: it explains that the tool fans out across two sources, that partial failures degrade gracefully, that bundlephobia's first measurement on a new version can take 5-30 seconds, and that a 'sources_failed' field will list timed-out sources. This provides rich transparency about the tool's behavior and failure modes.

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

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

The description is a single paragraph that is front-loaded with the core purpose. It is comprehensive without being excessively long; every sentence adds value. It could be slightly more structured (e.g., bullet points for the return fields), but it is still concise and well-organized for its content.

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

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

Despite having no output schema, the description thoroughly details what the tool returns: a summary block (with fields like is_latest, license, published_at, advisory_count, bundle_kb_min, etc.), per-advisory detail, links, and a list of recent alternative versions. It also addresses edge cases like partial failures and timeouts. Given the tool's complexity (2 parameters, multiple data sources), the description provides complete context for an agent to understand and use the tool correctly.

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

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

The input schema has 100% description coverage: both 'package' and 'version' parameters are described. The description adds context about version defaulting to latest and scoped packages being accepted, but this information is already present in the schema descriptions. With full schema coverage, the baseline is 3, and the description does not add significant new parameter semantics beyond what the schema provides.

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

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

The description starts with a clear verb and resource: 'Composite should I add this npm package to my project check in ONE call' and specifies it fans out across deps.dev and bundlephobia. It distinctly identifies the tool's purpose and differentiates it from sibling tools, none of which perform dependency scanning.

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

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

The description explicitly states when to use the tool: whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'. It also clearly specifies the ecosystem boundary ('NPM ecosystem only in v1') and directs users to alternative tools for other ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'). This provides both positive and negative usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds specific behavioral details: BGE-base-en embeddings, cosine over 500-char windows, 200K char cap with truncation flagging. No contradictions.

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

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

Well-structured, front-loaded with core capability, then usage context, then technical details. Every sentence serves a purpose. No wasted words.

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

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

Given 3 params, no output schema, and comprehensive annotations, the description covers purpose, usage scenario, technical limits, and return structure (passages with offsets and scores). No gaps for effective tool invocation.

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

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

Schema coverage is 100%, so baseline 3. Description adds minimal value beyond schema: 'text' and 'query' descriptions mirror schema, 'limit' provides default value already in schema. The examples for 'query' are slightly helpful but not essential.

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

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

The description clearly states it performs semantic search inside a fetched record, returning top passages with offsets and scores. It distinguishes from sibling tool 'ask_pipeworx_grounded' by explaining the pairing pattern.

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 ('record too big to cram into the prompt'), and mentions alternative workflow ('Pair with ask_pipeworx_grounded'). Provides clear context for appropriate usage.

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

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

The description adds significant behavioral context beyond annotations: requires OAuth, SMS daily cap (10/day), phone verification requirement, webhook auto-disable after 10 failures, and delivery signing. These details are valuable and go beyond the idempotent, non-destructive, and non-read-only 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-organized, starting with the core purpose, then prerequisites, types, and delivery. It could benefit from bullets for readability, but all information is present 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 complexity (3 params, nested objects, multiple types, no output schema), the description covers all essential aspects: purpose, return value, prerequisites, type-specific parameters, delivery options with constraints. No major gaps are present.

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

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

With 100% schema coverage, the description still adds substantial meaning: it provides concrete examples per type (sec_8k with items, polymarket_edge with topic), clarifies delivery constraints (phone verification, SMS cap, webhook signing), and explains the structure of params deeply, far exceeding the schema's minimal descriptions.

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

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

The description clearly states the tool creates a subscription to a live-data event stream and returns the new subscription ID. It specifies the resource (proactive monitoring subscription) and action, effectively differentiating from siblings like list_subscriptions and unsubscribe by focusing on creation.

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 prerequisites (Pipeworx OAuth account), supported types, and delivery options, which guide usage. However, it does not explicitly mention when to use alternatives like list_subscriptions for querying or recent_alerts for pulling events, missing explicit when-not 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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it returns category-bucketed example questions with exact tool+argument shapes from a live catalog, providing context beyond what annotations convey.

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

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

The description is well-structured, front-loading the purpose and usage. It includes examples and alternatives without excessive verbosity, though a slightly more concise phrasing could improve readability.

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 the return format (category-bucketed example questions with tool+argument shapes) and lists specific categories. This is adequate for an onboarding tool, though more detail on output structure could enhance completeness.

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

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

Schema coverage is 100% with one parameter (topic) described. The description adds examples of valid topics (finance, pharma, betting) and notes that omitting it gives a cross-category spread, enhancing understanding beyond the schema.

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

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

The description clearly states the tool's purpose: returning category-bucketed example questions as an onboarding entry point. It distinguishes from siblings by specifying it's for when the agent doesn't know what Pipeworx can do, unlike other tools focused on specific tasks.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools', providing clear when-to-use guidance. Also mentions optional topic filtering for focus, giving effective usage context.

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

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

The description adds behavioral context beyond annotations: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts.' Annotations indicate idempotentHint=true and destructiveHint=false, which align with this description. The ownership constraint is also disclosed.

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 with first sentence stating purpose upfront. Every sentence provides necessary information without redundancy. 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?

For a simple tool with one parameter and clear behavior (deactivation), the description covers purpose, ownership, and side effects. No output schema needed; return behavior is implied. Complete and self-contained.

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

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

Schema description coverage is 100% for the single parameter 'id'. The tool description does not add extra detail beyond the schema's description, but the schema itself is sufficient. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Cancel' and resource 'a subscription by id'. It is distinct from sibling tools like 'subscribe' and 'list_subscriptions' which perform different 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?

The description explicitly mentions ownership enforcement: 'you can only cancel your own subscriptions.' This provides clear guidance on when to use the tool, though it does not name alternative tools for other scenarios.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description adds extensive behavioral context: the dual verification paths (SEC EDGAR/XBRL for financial claims, grounded pipeline for others), exact percent-delta math, output fields (verdict, actual value, citation, reasoning), and efficiency gains over sequential calls. No contradiction with annotations.

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

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

The description is long but front-loaded with key trigger phrases and efficiently organized. It first lists common user phrasings, then explains the two verification paths concisely, and finally describes the output. Every sentence contributes useful information, though slightly more brevity could improve readability.

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 explains the return structure (verdict grades, evidence with citation, reasoning). It covers both claim types, tolerance handling, and the efficiency gain. No gaps are evident for an agent to understand what the tool does and returns.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds extra value by explaining the use of tolerance_pct (overriding implied tolerance, recommended values for hallucination detection, default capped at 5). This goes beyond the schema and clarifies parameter 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 is highly specific: it defines the tool as a claim verifier against authoritative sources, with explicit trigger phrases and a clear split between financial and non-financial claims. It distinguishes from siblings by stating it replaces 4–6 sequential calls, making its purpose unique.

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 ('whenever the agent needs to check whether something a user said is factually correct') and covers both financial and general claims. It does not explicitly mention when not to use, but the broad scope implies it is the primary fact-checking tool. No direct alternatives are cited, but the purpose is clear.

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