Eu Funding Tenders

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

Annotations already declare safe read-only idempotent behavior; description adds key details: default free model, BYO key for Anthropic, and return format including per-model fields. No contradictions.

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

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

Four concise sentences front-load the core purpose and default behavior, then efficiently cover key parameters, return format, and use cases. 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?

Despite no output schema, the description clearly specifies return structure. All parameters are explained adequately, and the complexity is moderate. The description is complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, but description adds value by explaining the default model behavior, the role of _apiKey for Anthropic, and how context disambiguates. Goes beyond schema descriptions.

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

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

Clearly states the tool probes LLMs for brand visibility and scores it 0-100 per model. Distinguishes from siblings like ask_pipeworx by targeting AI-marketing audits rather than general Q&A.

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 use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. Provides context but no explicit exclusion of alternatives or when-not-to-use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real behavioral context: 'fills arguments' (automatic argument population), 'returns the structured answer with stable pipeworx:// citation URIs' (return format and citation scheme), and 'works on every tier, one fast call' (performance expectation). This goes meaningfully beyond the annotations without contradicting them.

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

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

The description is long (~230 words) for a tool definition, but it front-loads the critical directive ('PREFER OVER WEB SEARCH') and every sentence earns its place: domain list, trigger phrases, examples, escalation paths, and citation behavior. The structure flows logically from what → when → how → when-not. Slightly verbose but not bloated.

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?

This is a complex routing tool with no output schema, so the description carries the full burden of explaining return behavior, and it does: 'returns the structured answer with stable pipeworx:// citation URIs.' It covers the question-format expectation via examples, the scope of covered domains, the entry-point role, and sibling differentiation. For a tool this complex, this is remarkably 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% and the schema already documents the `question` parameter with five aliases and examples. The description enriches this with realistic query examples ("current US unemployment rate", "adverse events for ozempic", "5-day forecast for Tokyo") that illustrate the natural-language flexibility. However, the schema carries the descriptive load, so 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 is crystal clear: 'Routes the question to the right one of 5,581 tools across 1463 verified sources, returns the structured answer with stable pipeworx:// citation URIs.' It names explicit domains (SEC filings, FDA drug data, FRED/BLS, patents, real estate, weather, clinical trials, etc.) and explicitly differentiates from siblings by naming when to use ask_pipeworx_grounded or deep_research instead.

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?

Extremely detailed and actionable: 'PREFER OVER WEB SEARCH' with a list of qualifying domains, trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), three worked examples, explicit 'START HERE for most questions' entry-point guidance, and clear escalation paths ('Step up only when needed' for ask_pipeworx_grounded and deep_research).

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 read-only, idempotent, and non-destructive behavior. The description adds the beta nature, potential behavior changes when a candidate is active, and the fact that it is a full working router with no fallback. This goes beyond annotations by disclosing the experimental edge and current state.

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 yet concise, with each sentence serving a purpose: beta identification, feature equivalence, current state, usage directive, merging rationale, and fallback clarification. No filler or redundant 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?

Despite no output schema, the description states it shares the same response shape as ask_pipeworx, covering expectations. It fully explains the tool's functionality, state, and usage without leaving gaps, especially given the rich annotations and 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 covers 100% of parameters with descriptions, including aliases. The description adds minimal parameter detail ('same arguments' as ask_pipeworx) but relies on the schema, which is sufficient. 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 explicitly states it is a beta version of ask_pipeworx, a universal router with the same 5,581 tools, arguments, and response shape. It clearly differentiates itself from the stable sibling ask_pipeworx and other siblings by emphasizing its experimental routing improvements.

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

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

It directly instructs to use it exactly like ask_pipeworx when the newest routing is desired, and notes that results are compared against the stable router to decide merges. It also clarifies that currently no candidate is active, so it behaves identically, giving clear when-to-use context.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive traits. The description adds substantial behavioral context: refusal reasons, evidence as verbatim quotes, explicit refusal object structure, and the extra LLM call cost. No contradiction with annotations.

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

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

The description is dense and information-rich, covering behavior, return format, refusal reasons, use cases, and cost trade-offs. Slightly long, but each sentence adds real value; front-loading with the core purpose helps.

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 routing across thousands of sources with no output schema, the description fully explains return values, failure/refusal modes, usage context, and cost implications. It is complete enough for an agent to select and invoke the tool 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?

Schema description coverage is 100% and all parameters are aliases for a single natural-language question. The description does not add parameter-level detail beyond the schema, but the baseline of 3 is appropriate since the schema fully documents the parameters.

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 purpose: hallucination-resistant answer extraction using only tool results, and explicitly contrasts with ask_pipeworx. It clearly identifies the resource (Pipeworx) and the distinguishing grounded behavior.

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

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

Provides explicit usage criteria: use when answers will be quoted/cited/acted on and facts must not be invented, and prefer ask_pipeworx for casual lookups due to extra LLM cost. This directly addresses when and when-not to use the tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint as true. The description adds extensive behavioral details: resolution logic, fan-out, response shapes, resolver contract (confidence, alternatives), parent_event extraction, news fallback, market closed/inactive handling, wide-spread warning, and cancellation rule parsing. 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 long but well-structured with sections and examples. Essential front-loaded summary. Some redundancy could be trimmed, but every sentence adds useful information for an agent.

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

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

Despite no output schema, the description fully documents response shapes, error states, and edge cases. It covers resolver confidence, parent events, news fallback, safety mechanisms, and cancellation rules. Complete for a tool performing complex research.

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

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

Schema coverage is 100% but description adds significant value: explains depth options, market input types, include_raw tradeoffs. Provides examples of parameter usage. Agents get richer context than 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 starts with a clear verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It explains inputs (slug, URL, question text) and outputs (evidence packet + comparison). Examples of use cases ('should I bet on X') further clarify purpose. While it doesn't explicitly differentiate from sibling tools, the purpose is unmistakable.

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

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

The description explicitly states 'Use for ...' and provides concrete examples. It covers many scenarios (different bet types, fan-out examples) and includes safety notes (low-confidence short-circuits, closed markets). It lacks explicit 'when not to use' or comparison to sibling tools, but the context makes appropriate usage 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 (readOnlyHint, idempotentHint) are supplemented by detailed behavior: data sources (SEC EDGAR, FAERS), off-calendar fiscal year handling, sorting by primary metric, and return format with citation URIs. 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?

Concise yet information-dense: starts with user-facing examples, explains behavior, data sources, sorting, and efficiency claim. Every sentence adds value with no redundancy.

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

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

Given no output schema, the description explains return format (paired data + citation URIs) and sorting. It covers key behavioral aspects but could be more explicit about error handling or limits.

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

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

Schema covers 100% of parameters already, but the description adds meaningful context: type='company' pulls SEC data, type='drug' pulls FAERS data, and values are tickers/CIKs or drug names. Enhances schema beyond type definitions.

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

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

The description clearly states the tool performs side-by-side comparisons of 2-5 companies or drugs, with specific examples like 'Compare X and Y' and explicit differentiation from sequential single-pack lookups (e.g., 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?

Provides explicit guidance to prefer this tool over sequential lookups when comparing entities, and lists example query patterns. However, it does not mention specific alternative tools or situations where this tool is not appropriate.

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

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

Beyond annotations (readOnly, openWorld, idempotent), the description discloses the tool's internal process: decomposes into facets, routes in parallel, returns a findings packet with verbatim evidence, confidence, source, fetched_at, stable citation, explicit gaps[], and contradictions[] for standard/thorough depths. It also mentions latency expectations and the fact that it never invents data, adding significant behavioral context.

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

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

Despite its length, every sentence adds critical information: account prerequisites, alternative tools, scope, output structure, limitations (empty gaps), iteration behavior, and latency. It is front-loaded with the mandatory account requirement and immediately differentiates from siblings, making it efficient for an agent to parse.

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

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

For a tool with only two parameters and no output schema, the description is exceptionally complete. It covers input (natural-language question), process (decomposition, parallel routing), output (findings packet structure, gaps, contradictions), edge cases (breaking news, unpaid accounts), and performance expectations, leaving nothing essential unclear.

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 documents both parameters, but the description enriches the 'depth' enum with concrete semantics: quick=3 single hop, standard=3 default with gap recovery and contradictions scan, thorough=6 paid with iterative chases. This goes beyond the schema's high-level descriptions, explaining practical impact on research behavior and cost.

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 structured data sources in one call, and explicitly differentiates it from ask_pipeworx (single lookup) and other siblings. It gives a concrete verb (research) and resource (Pipeworx's structured data sources), making its purpose unambiguous.

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

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

It provides explicit when-to-use guidance: for broad/multi-part questions over structured data, use deep_research; for single lookups use ask_pipeworx; for breaking news or colloquial current events, prefer ask_pipeworx because it routes to live news APIs. It also notes the account requirement and that unpaid users should use ask_pipeworx, offering clear alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's safety profile is clear. The description adds value by explaining that results include full input schemas with curated examples and are ready to call directly, which goes beyond annotations. However, it could mention any rate limits or pagination 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?

Concise, front-loaded with purpose and use cases, no redundant sentences. Each sentence adds value: purpose, usage scenarios, what results look like, and calling convention.

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 discovery tool with no output schema, the description fully explains what is returned (top-N tools with names, descriptions, full schemas, curated examples). It covers all necessary context for an agent to use it correctly.

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

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

Schema coverage is 100% with all parameters described. The description adds meaning beyond schema by listing aliases (task, q, description, search) and specifying default/max for limit. It also gives natural language examples, enriching usability.

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

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

The description starts with a specific verb and resource: 'Find tools by describing the data or task.' It clearly distinguishes from siblings by positioning itself as a tool discovery/browsing utility, unlike siblings that perform specific tasks like deep_research or validate_claim.

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 when you need to browse, search, look up, or discover what tools exist for...' and provides concrete examples of domains. Also advises to 'Call this FIRST when you have many tools available and want to see the option set', which implies alternatives and sets priority.

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 that it fans out across multiple sources, that patents may soft-fail until reactivated, and returns specific fields. Annotations already indicate readOnlyHint and idempotentHint, and the description adds context about the parallelism and failure modes without contradicting annotations.

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

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

The description is dense but well-structured, starting with user intents as examples, then summarizing behavior, listing returned data, and ending with parameter notes. While slightly verbose, every sentence adds value and the front-loading with examples is effective.

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

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

Despite having only 2 parameters and no output schema, the description thoroughly explains what the tool returns, including specific fields, sources, and edge cases (soft-fail for patents). This covers the complexity of the multi-source profile adequately.

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

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

The input schema has 100% description coverage. The description adds meaning by explaining that 'type' is only 'company' and 'value' can be ticker or CIK, and reiterates that names are not supported. This goes beyond the schema descriptions, providing contextual usage hints.

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 provides a 'full cross-source profile of a US public company in ONE parallel call' and lists the data sources and returned fields. It distinguishes itself from sibling tools like resolve_entity by clarifying it does not handle names.

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 clearly advises using this tool for holistic views and explicitly states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups'. It also tells the agent to use resolve_entity first if only a name is available, providing explicit 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it states coverage ('roughly 2,400 records'), scope ('all Commission-funded work delivered in partner countries'), and enumerates the returned fields (reference, title, budget, deadline, status, zone, URL). This adds value without 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 three sentences, but they are information-dense and well-structured. The first sentence establishes the core purpose, the second provides examples, and the third distinguishes from TED. Each sentence earns its place, though the first sentence could be slightly more concise.

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

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

With no output schema, the description appropriately explains the return values ('Returns the reference, title, contract budget and currency, submission deadline, status word, geographical zone and portal URL'). It also covers the data domain and scope, and the TED distinction. Minor gaps exist around pagination behavior and status semantics, but those are partially covered by the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description's example queries ('what EuropeAid contracts are open in Nigeria') illustrate usage but do not add new meaning to the parameters beyond what the schema already provides. The status enum is already explained in the schema, and no additional constraints are documented.

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 ('Search') and resource ('EuropeAid external-action contracts'), then further specifies 'the European Commission's own development cooperation, humanitarian aid and technical assistance tenders'. It also provides concrete example queries and distinguishes itself from TED, making the tool's purpose unmistakable.

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

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

The description explicitly states a clear alternative and exclusion: 'For a contract notice published by a national or municipal buyer inside the EU, that is TED... a separate and far larger journal.' It also gives example queries, implying when to use. However, it does not contrast with other sibling tools like eu_open_calls or eu_search_calls, leaving some ambiguity among the EU-related siblings.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds significant behavioral detail beyond annotations: it specifies the exact data returned (expected-outcome, scope, conditions, budget, types of action, deadline, etc.) and mentions that text is tag-stripped. It also maps tool outputs to user intents like 'what does this fund'.

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 clear and informative, but somewhat verbose with a long enumeration and two example questions. It is well-structured and front-loaded with the core purpose, but could be slightly more concise.

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

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

Despite no output schema, the description comprehensively lists all return fields and gives example questions the tool answers. It fully compensates for the lack of output schema and leaves no ambiguity about what the tool returns.

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

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

Schema has 100% description coverage for both parameters. The description adds the same example identifier and default behavior for include_conditions, but no additional meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description explicitly states the tool returns 'Full detail for one EU funding call topic by its identifier', provides a concrete example identifier, and lists all fields returned. It clearly distinguishes from sibling tools like eu_search_calls and eu_open_calls which are for listing/searching.

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 clearly indicates when to use: when you have a specific topic identifier and need full details. It does not explicitly mention alternative tools for searching, but given sibling tool names, an agent can infer. Slight lack of explicit exclusions.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive. The description adds value by disclosing that days remaining are computed at request time, ordering by deadline, and listing output fields. 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 four sentences, each adding unique value: core purpose, example queries, output fields. No fluff or redundancy. Front-loaded with the main functionality.

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 describes return format (topic identifier, title, deadline, days remaining, type, programme, URL). Covers purpose, sorting, and parameter implications. With 100% schema coverage and clear output description, it is complete.

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

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

Schema coverage is 100% and parameters are well-documented. The description adds ordering behavior (by nearest deadline) and computed days, which is not in the schema. This provides useful semantic context beyond the parameter descriptions.

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

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

The description clearly states the tool lists currently open EU funding calls sorted by nearest submission deadline, with computed days remaining. It answers specific user queries like 'what EU grants can I still apply for,' distinguishing it from siblings like eu_search_calls (which likely searches across all calls) and eu_get_topic (which retrieves a specific topic).

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

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

The description implicitly guides when to use this tool: for open calls ordered by deadline. However, it does not explicitly exclude alternative tools or provide when-not-to-use guidance. Sibling names (eu_search_calls, eu_get_topic) suggest differentiation, but the description could be more explicit about scope.

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, and open-world hints. Description adds value by listing return fields (topic identifier, title, deadline, status, type, programme, URL) and mentioning it searches the EU Funding & Tenders Portal. No contradictions.

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

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

Two sentences: first states core purpose, second lists return fields and gives example queries. Every sentence serves a purpose; no fluff. Front-loaded with essential 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?

With 5 parameters and no output schema, description covers return fields adequately. Combined with schema, the tool is well-documented. Could mention pagination or rate limits, but not critical for a search tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning by providing example values for query and status, explaining query as optional ('Omit to list everything'), and listing supported programmes. This extra context justifies a 4.

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

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

Description clearly states the verb 'search' and resource 'EU funding calls', specifies scope (Horizon Europe and other frameworks), and provides examples. It distinguishes from siblings like eu_open_calls and eu_get_topic by emphasizing keyword search across multiple programmes.

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 what the tool does and gives example questions it answers, implying when to use it (keyword search across calls). However, it does not explicitly state when not to use it or mention alternatives like eu_open_calls for only open calls, but sibling context helps.

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 confirms the destructive nature (matching annotations) and adds context about common use cases (stale context, task done, sensitive data), but doesn't detail side effects like what happens if the key doesn't exist.

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 core action, followed by usage context. No superfluous words; every sentence earns its place.

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

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

The tool is simple (one required param, no output schema). The description covers purpose, usage guidelines, and behavioral context. No gaps for an agent to misunderstand.

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 only parameter 'key' is well described. The description merely says 'by key', adding no additional meaning beyond the schema.

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

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

The description clearly states 'Delete a previously stored memory by key.' with a specific verb ('Delete') and resource ('memory'), distinguishing it from sibling tools like 'remember' and 'recall' implied by the usage hint.

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

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

The description explicitly says when to use ('context is stale, the task is done, clear sensitive data') and mentions pairing with 'remember' and 'recall', but doesn't state explicit when-not-to-use scenarios.

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

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

Annotations already declare the tool is read-only, idempotent, and non-destructive. The description adds behavioral details (fetches page, extracts title/description/key links, emits markdown) that go beyond the annotations without contradicting them.

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

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

The description is concise with two main sentences plus a bulleted list of use cases. Every sentence adds value, and the most critical information (what it does and output) 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?

Given the tool's simplicity and no output schema, the description adequately explains the output format and usage. It is slightly lacking in specifying that the output is returned as a string, but this is minor.

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 have full schema descriptions (100% coverage). The description does not add additional meaning beyond what the schema provides, so a 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 explicitly states the tool generates a production-ready llms.txt file for any URL, specifying the target AI crawlers and the output format. It distinguishes itself from sibling tools like 'scan_competitor_ai_presence' by focusing on llms.txt generation.

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

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

The description lists three concrete use cases: getting a client's site indexed, drafting for own project, or auditing competitor visibility. This provides clear context but does not explicitly exclude types of URLs or mention when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying return fields and usage context, but no additional behavioral disclosure beyond annotations.

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

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

Two sentences conveying purpose, return fields, and usage advice. No wasted words, front-loaded with key 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?

Low complexity (1 param, no output schema) but description covers purpose, return fields, and when to use. Siblings and annotations provide full context.

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

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

Schema coverage 100% with description for the only parameter. Description does not add extra meaning beyond the schema; baseline score 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?

Clearly states 'List the caller's active subscriptions' and specifies return fields (id, type, etc.). Distinguishes from sibling tools like subscribe and unsubscribe by focusing on listing.

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

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

Explicitly tells when to use: 'review what you're monitoring before adding more or to find an id to cancel.' Implies not to use for adding/canceling, which is handled by siblings.

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

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

Beyond the annotations (all false), the description discloses rate limits (5 per identifier per day), the claim_token return/pass-back workflow, and that it's free and doesn't count against tool-call quota. It also explains what happens when filing without an account. 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?

Although long, every sentence serves a purpose: purpose, when to use, exclusions, token handling, quota, and roadmap impact. Well-structured and 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?

Despite no output schema, the description explains the token-based reply mechanism and covers edge cases (account vs no account, different MCP servers). It fully prepares 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%, so the baseline is 3. The description adds meaningful context beyond the schema, particularly for claim_token (pass with no other arguments to read status) and the overall flow, raising it 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 states a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly identifies this as a feedback tool for Pipeworx tools and distinguishes it from siblings like ask_pipeworx or discover_tools.

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

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

Explicitly lists when to use (bug, feature/data_gap, praise) and when not to use (other MCP servers' tools), even providing a rule of thumb: 'Pipeworx tool names are the ones this connection lists.' It also advises against pasting end-user prompts, adding practical guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses the data source (CF analytics-engine), lack of PII, and caching behavior (5min-1h). This adds valuable behavioral context not in annotations.

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

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

Three concise sentences: first states output, second lists use cases, third adds technical note. No redundant words. Front-loaded with key info.

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 explains what the tool returns (top tools, top packs, total call volume) and the caching behavior. No significant gaps.

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

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

Schema coverage is 100% with descriptive enum values. The main description repeats window options but adds no new meaning beyond the schema's explanation of shorter vs longer windows. Baseline 3 is appropriate.

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

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

The description clearly states it returns top tools, top packs, and total call volume over a window. The verb 'Returns' and specific resource 'top tools, top packs, and total call volume' make it distinct from siblings like 'discover_tools' or 'ask_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?

Three explicit use cases are provided (discovering hot data sources, confirming popular tool, aligning use case). It also explains window choice. However, it does not explicitly state when not to use it or mention alternatives among siblings.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral context: partition checks, semantic anchor, placeholders filter, fill check, and output structure. No contradictions.

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

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

The description is dense but well-structured with sections for modes, semantic anchor, partition filter, and fill check. While long, every sentence adds value; minor conciseness improvements could be made.

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

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

Despite no output schema, the description fully explains return fields and provides operational details like fill check and edge cases. Complete coverage of functionality and constraints for a complex arbitrage 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?

Both parameters are fully described in the input schema. The description adds meaningful context beyond schema (e.g., event mode recommended, topic mode explanation), but the schema already covers names and descriptions adequately.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes modes (trending_scan, event, topic) and provides concrete examples, differentiating from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

Explicit guidance for each argument: no args for trending_scan, event for a specific slug, topic for cross-event scanning. Also warns about fill check and when not to trade, and references polymarket_fill_risk for custom sizing.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: caching at KV level (1h), model families, tradeable-edge knobs, and response diagnostics. It also warns about edge reliability and data limitations, with no contradictions to annotations.

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

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

The description is lengthy but front-loaded with the main purpose and organized into clear sections (model families, knobs, response summary). Given the tool's complexity, the level of detail is justified, though some sentences could be trimmed for 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?

Despite lacking an output schema, the description fully explains the response structure (by_segment, fed_candidates, _diagnostics) and caching behavior. It covers edge calculation details and filtering logic, leaving little ambiguity for an agent to interpret results.

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 input schema (100% coverage), so the baseline is 3. The tool description adds value by explaining parameter interactions (e.g., min_partition_leg_kelly vs. min_kelly) and providing context like slippage_pp referencing Polymarket bid/ask depth.

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

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

The description clearly states the tool scans Polymarket markets to find opportunities where Pipeworx data disagrees with market prices. It uses specific verbs ('scan', 'return') and specifies the resource ('top Polymarket markets'), distinguishing it from siblings like polymarket_arbitrage and polymarket_edge_tracker.

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

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

The description explicitly says it's built for 'what should I bet on today' and lets agents discover opportunities without paging hundreds of markets. It also notes that Fed bets surface but are excluded from ranking, indicating a limitation. However, it lacks explicit guidance on when not 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 state readOnly, idempotent, non-destructive. Description adds snapshot-based computation, cache-miss gaps, and detailed behavior of tracked/expired data, exceeding annotation information 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?

Front-loaded purpose, then structured with ARGS, RESPONSE, LIMITS. Each sentence contributes value, though slightly verbose.

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

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

No output schema, but description fully covers return fields (tracked, expired, snapshot_dates) with explanations of derived values (trend, decay, lifespan). Adequately explains edge case of missing snapshots.

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 has 100% coverage with descriptions. Description reinforces 'lookback' and 'snapshot family' but adds minimal new meaning beyond default values and clamp range.

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?

Explicitly states it provides 'edge persistence and decay telemetry' and answers 'how long has this edge existed and is it shrinking?', clearly distinguishing it from sibling tools like polymarket_edges.

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

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

Explains that a fresh wide edge and a 3-week-old wide edge are different trades, implying when to assess edge quality over time. Lists limits (60-day TTL, snapshot availability). But no explicit when-not-to-use or sibling comparison.

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. Description adds valuable behavioral context: it walks the order book, returns verdicts (clean|degraded|cannot_fill), warns about thin legs and forced directional risk. No contradiction. One point off because annotations already cover 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?

Description is lengthy but well-structured: single-sentence purpose, then REQUIRES block, then mode-specific details. Every sentence adds value; no fluff. Could be slightly more concise, but the complexity 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?

Despite lacking an output schema, the description fully enumerates return fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict for single; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg details, thin_legs, max_clean_notional_usd, forced_directional_risk for basket). Covers modes, parameters, risks, and usage guidance completely.

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

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

Schema description coverage is 100%, baseline 3. Description adds meaning: explains default side behavior for basket mode (auto from partition sum), clarifies size_usd for basket as settlement notional, and notes default values and clamp range. This goes beyond schema basics.

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

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

Description clearly states the tool's core function: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It explicitly distinguishes two modes (single-market and basket) and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by positioning itself as a prerequisite risk check.

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 usage instructions: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why (thin books, partial fills causing directional risk) and implies when not needed (below $500 threshold). Alternatives are clear through 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. The description adds extensive behavioral detail: price divergence range (2-25pp), compatibility checks via compatibility_warning, temporal alignment, and skipped counters. No contradictions.

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

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

The description is thorough and well-structured with key sections in ALL CAPS (TWO MODES, RESPONSE, SAFETY FIELDS). Though somewhat verbose, it front-loads the core purpose and earns its length by covering complex compatibility logic.

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 compensates by detailing response fields (leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). It provides enough context for an agent to understand inputs, outputs, and edge cases.

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 meaning by explaining the two modes (topic vs explicit), providing the full list of topic values, and clarifying that explicit tickers override the topic-mapped side. Examples in schema further aid 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 begins with 'Cross-venue spread between Kalshi and Polymarket for the same resolving question', providing a specific verb+resource. It clearly distinguishes from sibling tools like polymarket_arbitrage which focus on intra-venue opportunities.

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 details two modes (topic shortcuts vs explicit tickers) and when to use each. It also warns that most pre-mapped topics return compatibility warnings, advising caution. However, it does not explicitly contrast with sibling polymarket tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds scoping and listing behavior, but no critical new behavioral details beyond annotations.

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

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

Three sentences, front-loaded with primary function, efficient examples, and pairing info. 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 simple schema and annotations, the description fully covers behavior, scoping, and usage context. No gaps.

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

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

Schema coverage is 100% with a clear description of the 'key' parameter. The description largely repeats the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: retrieving a saved value by key, or listing all keys when omitted. It distinguishes itself from sibling tools 'remember' and 'forget' by specifying the pairing.

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 explains when to use (look up stored context without re-deriving) and mentions scoping to identifiers. Pairing with remember/forget implicitly guides against using for save/delete, though no explicit 'when not to use' 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?

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds details about returned data (source, citation_uri, payload), filtering, and mark_read behavior. No contradictions with annotations.

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

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

The description is concise, consisting of 3-4 sentences. It is front-loaded with the main purpose, and every sentence adds meaningful information without redundancy.

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

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

With no output schema, the description explains what the output contains. It covers filtering, mark_read behavior, and alternative access. All parameters are described in schema. Complete for a read-only tool.

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

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

Schema coverage is 100%, but the description adds value by providing an example for the type parameter ('sec_8k') and explaining the effect of mark_read. This goes beyond the schema descriptions.

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

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

The description starts with 'Pull fired events from your subscription feed,' clearly stating the verb and resource. It distinguishes from sibling tools like list_subscriptions, subscribe, and search tools by focusing on event retrieval.

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

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

The description explains when to use the tool (to pull recent alerts), provides an alternative access method (REST endpoint), and gives guidance on the mark_read parameter. It lacks explicit exclusions or 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds details: fan-out to multiple sources, fallback from GDELT to GNews, soft-fail for USPTO, and return format (changes[], total_changes, URIs). No contradiction.

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

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

The description is two sentences, front-loaded with examples, then details the logic. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description fully explains the tool's behavior: multiple sources, fallback, time window formats, and return structure. Given the complexity, it is complete.

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

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

Schema coverage is 100%, but the description adds meaning: explains type only 'company', since accepts ISO date or relative shorthand ('7d', '30d', '3m', '1y') with preferred defaults, and value can be ticker or CIK. This enriches the schema.

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

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

The description clearly states the tool returns a change feed for a company, listing sources (SEC EDGAR, GDELT→GNews, USPTO) and the time window. It differentiates from sibling 'entity_profile' by specifying when to use each.

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

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

Explicit usage examples are given (e.g., 'what happened to Z this week'). It provides guidance on when not to use it ('use entity_profile instead for static profile'), offering clear 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?

Describes that data is stored as key-value pairs scoped by identifier, and provides persistence details. Annotations already indicate write operation; description adds valuable context without contradiction.

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

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

Front-loaded purpose, then usage, then storage details. Every sentence is necessary. No fluff.

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

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

For a simple memory save tool with no output schema, the description covers storage mechanism, scoping, persistence, and pairing with other tools. Fully 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 key and value descriptions. The description adds naming conventions and value content examples, enhancing beyond schema.

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

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

The description clearly states the tool saves data for reuse later, with specific examples (ticker, address, preference). It distinguishes from siblings recall and forget.

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

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

Explicitly says when to use (discover something worth carrying forward) and how it pairs with recall and forget. Also describes persistence differences for authenticated vs anonymous users.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description adds substantial behavioral context: every identifier is labeled with its source, unresolved identifiers are explicitly reported under `unresolved`, LEI/FIGI enrichment degrades gracefully, and the tool cascades through multiple lookup endpoints internally. It also details the ISIN-to-LEI mapping and coverage of non-US issuers, giving agents a clear mental model of what happens during execution.

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

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

The description is long but information-dense, with front-loaded examples and clear 'SUPPORTED TYPES' section. Every sentence provides useful details; minor internal details (e.g., 'pipeworx://rxnorm/concept/{rxcui} citation') could be considered extra, but overall structure is logical and free of fluff.

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

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

Given there is no output schema, the description effectively covers expected return behavior: for company, it lists CIK, ticker, company_name, LEI, and FIGI with source labeling; for drug, it names RxCUI, ingredient, brand, and a citation URL. It also explains fallback behavior when enrichment sources are unavailable, making the tool's behavior fully understandable in context.

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

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

Despite the schema describing both parameters, the description adds significant semantic depth. For `value`, it explicitly includes ISIN as an accepted input format, which the schema omits. It also explains how each input type affects resolution (e.g., ISIN resolves to the legal entity via GLEIF) and what outputs to expect per `type`, enriching the meaning beyond the bare enum and string 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 is extremely clear: it states the core action ('resolve a user-spoken NAME to the canonical/official identifiers other tools require as input') and backs it with concrete NL examples ('What's the ticker for…' / 'find the CIK for…'). It also differentiates from siblings by emphasizing that this tool feeds IDs to other tools, and lists specific supported types (company, drug) with their distinct identifier outputs.

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

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

The description gives an explicit directive: 'Use FIRST whenever you have a name but need an ID.' It also explains that using resolve_entity replaces multiple manual lookups, implying it's the recommended entry point. However, it does not explicitly state when not to use the tool or name specific alternative sibling tools, so it stops short of a 5.

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

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

Discloses internal behavior: probes each entity with ai_visibility_check, ranks by score, returns ranked list with score/confidence/density. Annotations (readOnly, idempotent) are consistent; description adds valuable behavioral context beyond annotations.

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

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

Two sentences plus a parenthetical example. Front-loaded with key action, concise, no 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?

Given no output schema, description covers return format (ranked list with score, confidence, signal density). Explains internal probe mechanism and input requirements. Complete for a multi-entity comparison tool.

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

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

Schema has 100% coverage with clear descriptions for all parameters. The description adds minor value by noting the first entity is treated as subject, but largely reuses schema info. 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 compares AI visibility across multiple entities, ranks them by score, and highlights most/least recognized. It uses specific verb and resource, and distinguishes itself from sibling ai_visibility_check by emphasizing multi-entity comparison.

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

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

Explicitly states when to use: for competitive AI-marketing audits, with a sample question. Implicitly contrasts with single-entity call via ai_visibility_check, providing clear context for selection.

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

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

Annotations (readOnlyHint, etc.) are complemented by detailed behavioral context: fans out to two services, returns specific fields, partial failures with sources_failed list, and bundlephobia's first measurement can take 5-30s. 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 thorough and well-structured with key purpose front-loaded. It covers usage, return format, ecosystem scope, and failure modes. However, it is slightly lengthy; a more concise version could achieve clarity with fewer 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 no output schema, the description fully explains the return: summary block with fields listed, per-advisory detail, links, and list of recent alternative versions. It also covers ecosystem constraints and graceful degradation, providing complete context 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 adds explicit value: scoped packages ('@types/node') are accepted, and version defaults to latest published when omitted. This goes beyond the schema's own descriptions.

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

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

The description clearly states the tool's composite purpose: a one-call check for npm packages combining deps.dev and bundlephobia data. It specifies the question it answers ('is X safe / popular / small') and distinguishes from sibling tools by noting ecosystem scope (NPM only in v1) and fallback for other ecosystems.

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

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

Explicit guidance is provided: 'Use whenever an agent asks is X safe / popular / small or what does adding lodash cost me.' It also clearly states NPM ecosystem only and that other ecosystems fall under deps.dev:version directly, preventing misuse.

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

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

Annotations already indicate safe, read-only, idempotent behavior. The description adds internal details: BGE-base-en embeddings, cosine similarity over 500-char windows, 200K char cap with truncation flag, and output format (passages with offsets and similarity scores). No contradiction with annotations.

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

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

Three sentences that are dense with information, front-loaded with purpose, then usage, then technical details. No redundant or unnecessary words; every sentence earns its place.

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

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

Given no output schema, the description covers output format (passages, offsets, scores) and truncation behavior. It addresses the tool's complexity (embeddings, chunking) and provides complete context for an AI agent to use it effectively.

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

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

Schema coverage is 100%, but description adds significant value: for 'query' it provides realistic examples (e.g., 'supply-chain risk'), for 'text' it mentions typical content (SEC 10-K, article) and the 200K cap, and for 'limit' it states default and range. This enhances understandability beyond the schema.

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

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

The description clearly states it performs 'semantic search INSIDE a fetched record,' specifying the verb and resource. It distinguishes from the sibling ask_pipeworx_grounded by explaining how the two tools complement each other, which provides differentiation and clarifies scope.

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 guidance: use when 'the record is too big to cram into the prompt,' and pairs with ask_pipeworx_grounded for grounding. This gives clear when-to-use and suggests an alternative workflow, making the usage context unambiguous.

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

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

The description adds substantial behavioral context beyond annotations, including delivery channel limits (10/day SMS, auto-disable after 10 consecutive webhook failures), verification requirements for SMS, and the return of a subscription id. Annotations already indicate non-read-only, idempotent, non-destructive, and the description does not contradict.

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

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

The description is relatively long but well-structured with sections for types and delivery channels. It is front-loaded with the core purpose and returns. Some redundancy exists (e.g., delivery details repeated), but overall efficient for the complexity.

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

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

The description covers all necessary aspects: purpose, required authentication, subscription types with examples, delivery options with constraints, and result (returns subscription id). For a complex tool with 3 parameters and no output schema, it is complete.

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

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

Schema coverage is 100%, but the description enriches each parameter with detailed examples and constraints. For example, 'type' is explained with each enum value (sec_8k, polymarket_edge, etc.) and their specific params. The 'delivery' parameter includes sub-field descriptions like phone verification and webhook signing.

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 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' It specifies the verb 'create' and the resource 'subscription', and distinguishes from siblings like list_subscriptions, unsubscribe, and recent_alerts.

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

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

The description provides clear context including authentication requirements ('Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions).') and details about when to use (monitoring live-data streams). It lacks explicit when-not or alternative tools, but the context is strong.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that it returns category-bucketed example questions with exact tool+argument shapes, drawn from a live catalog. This adds behavioral 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?

Description is front-loaded with alternative phrasings of the user query. Every sentence adds value, but it is slightly lengthy (multiple examples and enumerations). Could be tightened slightly without losing clarity.

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

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

For an onboarding tool with no output schema, the description fully explains what it returns (categorized questions with tool call details). It covers purpose, usage, and parameter options completely, leaving no gaps.

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

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

Schema coverage is 100% for the single optional parameter. Description adds meaning by listing example topic values ('finance', 'pharma', etc.) and clarifying that omission yields a cross-category spread, providing richer semantics than 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?

Description clearly states the tool is the onboarding entry point, returning category-bucketed example questions with tool+argument shapes. It specifies the verb (suggest/ask) and resource (what to ask Pipeworx), distinguishing it from siblings as the first step.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' Also explains when to omit the topic argument vs. pass a specific focus area. Provides clear guidance on use case.

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

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

Adds key behavioral details beyond annotations: ownership enforcement, deactivation vs deletion, and impact on historical events. Aligns with annotations consistently.

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, no redundancy, front-loaded with purpose and key behavioral traits.

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 one-parameter tool with rich annotations and schema, the description covers purpose, behavior, side effects, and links to sibling tool (recent_alerts) completely.

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

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

Schema coverage is 100%, so baseline is 3. Description adds little beyond 'by id' and ownership context, but parameter 'id' is already well-described in schema.

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

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

Clearly states verb 'Cancel' with resource 'subscription by id', distinguishing it from sibling tools like subscribe and recent_alerts. Ownership enforcement adds specificity.

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?

Mentions ownership enforcement and historical availability via recent_alerts, providing context. Lacks explicit when-not-to-use or direct comparisons to alternatives.

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

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

With annotations declaring readOnlyHint and idempotentHint true, the description goes well beyond that by clarifying the critical distinction between 'could_not_verify' (the check did not happen, not evidence) and 'unsupported' (no source covers it). It also discloses the two-path routing, verbatim evidence, and pipeworx:// citation format. This is rich, non-contradictory disclosure.

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

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

The description is dense but front-loaded with trigger phrases and the core purpose in the first sentence. Subsequent sentences deliver essential behavioral context (verdicts, failure modes) and end with an efficiency note. Every sentence earns its place, and the use of semicolons and em-dashes keeps it readable despite 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?

There is no output schema, so the description carries the full burden of explaining return values, which it does by enumerating all six verdict types, the actual value with citation, and reasoning. It also explains the two failure modes and the routing pipeline, ensuring an agent can invoke and interpret results correctly. For a 2-parameter tool, this is complete.

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

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

The schema already covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds value by explaining tolerance_pct overrides the implied tolerance, provides a recommended range (1–2) for hallucination detection, and notes the default cap of 5. It also gives example claims in the schema that illustrate the claim parameter's semantics.

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

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

The description clearly states the tool verifies natural-language factual claims against authoritative sources, with explicit trigger phrases like 'fact check' and 'verify the claim that…'. It also distinguishes the company-financial fast path from the general grounded pipeline, making its scope unambiguous. This differentiates it from sibling tools like ask_pipeworx or deep_research by focusing specifically on claim verification.

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 whenever the agent needs to check whether something a user said is factually correct' and explains the routing logic for different claim types. It also notes it replaces 4–6 sequential calls, implying efficiency. However, it does not name alternative tools or provide explicit 'when not to use' conditions, so it stops short of full exclusion guidance.

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