Complex Portal

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond: default model is Workers AI Llama-3.3-70b (free), Anthropic requires an API key with direct payment to Anthropic, and it returns per-model {score, confidence, signals, raw_response} plus combined view. No contradictions.

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

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

The description is moderately concise and front-loaded with the core action. Every sentence adds value, though the list of use cases could be shortened. Still well-structured 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?

Given the tool's complexity (multi-model, optional key, scoring), the description covers purpose, default behavior, key requirements, return structure, and use cases. No output schema exists, but the return format is described adequately for invocation.

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

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

Schema description coverage is 100%, and the description adds valuable context: entity examples (e.g., 'Pipeworx'), model options ('workers-ai', 'anthropic'), API key format (sk-ant-...), and context example ('Boston restaurant'). This enriches understanding beyond the schema.

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

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

The description clearly states the tool probes LLMs for knowledge of an entity and scores visibility (0-100) per model. The verb 'probe' and resource 'LLMs' are specific. The purpose is distinct from sibling tools like ask_pipeworx or deep_research, as it focuses on AI visibility scoring.

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

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

The description provides explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains when to provide an API key for Anthropic. While it lacks explicit 'when not to use' or alternatives, the context is clear enough for an agent to decide.

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. The description adds valuable behavioral context about the routing mechanism, automatic argument filling, one fast call, and the structured output with citation URIs. It does not mention any side effects, which aligns with the annotations, but omits potential edge cases like rate limits or failure modes. Given the strong annotation coverage, this is a solid 4.

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 every sentence earns its place. It is front-loaded with the key preference directive, followed by a categorized list of use cases, concrete examples, and explicit alternatives. The logical structure and pragmatic ordering make it readable despite its length, and no information is wasted.

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 read-only router tool with no output schema, the description is complete: it explains the return format (structured answer with citations), provides multiple examples, covers spatial and temporal scoping (current/historical), and explicitly differentiates sibling tools. Combined with rich annotations and a fully described schema, this leaves minimal ambiguity for an agent.

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

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

The schema has 100% description coverage, with the question parameter described as 'Your question or request in natural language' and all aliases enumerated. The description's examples are helpful but largely redundant with the schema's own examples, so it does not materially enrich parameter understanding beyond the schema. The baseline of 3 is appropriate.

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

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

The description clearly states that this tool routes questions to one of 5,529 tools across 1455 verified sources and returns a structured answer with stable pipeworx:// citation URIs. It distinguishes itself from siblings by explicitly naming ask_pipeworx_grounded and deep_research as alternatives for different use cases.

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

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

The description explicitly instructs to prefer this over web search for specific data categories, says 'START HERE for most questions' and 'this is the default entry point', and provides clear step-up guidance to ask_pipeworx_grounded and deep_research. It also addresses breaking news scenarios, giving precise when-to-use and when-not-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?

While annotations already indicate readOnly, idempotent, openWorld, and non-destructive behavior, the description adds important context: it is the experimental edge, with candidate routing improvements enabled live whenever under test, and it is a full working router rather than a fallback. This dynamic status information is not available in annotations and helps set expectations about potential behavior changes.

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 tightly written in four sentences, leading with the core purpose, then the current experimental state, the usage directive, and a clarifying note that it is a full router. There is no fluff, and each sentence adds necessary information for an agent evaluating the tool.

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

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

Given the tool's complexity as a router to 5,529 tools, the description covers the essential points: what it is, its current behavior (identical to ask_pipeworx), and when to use it. It also mentions the same response shape, which compensates for the absence of an output schema. However, it could be slightly more explicit about stability trade-offs or when to prefer the stable version, leaving a small gap.

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 fully documents all six parameters with 100% coverage, including the primary 'question' parameter and five aliases. The description does not need to repeat parameter details since the schema is self-sufficient; it adds no additional parameter semantics beyond what the schema provides.

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

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

The opening phrase 'Beta version of ask_pipeworx: identical universal router' immediately establishes this as an experimental variant of the ask_pipeworx tool. It further clarifies it routes to the same 5,529 tools with the same arguments, distinguishing it from the stable sibling ask_pipeworx by its beta status and live candidate 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?

The description explicitly directs: 'Use it exactly like ask_pipeworx when you want the newest routing,' which tells the agent when to choose this over the stable router. It also notes that results are compared against the stable router, and that no candidate is active right now, so it currently matches ask_pipeworx exactly—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?

Even with annotations (readOnly, idempotent, openWorld, non-destructive) present, the description adds significant behavioral context: refusal modes and reasons, return format with evidence/confidence/source, and the extraction-only policy. No contradictions with annotations.

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

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

The description is dense but well-structured: it front-loads the core purpose, then explains mechanism, return format, use cases, and cost in a logical flow. Every sentence contributes, but it is slightly long and could be tightened without loss.

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

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

Without an output schema, the description fully specifies the return object (answer, evidence, confidence, source, fetched_at, refusal_reason) and all refusal reason enums. This makes the tool's behavior predictable for an agent. It's complete despite the complexity of the routing and extraction logic.

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

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

Schema coverage is 100%, and the description does not add meaning beyond the schema. The only parameter (question) is well-described in the schema with aliases; the description's mention of 'fills arguments' is generic and not parameter-specific. Baseline 3 applies.

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

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

The description clearly states a specific verb+resource: 'Hallucination-resistant answer mode for high-stakes reads.' It explains the tool's mechanism (fetches data, extracts answer only from tool result) and explicitly distinguishes it from sibling ask_pipeworx while sharing the same routing.

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

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

Provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and gives a clear alternative: 'prefer ask_pipeworx for casual lookups.' Also notes the cost trade-off of one extra LLM call, helping decision-making.

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

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

Annotations provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds extensive behavioral context beyond annotations: resolver contract, parent_event extractor, news fallback fields, safety short-circuits, closed market handling, wide-spread warnings, and resolution-rule risk. No contradiction with annotations.

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

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

The description is very long and detailed, covering multiple aspects. While front-loaded with purpose, it could be more concise. Some sections (fan-out examples, resolver contract) are extensive but necessary for completeness. Balancing thoroughness and brevity, it loses points for 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 no output schema, the description fully covers response shapes (market, analysis, evidence), edge cases (low confidence, closed markets, wide spreads), and important behavioral notes (cancellation rules, parent events, news fields). An agent can predict tool behavior accurately.

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 description adds significant meaning: explains market input types (slug, URL, text), depth options (quick vs thorough with default), and include_raw behavior (summary vs full payload). Provides examples and recommendations, e.g., 'Default false (recommended)'.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the input types, the workflow (resolves, classifies, fans out), and provides explicit use cases ('should I bet on X'). This distinguishes it from sibling tools like polymarket_edges or polymarket_arbitrage.

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

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

The description gives explicit usage guidance: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also explains when the tool short-circuits (low-confidence, closed markets) and provides field-by-field behavioral notes. However, it does not explicitly list alternatives or when not to use this 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 indicate safe read-only, idempotent, open-world. Description adds rich detail: pulls specific financial data (revenue, net income, cash, debt) from EDGAR/XBRL with off-calendar handling, and for drugs FAERS counts, FDA approvals, trial counts. Notes sorting by primary metric and returns paired data + 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?

Description is dense but efficient; every sentence adds value. Front-loaded with examples and usage guidance. Slightly verbose but not wasteful. Could be trimmed marginally, but structure is logical.

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 and two entity types with different data sources, description is highly complete. Covers what data is returned per type, sorting, citation URIs, and efficiency gains. No gaps for agent to guess.

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

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

Schema coverage is 100%. Description adds meaning beyond schema: explains that type='company' pulls latest 10-K data, type='drug' pulls adverse-event/trial data; values examples show tickers vs drug names, constraints on array size. Provides concrete context for parameter use.

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

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

Description clearly states the tool performs side-by-side comparison of 2–5 companies or drugs, with numerous example queries. Distinguishes from sequential single-pack lookups. Specific verb+resource: compare entities.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' Provides clear context for when to use and examples of queries that trigger this 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?

Beyond annotations (readOnly, idempotent), the description discloses many concrete behaviors: account requirements, paid tier for 'thorough', time expectations (15-60s, up to ~90s), the fact that it does NOT do open-web search, the format of the findings packet (verbatim evidence, confidence, source, citations), gaps[] for unanswered facets, contradictions[] for disagreeing findings, and semantic excerpting behavior. This is far more transparent than the annotations alone.

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 with valuable information and front-loaded with the most critical constraint (account requirement). However, it is a long single paragraph, which could be better organized with line breaks or bullets. Every sentence earns its place, but the wall-of-text structure reduces scannability. Thus slightly below a perfect 5.

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

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

Given that there is no output schema, the description thoroughly explains return values (finding packet fields, gaps[], contradictions[], citation_uri, hop) and failure modes (empty gaps[] for non-catalog topics). It also covers edge cases like large-record excerpting and performance expectations, making the tool's behavior fully predictable for an agent. Completeness is outstanding.

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

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

The input schema already covers both parameters with detailed descriptions, and the description adds meaningful nuance: it clarifies that the question can be broad/multi-part (decomposition is the point) and explicitly notes that depth='thorough' requires a paid plan, which is not in the schema. This helps parameter selection beyond the schema, though much of the depth-level detail is redundant with the schema.

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

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

The description clearly defines the tool as a multi-source research engine over Pipeworx's structured data, with a specific verb ('research'), resource ('1455 STRUCTURED data sources'), and scope ('in ONE call'). It explicitly distinguishes itself from ask_pipeworx for single lookups and from open-web search, making it easy to differentiate from siblings.

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

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

Usage is exceptionally well-defined: 'Best for broad/multi-part questions over structured data' gives a positive use case, while negative cases are explicit ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'). It also covers account tier requirements and when to use which depth level.

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, idempotentHint, and destructiveHint, which the description complements by explaining the return format: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' This adds behavioral detail beyond annotations.

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

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

Description is compact yet comprehensive: states purpose, usage, return characteristics, and a direct instruction ('Call this FIRST...'). No redundant sentences; all earn their place.

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

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

Given the tool's complexity (discovery with aliases, no output schema), the description fully covers what it does, when to use it, and what the output contains. No gaps remain.

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

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

Schema coverage is 100% with 6 parameters all described. The description mentions query and limit but doesn't add significant meaning beyond schema aliases and examples already present. Baseline score of 3 is appropriate as the description adds minimal extra semantic value.

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

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

The description clearly states 'Find tools by describing the data or task' with a specific verb (find), resource (tools), and method (natural language query). It distinguishes from sibling tools like search_complexes or ask_pipeworx by focusing on discovery of available 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?

Explicit guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Lists concrete use cases (browse, search, look up) and domains (SEC filings, FDA drugs, etc.), implicitly telling when not to use it (when you need a single answer from a specific 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds rich behavioral context: parallel fan-out across multiple sources, returns specific fields like cik, recent_filings with URIs, fundamentals, patents (with soft-fail note), news via GDELT→GNews fallback, and LEI via GLEIF. 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 somewhat lengthy but well-structured: starts with examples, then clear guidelines, then detailed list of returns and limitations. Every sentence provides value; could be slightly tightened but remains effective.

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

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

No output schema exists, so the description must explain returns. It covers all returned fields (cik, filings with URIs, fundamentals, patents, news, LEI) and limitations (names not supported, patents sunset). For a complex multi-source tool, this is highly complete.

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

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

Schema coverage is 100% with descriptions for both parameters. The description restates the same info (type must be 'company', value can be ticker or zero-padded CIK, names not supported) but adds minimal extra meaning beyond the schema. The patents sunset note is not parameter-specific.

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 multiple user-query examples like 'Tell me about X' and 'company profile for Microsoft', clearly specifying the verb+resource: providing a holistic cross-source profile of a US public company. It explicitly states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups', distinguishing it from sibling tools like resolve_entity.

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

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

The description provides explicit when-to-use (user asks for a holistic view) and when-not-to-use (if only a name exists, use resolve_entity first). It also mentions the patents feature may sunset, guiding appropriate use. No sibling alternative is more appropriate for holistic profiles.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description confirms the delete operation and adds context about clearing sensitive data. 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?

Extremely concise: only two sentences plus a pairing hint. 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?

Single-parameter, simple operation. Description covers purpose, usage, and pairing. Completeness is appropriate for the tool's complexity.

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

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

Schema coverage is 100% and the description does not add significant meaning beyond the schema's 'key' parameter description. The phrase 'memory key' is slightly more specific but not transformative.

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

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

The description clearly states the action ('Delete'), the resource ('previously stored memory'), and the method ('by key'). It distinguishes from sibling tools 'remember' and 'recall'.

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

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

Provides explicit usage scenarios: when context is stale, task done, or clearing sensitive data. Also suggests pairing with 'remember' and 'recall'. No explicit 'when not to use', but the positive guidance is sufficient.

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

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

Annotations confirm safe, read-only, idempotent behavior. The description adds details about what it does (fetch, extract title/description/links, emit markdown), which goes beyond 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: two main sentences and a bullet-like list of use cases. It is front-loaded with the core purpose. No wasted words, but could be slightly more structured.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers the key aspects: input URL, output format, and use cases. No critical gaps are apparent.

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

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

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

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

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

The description clearly states it generates a production-ready llms.txt file for any URL, distinguishing it from sibling tools like ai_visibility_check or scan_competitor_ai_presence. It specifies the action (generate), resource (llms.txt), and purpose (index by AI crawlers).

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

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

The description provides explicit use cases (client site indexing, own project, competitor audit), but does not mention when not to use it or list alternative tools. This gives clear context for typical usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds behavioral context: it returns participants with UniProt IDs, roles, stoichiometry, and other fields. It also notes 'Keyless' meaning no authentication needed, which is not in annotations.

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

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

Two sentences with no wasted words. First sentence clearly states action and example; second sentence lists return content and context.

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 read tool with comprehensive annotations, the description covers purpose, return structure, and context (keyless, complements other resources). No output schema exists, but the description explains return values 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 already fully describes the single parameter with an example. The description adds 'by its accession' but does not significantly enhance meaning beyond what the schema provides.

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

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

The description clearly states it retrieves a single Complex Portal record by accession, with an example (CPX-7762). It distinguishes itself from sibling tools like search_complexes by focusing on a specific fetch by ID.

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

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

The description mentions 'Keyless' and 'Complements UniProt/IntAct/STRING', providing context for when to use this tool (access by accession) and implying alternatives. However, it does not explicitly state when not to use it.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds return field details and parameter behavior (include_inactive), but does not disclose additional behavioral traits beyond what annotations already cover.

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

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

Two concise sentences, front-loaded with purpose and usage. Every sentence adds value with no redundancy.

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

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

The description fully covers purpose, usage, returned fields, and parameter behavior for this simple tool. No gaps given the lack of output schema and single optional parameter.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add new meaning beyond the schema's description for the single parameter; it only reiterates the default behavior.

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

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

The description clearly states the tool lists the caller's active subscriptions and explicitly lists returned fields (id, type, params, created_at, last_fired_at, fire_count). This distinguishes it from siblings like subscribe and unsubscribe.

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

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

The description explicitly states when to use this tool: 'review what you're monitoring before adding more or to find an id to cancel.' This provides clear context and 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?

Even though annotations provide some safety signals (readOnlyHint: false, destructiveHint: false), the description adds substantial behavioral context: filing without an account returns a claim_token that can be used later to check resolution, there's a rate limit of 5 per identifier per day, and it's free and does not count against tool-call quota. None of this contradicts the annotations.

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

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

Although the description is long, every sentence earns its place: purpose, usage triggers, exclusion rule, identity heuristic, message-format guidance, token behavior, team response cadence, rate limit, and cost. The most critical info (what it does, when to use) is front-loaded; supporting details are organized logically.

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, but the description explains both immediate return behavior (claim_token) and how to later retrieve status/change details. It covers message specificity, context structure, constraints, and the feedback lifecycle. Compared to sibling tools, this is fully specified for a feedback/reporting tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra value by illustrating the claim_token usage pattern with an executable example and clarifying that it should be passed with no other arguments. It also reinforces the type enum and message requirements without duplicating schema text verbatim.

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

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

The description opens with a clear action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It names the concrete resource (Pipeworx team/feedback) and distinguishes this tool from sibling tools like ask_pipeworx or discover_tools by focusing on reporting issues, gaps, or praise rather than requesting information.

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

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

The description gives explicit when-to-use guidance: bug reports (wrong/stale data), feature requests, data gaps, and praise. It also states a firm when-not-to-use rule: only for tools served by this Pipeworx connection, not other MCP servers, and even provides a heuristic ('Pipeworx tool names are the ones this connection lists').

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

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

Annotations already mark it read-only/idempotent. Description adds value: data source (CF analytics), no PII, caching behavior (5min-1h). 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?

Five sentences front-load core function and use cases. Efficient but not minimal; 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 single optional parameter, rich annotations, and no output schema, description covers purpose, use cases, data derivation, privacy, and caching 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 covers parameter fully; description adds semantic guidance on window choice for hot vs steady-state demand.

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

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

Description clearly states it returns top tools, top packs, and call volume over windows, distinguishing it from siblings like 'discover_tools' by focusing on what other agents are calling.

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

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

Explicitly lists three use cases and explains window selection (short for hot, long for steady-state). No explicit when-not-to-use, but context is clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds extensive context beyond these: it explains the algorithms, filters (Jaccard similarity, placeholder fraction), fill check mechanics, and response structure. 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 somewhat verbose with multiple paragraphs, but it is front-loaded with the main purpose and each sentence contributes value. For a tool with this complexity, the detail is justified, though a slightly more concise version could be possible.

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 modes, algorithmic details, filters, and output structure comprehensively. However, it lacks explicit error handling or edge case descriptions, which slightly reduces completeness given the tool's complexity and lack of output schema.

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

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

Although the input schema already describes both parameters with 100% coverage, the description adds significant meaning: it explains the difference between event and topic modes, provides example slugs and seed questions, and describes the underlying logic, greatly enriching parameter understanding.

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

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

The description clearly states 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks', specifying the verb, resource, and method. It distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection using these specific algorithms.

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

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

The description provides explicit guidance on when to use each mode: 'Call with NO args for a trending_scan', 'pass event...', or 'topic...'. It recommends event for specific markets, explains cross-event mode benefits, and directs users to polymarket_fill_risk for custom sizing, showing 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description goes far beyond, detailing caching (1h KV-level), model families, slippage subtraction, edge calculations, and diagnostics. No contradiction with annotations.

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

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

The description is lengthy but well-structured with clear segments (model families, knobs, response structure). Every paragraph adds necessary detail for a complex tool. Could be slightly more concise, but the organization aids 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 no output schema, the description fully explains the response structure (by_segment, fed_candidates, diagnostics), edge components, caching behavior, and filter knobs. It covers edge cases like Fed bets and why they are excluded. Complete for a multi-model scanning 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%, and the description adds substantial context beyond schema descriptions, such as the meaning of min_kelly (skipping small bets), min_partition_leg_kelly (filtering thin partitions), and slippage_pp (Polymarket zero fees but bid/ask costs). This adds genuine value for parameter understanding.

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

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

The description explicitly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, with a clear use case 'what should I bet on today'. It distinguishes from siblings like polymarket_arbitrage by focusing on model-driven and structural arbitrage signals.

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

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

The description clearly frames the tool for daily betting discovery without paging, and provides detailed parameter knobs (e.g., min_liquidity, max_spread_pp) to filter realizable edges. However, it does not explicitly contrast with alternative tools like polymarket_arbitrage or explicitly state when not to use it.

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

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

The description goes well beyond annotations, which already indicate readOnly, openWorld, idempotent. It details the response structure (tracked[], expired[], snapshot_dates[]), explains decay computation (daily closes of edge_pp_net, net of slippage, not intraday), and notes history bounds (60-day TTL, from snapshot enablement). 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 informative but on the longer side, with multiple paragraphs explaining response fields and limits. While well-structured, it could be more concise by consolidating some details. It is front-loaded with the core purpose, which is good.

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 compensates by explaining the response structure in detail (tracked[], expired[], snapshot_dates[] with field meanings). It covers limitations (TTL, snapshot enablement) and nuances (decay numbers from daily closes, not intraday). This makes the tool fully understandable without additional documentation.

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

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

Schema coverage is 100%, so the description adds marginal value. It restates defaults and clamps (days: default 14, max 30; window: default '1wk') which are already in the schema. The description includes 'snapshot family' for window, but this is not a significant addition beyond the schema's description.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily polymarket_edges snapshots. It answers the specific question 'how long has this edge existed and is it shrinking?' and distinguishes itself from sibling tools by focusing on time-series analysis rather than raw data. The verb 'tracker' and resource 'polymarket_edges snapshots' are explicit.

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

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

The description implies when to use this tool: when you need to assess edge persistence over time, noting that a fresh wide edge and an old wide edge are different trades. It does not explicitly list alternatives or when not to use it, but the context is clear enough for an AI agent to infer appropriate usage.

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

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

Annotations declare readOnly, openWorld, idempotent, non-destructive. The description adds context: requires one of market or event, returns verdicts (clean|degraded|cannot_fill), and warns about forced directional risk. 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 somewhat lengthy but well-structured with capitalized mode labels (SINGLE-MARKET, BASKET) and bullet-like enumerations. Every sentence adds value, though a more structured format could improve readability.

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

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

No output schema exists, but the description comprehensively lists all return fields for both modes (e.g., top_of_book, vwap_fill_price, verdict, capture_ratio, thin_legs). It also explains the logic behind verdicts and basket risks, making it self-contained.

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

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

Schema description coverage is 100%. The description adds extra semantic value beyond the schema, such as the default for side in basket mode (auto from partition sum) and clarifying size_usd for baskets as settlement notional per leg.

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 a 'Realizable-vs-theoretical edge check' and distinguishes between single-market and basket modes. It contrasts with siblings like polymarket_arbitrage and polymarket_edges by focusing on fill risk assessment.

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

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

Explicitly advises: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why theoretical overround is not capturable on thin books and warns about partial basket fills creating unhedged positions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral context: safety fields (compatibility_warning, temporal_alignment), skipped counters for cross-type mismatches, and explanation of when spreads are meaningless. It also describes the output structure (leg-by-leg prices, top_spreads_pp). No contradiction with annotations.

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

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

The description is long but well-structured with clear headings (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence adds value, and the most important information (what the tool does and both modes) is front-loaded. Given the complexity of the tool, the length is appropriate and not 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?

Despite no output schema, the description fully covers input modes, output structure (raw probabilities, top spreads, safety fields), and edge cases (compatibility warnings, temporal alignment). It is complete for an agent to select and use the tool correctly, with no apparent gaps.

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

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

Schema coverage is 100%, so the schema already describes all three parameters. The description adds value by listing the exact topic shortcuts, explaining that explicit tickers override the topic side, and providing examples. It enriches the schema descriptions with usage patterns and edge cases.

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

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

The description clearly states it computes the cross-venue spread between Kalshi and Polymarket for the same question, distinguishes two modes (topic shortcuts and explicit tickers), and sets expectations that spreads may not always be tradeable. The verb 'computes spread' and resource 'cross-venue spread' are specific, and it differentiates from sibling tools like polymarket_arbitrage by focusing on the two-venue spread comparison.

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

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

The description explicitly tells when to use `topic` (10 pre-mapped macros) vs explicit tickers for custom pairings. It warns that most pre-mapped topics return compatibility_warning today, so the agent knows not to assume tradeability. However, it does not compare directly to sibling tools like polymarket_arbitrage or polymarket_edges, missing an opportunity to guide selection among related 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, idempotentHint, destructiveHint. The description adds value by describing scoping and pairing behavior, without contradicting annotations.

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

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

Two concise sentences front-load the core action, with no wasted words. 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 low complexity (1 parameter, no output schema), the description fully covers retrieval behavior, scoping, and relationships with siblings. No gaps.

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

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

Schema coverage is 100% with 1 optional parameter. Description explains the optional key behavior (omit to list all) and provides usage examples, adding meaning beyond schema.

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

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

The description clearly states it retrieves values saved via 'remember' or lists all keys when omitted, using specific verbs and distinguishing from sibling tools like 'remember' and 'forget'.

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

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

Provides explicit context for when to use (retrieve stored context) and mentions scoping and pairing with siblings, though no explicit when-not conditions are 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?

The description adds significant behavioral details beyond annotations: the exact fields returned (source, citation_uri, raw event payload), the effect of mark_read, and the assurance that polling works fine. It is consistent with the readOnly, idempotent, non-destructive 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 (4 sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, fields returned, filtering, mark_read behavior, and an alternative access method. 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?

The description adequately specifies return fields and filtering options, which is crucial since no output schema is provided. However, it omits details about result ordering (likely by fired_at descending) and pagination beyond the limit parameter, which could be clarified.

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

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

Despite 100% schema coverage, the description provides richer parameter context: it gives an example type ('sec_8k'), explains mark_read's side effect on subsequent calls, and clarifies that 'since' is an ISO timestamp, all while avoiding repetition of schema descriptions.

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

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

The description clearly states the tool pulls fired events from the subscription feed, with a specific verb ('Pull') and resource ('fired events'). It distinguishes from siblings like list_subscriptions and subscribe by focusing on recent alert retrieval and mentioning filtering and mark_read 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?

The description explains when to use the tool (programmatic access) and provides an alternative HTTP endpoint for scripts/dashboards, but does not explicitly exclude use cases or compare with sibling tools like search_within.

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 convey read-only, idempotent, non-destructive. Description adds parallelism, fallback between GDELT and GNews, and soft-fail for USPTO. Does not contradict annotations.

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

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

Slightly lengthy but highly informative. Front-loaded with query examples, no redundant sentences. Could be tightened slightly but 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?

Despite no output schema, description specifies return structure (changes[] grouped, total_changes count, citation URIs). Covers all complexity: multiple sources, fallback, date formats. Complete for a complex tool.

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

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

Schema coverage is 100%, but description enriches by explaining since accepts ISO or relative shorthand with examples, and value accepts ticker or CIK. Adds practical usage guidance beyond schema.

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

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

Description clearly states the tool provides a change feed for a company across multiple sources (SEC, GDELT, USPTO) in a single call. It uses concrete verbs (fans out, returns) and distinguishes from sibling entity_profile for static 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?

Explicitly lists example queries like "What's new with X" and advises when to use entity_profile instead. Provides clear context for when this tool is appropriate.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the description focuses on scoping (by identifier), persistence differences, and the key-value pair structure. No contradiction with annotations; description adds non-obvious behavioral context.

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

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

The description is four sentences, each carrying distinct value: core function, usage signals, storage model, and paired tools. No redundancy; effectively front-loaded.

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

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

For a simple key-value memory tool with no output schema and only two required parameters, the description covers all necessary aspects: purpose, when to use, storage duration, and companion tools. 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%, providing descriptions for both key and value. The description suggests a naming convention for keys (examples) but does not add new constraints or format requirements 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 starts with a specific verb ('Save') and resource ('data'), provides concrete examples of what to store (resolved ticker, target address, user preference), and explicitly contrasts with sibling tools (recall, forget). This fully differentiates it from tools like remember, 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?

The description explicitly states when to use the tool ('when you discover something worth carrying forward') and pairs it with recall and forget for retrieval and deletion. It also clarifies the persistence model (authenticated users get persistent memory, anonymous 24-hour retention).

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

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

Annotations already declare read-only, open-world, and idempotent behavior. The description adds substantial context: graceful degradation when downstream sources are unavailable, source labeling for each identifier, explicit reporting of unresolved identifiers, and internal cascade through multiple endpoints. This goes well beyond the annotations.

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

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

The description is lengthy but well-structured with clear sections (examples, supported types, degradation behavior). Every sentence adds value, though some verbosity could be trimmed without loss. It remains readable and front-loaded with the core purpose.

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

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

Given only 2 parameters and no output schema, the description thoroughly covers expected behavior: what identifiers are returned, how unresolved ones are handled, and what happens when enrichment sources fail. It also sets expectations about replacing manual lookups, making the tool's context 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 includes per-parameter descriptions, but the description adds deeper meaning: for company it details the cross-source identity spine (CIK, ticker, LEI, FIGI) and for drug it specifies RxCUI/ingredient/brand. This enriches parameter understanding beyond the schema's generic examples.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, with a specific verb ('resolve') and resource ('identifiers'). It includes multiple example queries and explicitly distinguishes itself from siblings by noting these identifiers are what 'other tools require as input.'

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

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

The description gives explicit guidance: 'Use FIRST whenever you have a name but need an ID.' It also enumerates supported types and example inputs without naming alternatives, but the 'use first' directive strongly implies when to choose this tool over others.

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 the tool is read-only, idempotent, and non-destructive. The description adds that it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, and signal density. This provides useful behavioral context beyond annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. No extraneous 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?

The description explains the return format (ranked list with score, confidence, signal density per entity) despite no output schema. It also explains the internal call to ai_visibility_check. For a comparison tool with 4 parameters all documented, this is sufficiently complete.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds minimal context: that the first entity in 'entities' is treated as the subject for narrative. Otherwise, it does not significantly extend meaning beyond the schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, ranks them, and surfaces most/least recognized. It specifies the use case for competitive AI-marketing audits and distinguishes from the sibling tool ai_visibility_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?

The description provides a concrete use case and implies when to use this tool over alternatives (e.g., comparing multiple entities vs. single check with ai_visibility_check). It does not explicitly list when not to use, but the context is clear.

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

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

Annotations already mark read-only, open-world, idempotent, non-destructive. Description adds valuable behavioral context: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed will list timeouts. This goes beyond annotations, though could be more detailed on failure modes.

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

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

The description is detailed but well-structured: composite nature first, usage, behavior, ecosystem limits, failure handling. Every sentence adds value, though length could be slightly trimmed for brevity.

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

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

With no output schema, the description explains return fields (summary block, per-advisory, links, alternatives). It covers ecosystem scope, partial failure behavior, and expected outputs. For a 2-param tool with no nested objects, this is complete.

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

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

Schema coverage is 100%, and both parameters have descriptions. The description adds an example version format ('18.3.1') and confirms default behavior. This provides marginal additional meaning beyond the schema; baseline of 3 is appropriate.

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

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

The description clearly states it is a composite check for npm packages covering license, advisories, version history, and bundle metrics. It uses specific verbs ('scan', 'check') and resource ('npm package'), and distinguishes from potential alternatives by specifying NPM-only 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?

Explicitly tells when to use: when agent asks about safety, popularity, size, or cost of npm package. Also notes NPM-only in v1 and alternatives for other ecosystems (PyPI, Maven, etc.), providing clear guidance on exclusion.

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, so the description adds value by noting it's keyless (no auth) and returns specific fields (accession, name, description, organism). No contradictions.

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

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

The description is two sentences with no wasted words. The first sentence immediately states purpose and query methods, the second adds complementary info (keyless, complements other tools). Highly efficient.

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

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

For a simple tool with 2 parameters, no output schema, and no nested objects, the description is complete. It explains what the tool searches, how to query (examples), what it returns, and its relationship to other databases. 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 descriptions for both 'query' and 'limit'. The description enhances meaning by giving example queries ('apoptosis', 'SCF', 'ribosome') and noting the return fields, adding practical context beyond the schema.

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

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

The description clearly states it searches the EBI Complex Portal for macromolecular protein complexes by name, gene, GO term, or biological process. It specifies the database as curated and lists return fields (accession, name, description, organism), distinguishing it from sibling tools like 'get_complex'.

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 indicates it's keyless and complements other databases (UniProt/IntAct/STRING), giving context on when to use it. It doesn't explicitly state when not to use it, but the purpose is clear and no misleading guidance is present.

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, etc.), it reveals technical details: truncation at 200K chars, BGE-base-en embeddings, 500-char overlapping windows, cosine similarity, and offset-based passage verification.

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

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

Well-structured with main purpose, usage, then technical details. Every sentence adds 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 describes return values (passages with offsets and similarity scores). Mentions pairing with sibling tool. Complete for the tool's purpose.

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

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

With 100% schema coverage, baseline is 3. The description adds value by providing context for 'text' (max chars), 'query' (examples), and 'limit' (default/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?

The description clearly states it performs semantic search inside a fetched record, with specific examples (SEC 10-K, article) and distinguishes itself from sibling tools like ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and mentions pairing with ask_pipeworx_grounded, but does not explicitly state when not to use it.

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

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

Annotations are readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds significant context: requires OAuth, always-on feed, optional delivery channels with constraints (SMS cap, webhook HMAC signing, auto-disable after 10 failures). 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?

Description is somewhat long but well-structured with bullet points and examples. Front-loaded with core purpose. Could be slightly more concise, but every sentence is informative.

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

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

No output schema provided, but description mentions return value ('new subscription id'). Covers all parameter types, delivery channels, constraints, and prerequisites. Sibling tools include unsubscribe and list_subscriptions, providing full lifecycle context.

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

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

Schema coverage is 100%, but description adds invaluable type-specific parameter examples and constraints for each subscription type (e.g., sec_8k item codes, polymarket_edge topics, SMS format). This greatly aids the agent in constructing correct invocations.

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 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This is a specific verb and resource, and it effectively distinguishes from sibling tools like 'unsubscribe' and 'list_subscriptions'.

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

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

Explicit requirement for Pipeworx OAuth account and that anonymous/BYO cannot persist. Explains supported types with examples. Does not explicitly contrast with alternatives like 'recent_alerts', but context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral details such as returning category-bucketed examples with tool calls, the effect of the topic argument, and that it can be called with no arguments. 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 and well-structured, front-loaded with example queries. It uses parenthetical lists and clear sentences, earning its space without redundancy.

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

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

Given the tool's simplicity (one optional parameter), rich annotations, and no output schema, the description fully explains what the tool does, how to use it, and its role among siblings. It is complete for an onboarding 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?

The input schema covers the single optional parameter topic with a description. The description reinforces this by providing concrete examples ('finance', 'pharma', 'betting') and explaining that omitting it gives a cross-category spread. This adds value beyond the schema, though the schema already adequately describes the parameter.

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

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

The description clearly states the tool's purpose as an onboarding entry point for suggesting questions Pipeworx can answer. It specifies that it returns category-bucketed example questions with exact tool+argument shapes, and distinguishes it from sibling tools like ask_pipeworx and entity_profile by recommending it as a 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?

The description 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'. It also explains when to use the optional topic argument, providing clear guidance on context and alternatives.

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

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

Discloses deactivation (not deletion) and ownership check, adding context beyond annotations (idempotentHint, destructiveHint). Could mention idempotency.

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 wasted words, front-loaded with the 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?

Single-param tool with annotations; description covers ownership, behavior, and relation to recent_alerts. Fully adequate.

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

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

Schema already describes 'id' as returned by subscribe. Description adds ownership context but no extra parameter detail; baseline 3 applies.

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

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

Clear verb 'Cancel' and resource 'subscription'. Distinct from siblings like 'subscribe' and 'list_subscriptions'.

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

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

States ownership enforcement and effect (deactivation, not deletion). Implicitly warns non-owners, but lacks explicit when-not-to-use.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description provides critical behavioral context: 'could_not_verify means the check did not happen... it is NOT evidence for or against the claim, and must not be shown as one.' It also clarifies 'unsupported' semantics and the internal fallback pipeline. This is exactly the type of nuance an agent needs to interpret results correctly.

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

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

The description is long but front-loaded with trigger phrases and a clear use-case. It covers multiple aspects (inputs, outputs, error semantics, replacing sequential calls) without unnecessary fluff. The opening example list could be trimmed, but it serves as intent-matching aid for the model.

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

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

With no output schema, the description fully explains return values: verdict enum, actual value with citation, and reasoning. It also covers both domain-specific paths and error cases. The note about replacing 4–6 sequential calls adds operational context. Given the tool's complexity, the description is complete for safe and correct invocation.

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

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

The schema covers 100% of parameters with clear descriptions, so the baseline is 3. The tool description adds some value by explaining how tolerance_pct overrides claim-wording tolerance and its role in grading (e.g., hallucination detection), but this largely reinforces schema information. No major gaps exist, but no significant added meaning beyond the schema either.

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

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

The description explicitly states the tool's function: 'natural-language claim verification against authoritative sources.' It provides example user phrasings, details the two processing paths (SEC EDGAR for financial claims and grounded pipeline for others), and distinguishes itself from siblings by focusing on verification with verdicts. This is a specific verb+resource with clear 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?

The description clearly states when to use it: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the domain split (financial vs. other claims). However, it does not explicitly name alternatives or state when NOT to use this tool, so it falls short of the highest bar.

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