Data Energystar

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds: default model is free, BYO key for Anthropic, output includes per-model details and combined view. No contradictions.

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

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

Two concise sentences front-loading purpose and output. Every sentence provides necessary information without redundancy.

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

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

Covers purpose, output structure, cost implications, and disambiguation hint. Despite no output schema, description gives sufficient detail for an agent to understand return format. Could mention pagination or rate limits, but not critical.

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

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

Schema coverage is 100%, but description adds real-world context: default model is Workers AI Llama-3.3-70b (free), _apiKey is passed through, context helps disambiguation. This enriches schema definitions.

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

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

The description uses specific verb 'probe' and resource 'LLMs for visibility', clearly distinguishing from sibling tools like ask_pipeworx (general Q&A) or entity_profile (structured info). It also specifies output format (score 0-100).

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

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

Explicitly states use cases (AI-marketing audits, pre-launch checks, competitive monitoring) and explains when to use _apiKey. Does not explicitly exclude scenarios or name alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Beyond that, the description adds valuable context: routing to 5,439 tools, returning structured answers with stable citation URIs, working on every tier, and being a single fast call. It does not contradict any annotation, though it could further disclose potential limitations (e.g., what happens if no source matches).

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

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

The description is longer than typical but intentionally front-loaded with the most important directive ('PREFER OVER WEB SEARCH') and organized into clear sections: use cases, examples, alternatives, and caveats. Every sentence serves a purpose, though a few could be tightened without losing meaning.

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

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

Given the tool's complexity (a router over thousands of sources), the description covers its core function, return format, usage context, examples, and escape hatches to alternatives. It explains what the agent gets (structured answer with citations) despite no output schema, and it is complete enough for an agent to select and invoke appropriately.

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: all six parameters are aliases for 'question' with full descriptions. The description's examples (e.g., 'current US unemployment rate') reinforce the natural-language nature, but they add little beyond the schema's already-clear parameter definition. This meets the baseline for schema-driven 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 uses a specific verb ('ask', 'routes', 'returns') and clearly identifies the resource: a meta-tool that answers factual questions by routing to 5,439 tools across 1,412 sources. It explicitly distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, making its unique role unmistakable.

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

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

The description gives explicit when-to-use guidance ('PREFER OVER WEB SEARCH', 'START HERE', 'Use whenever...'), provides concrete examples, and names alternatives with conditions to step up ('for hallucination-resistant... use ask_pipeworx_grounded; for broad/multi-part... use deep_research'). It also clarifies exclusions for breaking-news contexts.

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

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

The description goes well beyond the readOnly/idempotent annotations by disclosing that candidate routing improvements can be enabled live during tests, that no candidate is currently active so behavior matches ask_pipeworx, and that it is a full working router with no fallback. This provides critical behavioral context for an experimental tool.

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, all valuable: identity, experimental nature, current state, usage instruction, and a clarification that it is not a fallback. No redundant or vague phrases, and the most important facts are front-loaded.

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

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

The description fully explains the tool's purpose, current behavior, and relationship to ask_pipeworx. Without an output schema, mentioning 'same response shape' is sufficient given the context, and the description covers when and how to use it.

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

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

Schema description coverage is 100%, so the parameter semantics are already fully documented. The description's statement 'same arguments' adds context about compatibility with ask_pipeworx but no additional parameter-specific detail, which is appropriate given the schema covers everything.

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 this as a beta version of ask_pipeworx, a universal router with the same 5,439 tools and arguments, and distinguishes it from the stable version by noting the experimental routing candidates. The verb 'ask' and resource 'Pipeworx' are specific, and the relationship to siblings is 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?

It explicitly instructs to use it exactly like ask_pipeworx when you want the newest routing, and notes results are compared against the stable router to decide merges. It implies ask_pipeworx is the stable alternative but does not explicitly state when not to use this beta, though the 'experimental edge' qualifier suggests caution.

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, which the description does not contradict. It adds significant behavioral detail: explicit refusal modes (with a list of refusal_reason values), an extra LLM call cost, and a promise to return a verbatim evidence quote. This goes well beyond the annotation hints.

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 about 130 words but densely packed; each sentence earns its place by covering a distinct aspect: purpose, mechanics, return contract, failure modes, usage timing, and cost tradeoff. It is front-loaded with the core value proposition and structured for quick scanning.

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

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

For a high-stakes tool with no output schema, the description is remarkably complete: it explains what the tool does, how it differs from ask_pipeworx, when to use it, what success/refusal look like (including specific refusal_reason values), and the extra LLM call cost. Nothing essential is missing.

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

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

Schema coverage is 100%—all six parameters are documented as aliases for 'question'. The description doesn't add new parameter-level syntax or formatting details, but it does reinforce that the question is natural language and used for routing/filling arguments. Since the schema already provides full descriptions, a baseline 3 is appropriate.

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

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

The description clearly states the tool is a 'hallucination-resistant answer mode' for 'high-stakes reads' that 'EXTRACTS the answer using ONLY what the tool result contains.' It distinguishes itself from the sibling ask_pipeworx by emphasizing grounded extraction and refusal on insufficient data, making the verb, resource, and scope very specific.

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

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

It explicitly says 'Use whenever an answer will be quoted, cited, or acted on' and lists high-stakes domains. It also names the alternative ask_pipeworx and gives a cost-based preference: 'prefer ask_pipeworx for casual lookups.'

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

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

The description extensively discloses behaviors beyond annotations, including resolution confidence levels, parent event extraction, news fallback mechanisms, safety short-circuiting, spread illiquidity warnings, and cancellation rule parsing. This fully compensates for any lack of annotation detail.

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

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

While the description is thorough, it is very long and lacks structural formatting (e.g., sections, bullet points). It front-loads the main purpose but becomes a dense wall of text. Some sentences are verbose; conciseness could be improved.

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

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

Given the tool's complexity and the absence of an output schema, the description is exceptionally complete. It covers resolution confidence, parent events, news fallback, cancellation rules, tradeability warnings, and more, leaving no significant gaps for the 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%, and the description does not add significant parameter-specific meaning beyond the schema's own descriptions. The tool's main purpose is explained, but parameter details (e.g., depth enum, include_raw) are already well documented in the schema.

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

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

The description explicitly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It details input types (slug, URL, question text) and output (evidence packet, market-vs-model comparison), making it clear and distinct from sibling tools.

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

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

The description provides explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also explains when the tool blocks (low confidence, closed markets, wide spreads), giving clear context for when to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. Description adds behavioral context: data pulled from SEC EDGAR/XBRL with correct off-calendar fiscal year handling, results sorted by primary metric, returns citation URIs, and is a parallel call. No contradiction with annotations.

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

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

Description is comprehensive and front-loaded with example queries. Every sentence adds value, but slightly verbose given the richness of information. Still excellent conciseness for the complexity.

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

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

Given no output schema, description fully explains return format (paired data + citation URIs), data sources, sorting, and replacement of many sequential lookups. Covers usage intent, type-specific data, and constraints. Complete and clear.

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 enriches semantics: explains what each enum value does (company pulls 10-K data, drug pulls FAERS), specifies value constraints (2–5, examples with tickers/CIKs for company, drug names). Adds context beyond schema descriptions.

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

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

Description clearly states it performs side-by-side comparison of 2–5 companies or drugs in one parallel call, listing specific data points for each type (revenue, net income for companies; FAERS counts for drugs). It distinguishes from siblings like entity_profile by emphasizing aggregation and parallel execution.

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

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

Explicitly advises 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides example queries ('compare X and Y', 'X vs Y'). Tells when to use (comparing multiple entities) and why (replaces 8–15 sequential lookups).

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 value by specifying the return fields (resource_id, name, description, category, update date) and recommending follow-up actions, but does not disclose rate limits or auth requirements.

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

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

Two sentences, front-loaded with the main action (keyword search) and return information, with no wasted words.

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

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

For a simple search tool with full schema coverage and annotations, the description covers the purpose, return fields, and a follow-up hint. It is sufficiently complete for an agent to understand usage.

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

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

The input schema already covers all three parameters with descriptions (100% coverage). The description does not add additional meaning beyond what the schema provides, meeting the baseline for full schema coverage.

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

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

The description clearly states the tool searches the ENERGY STAR Open Data catalog by keyword and returns specific fields. The verb 'Search' and resource are explicit, and it distinguishes from siblings by focusing on dataset search.

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

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

The description implies the tool is for searching datasets and suggests passing resource_id to query/metadata, but it does not explicitly compare to siblings or state when to use this tool versus 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 readOnly/idempotent, but the description discloses critical non-obvious behaviors: never invents findings (gaps[] instead), returns contradictions[] for standard/thorough, follows a second-hop iteration, semantically excerpts long records, requires an account with a paid plan for thorough, and has latency expectations. No contradiction with annotations; it fully complements them.

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

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

The description is long but tightly packed with high-value information, covering account constraints, alternatives, capability, output format, limitations, and performance. It is front-loaded with the account requirement and core purpose, and every sentence adds a new behavioral fact. Slightly dense, but the complexity of the tool justifies the length.

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

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

Given the tool's complexity and the absence of an output schema, the description is complete: it explains return structure (findings with evidence, confidence, source, fetched_at, citation), gap handling, contradictions, hop field, and expected latency. It also covers usage context, alternatives, and prerequisites. The agent has everything needed to select and invoke the tool correctly without needing to see an output schema.

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

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

Schema coverage is 100% (question and depth both described), so baseline is 3. The description adds significant meaning beyond the schema: it explains that breadth is acceptable for the question ('decomposition is the point') and elaborates the depth parameter's behavioral impact (quick=3 facets, standard=5 with gap recovery and contradictions, thorough adds lead-chasing and requires payment). This exceeds the schema's description.

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

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

The description clearly states the tool performs grounded multi-source research across Pipeworx's structured data sources in one call, with a specific verb ('researches') and resource ('1412 STRUCTURED data sources'). It explicitly distinguishes itself from open-web search and from sibling tools like ask_pipeworx, naming which sibling to use for single lookups or current-news topics.

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

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

Provides explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data' and contrasts with single lookups (ask_pipeworx) and breaking news (also ask_pipeworx). It also documents account prerequisites and depth-tier tradeoffs, so an agent can decide before invoking.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond these: it explains that results include names, descriptions, and full schemas with examples, and that each result is 'ready to call directly, no second schema lookup needed.' This enriches behavioral understanding.

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

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

The description is detailed but front-loaded with purpose and usage. Each sentence adds value, though the list of domains could be slightly trimmed without losing clarity. Still well-structured 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?

With no output schema, the description covers what is returned (top-N tools with names, descriptions, schemas) and mentions the limit parameter. It could briefly note the result format or any pagination behavior, but overall is adequate for a discovery tool.

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

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

Schema description coverage is 100% with all parameters described. The description adds additional meaning by naming aliases for 'query' (task, q, description, search) and specifying the limit parameter's default and maximum (20, max 50). This goes 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 clearly states the tool discovers tools by describing a data or task, specifying verb 'find' and resource 'tools'. It lists numerous domains and distinguishes itself from sibling tools like 'query' or 'deep_research' by focusing on tool discovery.

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

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

The description explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for' and advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear context but could be more explicit about when not to use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, read-only, non-destructive behavior. The description adds rich behavioral context: it fans out across multiple sources (SEC, XBRL, USPTO, news, GLEIF), notes that the USPTO API sunset in May 2025 and 'soft-fails until reactivated,' mentions parallel execution, and details the exact return fields. This fully informs the agent of what to expect.

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 begins with concrete example queries that immediately signal the tool's purpose, then proceeds with a dense but structured explanation of its inner workings and outputs. Every sentence earns its place; there is no redundancy or filler. The information is well-organized and front-loaded.

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

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

Despite having no output schema, the description thoroughly enumerates the return fields (cik, recent_filings with URIs, fundamentals, patents, news, LEI) and their details (e.g., 'LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC'). It also acknowledges limitations (USPTO sunset, GDELT→GNews fallback) and mentions parallel execution. For a multi-source aggregation tool, this is complete and 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?

The schema already achieves 100% coverage with clear descriptions for both parameters (type: enum with only 'company'; value: ticker or zero-padded CIK). The description adds value by re-emphasizing that names are not supported, providing specific examples ('AAPL', '0000320193'), and explicitly referencing the fallback to resolve_entity for name inputs. While helpful, the schema already covers the essentials.

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

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

The description clearly states the tool provides a 'full cross-source profile of a US public company in ONE parallel call.' It gives concrete example queries and explicitly distinguishes itself from chaining single-pack lookups or using resolve_entity for names. The verb 'profile' combined with the resource 'US public company' is specific and actionable.

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

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

The description explicitly advises to 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also states that names are not supported and directs to 'use resolve_entity first if you only have a name,' providing clear when-to-use and when-not-to-use guidance with an alternative tool.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds usage context (e.g., clearing sensitive data) but doesn't reveal additional behavioral traits beyond what annotations provide.

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

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

Two sentences: first states action, second provides usage guidance and related tools. No redundant words.

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

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

Fully adequate for a simple tool with one parameter, high schema coverage, and clear annotations. Explains action, usage, and relates to 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% and clearly documents the 'key' parameter. Description adds no extra semantic meaning beyond 'by key'.

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

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

Clearly states verb 'Delete', resource 'memory', and method 'by key'. Distinguishes from siblings 'remember' and 'recall'.

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

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

Explicitly lists when to use: stale context, task done, clear sensitive data. Mentions pairing with related tools, though no explicit when-not-to-use.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral details: fetching the page, extracting metadata, and emitting standard markdown format. This provides useful context 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 a single concise paragraph with front-loaded main action. It includes usage examples without extra fluff. Minor improvement could be bullet points for use cases, but current structure is efficient.

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

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

Given the simple tool with only 2 parameters and no output schema, the description covers the core functionality, behavior, and use cases adequately. An agent would understand what the tool does and when to use it.

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

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

Schema coverage is 100% with clear descriptions for both parameters (url and max_links). The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description specifies the tool's action (generate llms.txt), the resource (any URL), and the output format (standard markdown). It distinguishes itself from siblings by naming specific use cases and the exact output, which is unique among the listed tools.

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

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

The description explicitly lists three use cases: getting a client's site indexed, drafting for own projects, and auditing competitors. This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or alternatives.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds value by specifying the return fields and that subscriptions are for the caller, complementing annotations without contradicting.

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 covering purpose and usage; front-loaded with key information; 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 the simplicity of the tool (one parameter, no output schema), the description provides sufficient context: return fields, usage scenario, and parameter implication. Annotations cover safety.

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?

Only one parameter with 100% schema coverage; the description does not add additional meaning beyond the schema's description of include_inactive. Standard baseline.

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

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

The description clearly states the tool lists the caller's active subscriptions with specific return fields, distinguishing it from sibling tools like subscribe/unsubscribe.

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

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

Description advises using it to review monitoring before adding more subscriptions or to find an ID for cancellation, providing clear context for usage. Does not explicitly mention when not to use it, 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context beyond what annotations provide, which is adequate but not supplementary.

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

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

The description is a single, concise sentence that efficiently communicates the tool's purpose and key detail (example resource_id). No unnecessary words or structure issues.

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 (1 required param, no output schema), the description adequately explains what the tool returns (columns, types, row count, category, last-updated). It could be more complete if it mentioned the response format, but it's sufficient for a straightforward 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 the schema fully documents the parameter. The description provides an example resource_id, consistent with the schema, but adds no new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'get' and resource 'schema + metadata' for a dataset identified by resource_id, with an example provided. It distinguishes from sibling tools like 'datasets' which list datasets, while this gets details of a specific dataset.

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 when needing dataset schema or metadata, but does not explicitly state when to use this tool versus alternatives like 'datasets' for listing. No exclusions or contextual guidance is given.

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?

All annotations are false, so the description carries the full burden, and it excels: it discloses rate limiting ('Rate-limited to 5 per identifier per day'), quota impact ('doesn't count against your tool-call quota'), privacy guidance ('don't paste the end-user's prompt'), and the team's digest review process. This goes well beyond what annotations alone would provide.

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

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

The description is six sentences, but every sentence earns its place: main purpose, usage triggers, scope exclusion, identification heuristic, content guidance, and operational constraints (rate limit, quota). It is front-loaded with the verb and structured to be immediately actionable.

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 feedback tool with no output schema and a nested context object, the description fully covers all necessary aspects: what to report, when to report, scope boundaries, content expectations, and rate limits. No important behavioral or contextual information is missing.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters, so the baseline is 3. The description adds extra value by instructing how to frame feedback ('Describe the issue in terms of Pipeworx tools/packs') and by reinforcing the anti-pattern ('don't paste the end-user's prompt'), which is not in the schema. This elevates the score to 4.

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

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

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' which is a specific verb+resource statement that distinguishes it from sibling tools like ask_pipeworx or query. It clearly identifies the tool's unique role as a feedback channel rather than a data 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?

The description explicitly enumerates when to use the tool ('Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog...'), and provides a clear exclusion ('if the tool came from a different MCP server... file it with that server instead'). This is a textbook example of when-to-use and when-not-to-use guidance.

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

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

Adds rich behavioral context beyond annotations: data source (CF analytics-engine), no PII, structure (pack, tool, count), and caching policy (5min-1h). Annotations already indicate safe read operation; description enhances trust.

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 tight sentences plus bullet-like use cases. Every sentence serves a purpose: what it returns, when to use, behavioral details. Front-loaded with the most important information.

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

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

For a simple single-parameter tool with no output schema, the description fully covers output structure, data freshness, privacy, and usage scenarios. No gaps.

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

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

Schema already covers the enum fully (100% coverage). Description adds value by explaining that shorter windows show current trends and longer windows show steady-state demand, aiding parameter selection.

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

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

Clearly states it returns top tools, packs, and call volume over a window. Distinguishes from siblings like 'ask_pipeworx' and 'discover_tools' by focusing on trending data.

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

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

Lists three explicit use cases for when to use the tool (discovering hot data, confirming canonical choice, aligning use case). Does not explicitly list alternatives but provides clear context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds crucial behavioral details: monotonicity violation checks, partition-sum checks, Jaccard similarity filter, placeholder fraction filter, and the fill check that evaluates realizable edge against live CLOB depth—warning not to trade when realizable_edge_pp ≤ 0.

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

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

The description is long but well-organized, front-loaded with the core purpose. Every sentence adds value, though the density could be slightly overwhelming. Using bullet points or headings would 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 thoroughly explains response fields and behavioral context. It covers key modes, filters, and fill checks. Missing mention of rate limits or authentication, but these are not critical for a read-only, open-world 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%, providing baseline 3. The description significantly adds value by explaining what event slugs and topic strings look like, giving examples, and describing response structure (opportunities, partition_check, fill_check). This goes well 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 states a specific verb and resource ('Find arbitrage opportunities on Polymarket') and clearly distinguishes three modes (trending_scan, event, topic) with unique behaviors. It contrasts with sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection.

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

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

The description provides explicit guidance on when to use each mode (no args, event slug, topic) and includes details like semantic anchor and partition filter. It lacks direct comparison to sibling tools like polymarket_kalshi_spread, but internal differentiation is excellent.

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

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

The description goes well beyond the annotations, detailing caching behavior (1h KV), exclusion of Fed bets from ranking, and the internal logic of model families and response structure. It also explains how knobs like min_partition_leg_kelly work, providing full transparency into the tool's behavior.

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

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

The description is very long and dense, containing extensive details about model families and response structure. While this information is valuable, some of it could be condensed or moved to parameter descriptions. The front-loading is good, but overall it lacks conciseness.

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

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

Given the tool's complexity (9 parameters, no output schema), the description thoroughly explains the response structure, including by_segment segments, fed_candidates, and _diagnostics, as well as the fields within each opportunity. It covers all necessary context 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?

All 9 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds extra context for several parameters, such as the rationale for slippage_pp and the behavior of min_partition_leg_kelly, enhancing understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose: scanning Polymarket markets and returning opportunities where Pipeworx data disagrees with market prices. It explicitly mentions the use case 'what should I bet on today' and distinguishes it from alternatives by explaining the unique model families and segments.

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

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

The description provides clear guidance on when to use the tool (discovering betting opportunities without paging) and explains the tradeable-edge knobs and their effects. However, it does not explicitly mention when not to use it or differentiate from sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description is not required to restate safety. It adds value by detailing the response structure, how trends and decay are computed, and limitations like the 60-day snapshot TTL. 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 structured logically: overview, argument details, response breakdown, and limits. It is relatively long but each section earns its place by providing necessary context. The key question is front-loaded, aiding quick comprehension.

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

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

Given the absence of an output schema, the description compensates by thoroughly explaining the three response arrays (tracked, expired, snapshot_dates) with field definitions and interpretations. It also covers limitations and data sources, making the tool's behavior predictable 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?

Both parameters are already described in the input schema with 100% coverage. The description repeats defaults and constraints (e.g., days default 14, max 30) but does not add significant new semantic meaning beyond what the schema provides. It clarifies that 'window' refers to the snapshot family, which is already stated.

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: providing edge persistence and decay telemetry from daily snapshots. It uses specific verbs ('tracks', 'answers') and defines the core question 'how long has this edge existed and is it shrinking?'. While it doesn't explicitly differentiate from sibling tools like 'polymarket_edges', the context implies a distinct role in historical analysis.

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

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

The description includes concrete use context (e.g., a fresh wide edge vs. an old one) and explains the response fields. However, it does not explicitly state when to use this tool over alternatives or when not to use it. The LIMITS section provides boundary conditions but lacks comparative 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, idempotentHint, and destructiveHint, so the description adds context beyond them. It details return fields (top_of_book, vwap_fill_price, slippage_pp, verdict), modes of operation, and risks like forced directional risk, which is valuable behavioral 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 fairly long but well-structured with uppercase headings and bullet-like details. It front-loads the purpose and uses clear sections for modes. Some redundancy could be trimmed, but overall efficiently 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?

Despite no output schema, the description thoroughly explains return values for both modes, edge cases (thin_legs, max_clean_notional_usd, forced_directional_risk), and the verdict. Given tool complexity, it is comprehensive and leaves little 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 description coverage is 100%, baseline 3. The description adds meaning: explains the 'auto' default for side in basket mode, clarifies size_usd semantics ('max spend on buys, target proceeds on sells'), and describes the market/event requirement. This adds moderate value beyond the schema.

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

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

The description clearly identifies the tool as a 'realizable-vs-theoretical edge check against live CLOB order-book depth,' which is a specific verb-resource pair. It distinguishes between single-market and basket modes, and contrasts with sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

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.' Provides rationale about thin books and partial fills causing directional risk, offering clear decision criteria.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds extensive behavioral details: response format, compatibility_warning, temporal_alignment, skipped counters. 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 well-structured with sections (TWO MODES, RESPONSE, SAFETY FIELDS) and front-loaded with purpose. Every sentence adds value, though slight trimming could improve conciseness.

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

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

Given the tool has no output schema and three optional parameters, the description thoroughly covers response structure, edge cases, and safety fields. It is complete and anticipates agent needs.

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

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

Schema coverage is 100% with descriptions for all three parameters. Description adds usage patterns and examples, but the schema already provides sufficient meaning. Extra context warrants a score above baseline.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It is specific with verb 'compute' and resource, and distinguishes from sibling tools like polymarket_arbitrage.

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

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

Explicitly explains two modes (topic shortcuts vs explicit tickers), warns that most pre-mapped topics return compatibility_warning, and details when spreads are not tradeable. Provides clear when-not-to-use scenarios.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds that results are returned as JSON and that SoQL clauses omit the $ prefix. It does not cover error behavior or rate limits, but for a read-only query the annotations carry the main safety profile.

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 sentence that is front-loaded with the core action. It efficiently lists the main filter clauses and pagination options. No unnecessary words.

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

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

For a SoQL query tool, the description covers the essential aspects: dataset identification, filter syntax, pagination, and return format. It does not mention default limits or error handling, but combined with annotations it is sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with per-parameter descriptions. The description adds value by explaining that SoQL clauses should omit the leading $, which is a nuance not fully captured in the schema. It also contextualizes the parameters as part of a query language.

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

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

Description clearly states it runs a Socrata SoQL query against a specific dataset by resource_id, and names the filtering clauses. It is distinct from sibling tools like 'datasets' which list dataset metadata.

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

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

Description explains when to use the tool (to query data from ENERGY STAR Open Data) and how to structure the query (SoQL clauses without $, limit/offset). It does not explicitly state when not to use, but the context is clear.

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

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

Aligns with annotations (readOnlyHint, idempotentHint). Adds behavioral details: scoping per identifier (anonymous IP, BYO key hash, account ID), and that omitting key lists all. No contradictions.

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

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

Three sentences: core function, usage rationale with examples, and scoping/pairing info. No redundant or extraneous words. Well-front-loaded.

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

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

Given available annotations and schema, description covers what, when, how, scoping, and pairing with other tools. Sufficient for agent to use correctly. No output schema needed for this 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 100% with one optional key parameter. Description reinforces that omitting key lists all, and provides typical key examples (user_research_topic). Adds value beyond schema by illustrating 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?

Clear verb 'Retrieve' and 'list' with specific resource (saved values/keys). Distinguishes from siblings 'remember' and 'forget' by naming them. Provides concrete examples like ticker, address, research notes.

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

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

Explicitly states when to use: to look up previously stored context without re-deriving. Mentions paired tools (remember, forget). Could be more explicit about limitations (e.g., empty results for nonexistent key), but overall provides clear guidance.

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

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

The description discloses key behaviors beyond the annotations: it returns specific fields (source, citation_uri, raw event payload), explains the effect of mark_read ('flag returned events read so the next call only shows newer ones'), and implies behavior for polling. No contradictions with annotations (readOnlyHint, idempotentHint, etc.).

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

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

The description is concise (about 70 words) and front-loaded with the core purpose. Every sentence contributes meaningful information—returned data, filtering options, mark_read behavior, and alternative access method—without redundancy.

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

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

Given no output schema, the description adequately explains the return structure (source, citation_uri, raw event payload) and usage context (polling, alternative URL). It covers all necessary aspects for a read-only, idempotent tool with all optional 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?

The schema coverage is 100% (all 5 parameters described in schema). The description adds context for type (filter by type), since (ISO timestamp), and mark_read (flag as read). It does not add much for limit or unread_only, but overall 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 identifies the tool's purpose: 'Pull fired events from your subscription feed.' It specifies the verb (pull) and resource (fired events from subscription feed), and distinguishes itself from sibling tools like list_subscriptions by focusing on alert events rather than subscriptions themselves.

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

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

The description provides usage context by noting that polling works fine and that the same feed is available via a direct URL for scripts/dashboards, implying when to use the tool vs. the API. However, it does not explicitly compare to other sibling tools or state when not to use it.

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

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

Annotations already declare read-only/idempotent, and the description adds significant behavioral context: fanning out to multiple sources, fallback, soft-fail for USPTO, and return format with citations. No contradictions.

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

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

The description is a single paragraph that packs necessary information efficiently. Front-loads example queries. Could be slightly more structured but is still concise and readable.

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 explains return structure (grouped changes, total count, citation URIs). Combined with annotations, the agent has sufficient context to invoke correctly.

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

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

Schema coverage is 100%, but the description adds practical guidance (relative shorthand, typical monitoring values, ticker/CIK usage). This enhances usability beyond the schema's basic descriptions.

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

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

The description clearly states this tool retrieves recent changes (news, filings, patents) for a company over a time window. It uses specific verbs like 'change feed' and distinguishes from the sibling 'entity_profile' tool.

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

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

The description provides example queries and explicitly tells when to use an alternative ('entity_profile' for static profile). It also explains fallback behavior (GDELT→GNews) and optional 'since' formats.

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 idempotentHint and destructiveHint; description adds scoping and expiration details, but does not contradict annotations.

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

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

Front-loaded with purpose, efficient in length, but contains slight redundancy ('so you don't have to look it up again').

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 coverage of usage, parameters, scoping, persistence, and retrieval lifecycle given no output schema.

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

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

Schema coverage is 100%; description adds context on naming conventions and purpose that goes beyond raw parameter descriptions.

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

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

Clearly states the tool saves data for later reuse, with specific examples of what to store, and distinguishes from siblings (recall, forget).

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

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

Explicitly describes when to use (when discovering something worth carrying forward) and pairs with recall/forget for completeness.

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 valuable behavioral context: internal cascading through multiple endpoints, auto-disambiguation for companies, and citation URIs in results. 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-organized sentence that front-loads the most important information (purpose and usage) followed by 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?

Given the tool's complexity (two types, no output schema), the description covers return values (ticker, CIK, RxCUI, etc.), citation URIs, auto-disambiguation, and internal cascading. It is fully adequate for an agent to use the tool correctly.

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

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

Schema coverage is 100%, but the description significantly enriches the parameter meanings. For 'type', it specifies what each enum returns. For 'value', it details the accepted input forms (ticker, CIK, name for company; brand/generic for drug) and mentions auto-disambiguation, which the schema does not provide.

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 concrete user questions ('What's the ticker for...') and clearly states the core function: resolve a name to a canonical identifier. It lists supported types with specific outputs (ticker+CIK for company, RxCUI for drug), making the purpose unambiguous and distinct from sibling tools like entity_profile.

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

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

The description explicitly advises 'Use FIRST whenever you have a name but need an ID', which is strong guidance on when to invoke. It also notes that it replaces manual lookups. However, it does not mention when not to use it or suggest 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by detailing the internal process: probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, signal density. It does not contradict annotations.

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

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

Three sentences, each serving a clear purpose: what the tool does, how it works, and when to use it. No extraneous words. 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?

The description covers purpose, process, output, and use case. For a tool with 4 parameters and no output schema, it is sufficiently complete. Minor omissions (e.g., no mention of input validation or potential API dependencies beyond the schema) are acceptable given the concise format.

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

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

Schema coverage is 100% but the description adds critical semantic context: the first entity is treated as the 'subject' for narrative, and the purpose of models and _apiKey parameters is clarified (probing different AI models). This goes beyond the schema's parameter descriptions.

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

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

The description uses a specific verb ('Compare') and clearly defines the resource ('AI visibility across multiple entities'). It distinguishes itself from sibling tool ai_visibility_check (single-entity) by emphasizing side-by-side comparison and ranking, and from compare_entities by specifying the domain (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 clear context: 'Useful for competitive AI-marketing audits' with an example question. It implies when to use (comparing multiple entities) but does not explicitly state when not to use or list alternatives, though the sibling tool ai_visibility_check is naturally the single-entity alternative.

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

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

Describes partial failure graceful degradation, bundlephobia first measurement delay (5-30s), and sources_failed listing. Annotations already show read/hint, but description adds valuable behavioral details beyond.

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

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

Well-structured with purpose first, then usage, then return details, then limitations. Slightly long but 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?

Complete given complexity: composite check, multiple data sources, partial failures, no output schema. Describes return summary, per-advisory detail, links, alternatives, and limitations.

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

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

Schema coverage is 100%, so baseline is 3. Description adds that scoped packages are accepted and version defaults to latest, slightly improving clarity.

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

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

Description clearly states it is a composite check for adding an npm package, fanning out to deps.dev and bundlephobia. It specifies 'NPM ecosystem only in v1' and distinguishes from siblings by specific use case.

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small"' and notes when not to use (other ecosystems go to deps.dev:version directly). Provides clear usage triggers.

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 detail beyond annotations: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation flagging, and offset for quote verification. Annotations already indicate read-only, idempotent, non-destructive; description concords with these.

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

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

Every sentence conveys unique, essential information without redundancy. Front-loaded with key purpose and usage, then technical specifics. Very 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 semantic search tool with no output schema, the description covers purpose, when to use, technical details, limitations (200K truncation), and output characteristics (passages with offsets and scores). Pairs with sibling tool. No gaps identified.

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

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

Schema coverage 100% (baseline 3). Description adds examples for 'text' (SEC 10-K body, article) and 'query' (natural-language examples), explains limit range and default, and clarifies that text is the already-fetched document. This improves agent understanding beyond schema.

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

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

The description clearly states it performs semantic search inside a fetched record, with specific verb 'search within' and resource 'text'. It distinguishes from siblings like ask_pipeworx_grounded by explaining the pairing strategy.

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 when the record is too big to cram into the prompt', providing clear context. Mentions pairing with ask_pipeworx_grounded. Lacks direct when-not-to-use, but the use case is well-defined.

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 write operation with idempotency and non-destructive behavior. The description adds behavioral context: requires Pipeworx OAuth account, cannot persist for anonymous/BYO, provides SMS limits (10/day), webhook auto-disable after 10 failures, and returns subscription id. No contradictions.

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

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

The description is well-structured with a clear front-loaded purpose sentence. It efficiently covers requirements, supported types with examples, and delivery channels without redundant information. Every sentence adds value.

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

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

For a complex tool with 5 type enums and nested params, the description covers most key aspects: return value (id), constraints (OAuth, SMS cap, webhook auto-disable), and delivery options. It lacks explicit guidance on error scenarios or idempotent retry behavior, but given no output schema, it is reasonably complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds concrete examples for some types (sec_8k, polymarket_edge, fred_series) but does not cover patent_grant and clinical_trial in the narrative, though the schema's param description does. Overall, the description adds value but not beyond baseline for parameter understanding.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream. It distinguishes from siblings like 'unsubscribe' and 'list_subscriptions' by virtue of being the creation action.

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

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

The description provides context for when to use the tool (to set up real-time monitoring) but does not explicitly mention when not to use it or compare directly to sibling tools like 'recent_alerts'. However, it implies usage scenarios through type examples.

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 cover readOnly, openWorld, idempotent, and non-destructive nature. The description adds value by detailing the return content (category-bucketed example questions with tool+argument shapes). No contradictions.

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

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

The description is front-loaded with example questions and is somewhat lengthy but each sentence serves a purpose. A minor trim could improve conciseness, but it remains effective.

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

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

Given no output schema, the description sufficiently explains the return type (categorized examples). It also references the tool catalog and meta-tools, covering all needed context for an introductory tool.

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

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

Schema coverage is 100% with the only parameter 'topic' documented in both schema and description. The description adds no new meaning beyond what schema provides, so baseline 3 is appropriate.

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

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

The description clearly identifies it as the onboarding entry point, explaining it returns categorized example questions. It distinguishes itself from sibling tools by being the first tool to use when learning about Pipeworx.

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

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

Explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains optional topic filtering and learning meta-tools. Provides clear context for use.

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

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

Discloses that the subscription is deactivated (not deleted) and historical events remain available via recent_alerts. This adds value beyond annotations (idempotentHint, destructiveHint false) by explaining the exact effect.

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 action, ownership, and side effect. No wasted words, information is front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, ownership constraint, and behavioral outcome (deactivation). 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 already provides 100% coverage with clear description for the single parameter 'id'. No additional parameter details needed; baseline score applies.

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

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

Verb 'Cancel' with resource 'subscription' is clear and specific. Distinguishes from sibling 'subscribe' by indicating cancellation of existing subscriptions.

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

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

Explicitly states ownership enforcement ('you can only cancel your own subscriptions'), providing clear when-to-use context. Does not explicitly mention alternatives or when not to use, but the constraint is sufficient.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral details: the two-tier verification process (structured vs. grounded pipeline), exact percent-delta math for financial claims, verdict types, citation mechanism, and the fact that it replaces multiple sequential calls. 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 fairly long but efficiently packed with essential information. It uses clear natural language, front-loads the purpose with query patterns, and structures the two processing paths logically. Could be slightly trimmed without losing clarity, but earns its length.

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

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

Given the complexity of the tool (claim verification with multiple routes and verdicts), the description covers: input format, two processing paths, verdict types, return components (actual value, citation, reasoning), and performance benefit (replaces 4-6 calls). No output schema is provided, but the return structure is fully described. Highly complete.

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

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

Schema coverage is 100% with both parameters described. The description adds context beyond the schema: tolerance_pct default behavior ('implied by wording, capped at 5') and override use cases ('set 1-2 for hallucination detection'). The claim parameter is given example formats. This adds significant meaning but the schema already provided solid 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 uses specific verbs ('verify', 'check', 'confirm or refute') and clearly identifies the resource ('natural-language claim verification against authoritative sources'). It distinguishes itself from siblings by noting it replaces 4-6 sequential calls and describes two distinct processing paths.

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 describes the two routing paths (SEC EDGAR for financial claims, grounded pipeline for others). It lacks explicit when-not-to-use rules but provides sufficient context for decision-making.

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