Regulatory Catalysts

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: probing is non-destructive, returns per-model scores and combined view, and explains the cost model (free default, BYO Anthropic key passed through). It does not contradict annotations.

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

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

Three sentences with no wasted words. Front-loaded with main action, then default behavior, optional key info, return format, and use cases. 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 4 parameters, 100% schema coverage, and no output schema, the description adequately explains the return format (per-model score, confidence, signals, raw_response plus combined view). It covers when to use optional parameters. Not all edge cases (e.g., rate limits) are covered, but it is sufficient for a probe tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds extra meaning by explaining 'entity' as the thing to ask about, 'models' as which models to probe with examples, '_apiKey' as optional and passed straight through, and 'context' for disambiguation. It also clarifies default behavior and cost implications.

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 visibility scoring (0-100) per model, with a specific verb 'probe' and resource 'LLMs for business/brand/product/topic'. It differentiates from siblings by focusing on AI visibility scoring, not general Q&A or entity profiling.

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

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

The description provides clear usage context: AI-marketing audits, pre-launch brand checks, competitive monitoring. It also explains when to use the optional _apiKey (for Anthropic) and that the default model is free. However, it does not explicitly state when not to use this tool compared to sibling tools like entity_profile or compare_entities.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations: it explains the routing mechanism, that it 'fills arguments' automatically, and that it returns a structured answer with citation URIs. It also notes performance characteristics ('one fast call') and that it works on every tier. 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?

Although the description is relatively long, it is densely packed with useful information and well-structured: it starts with an imperative preference, lists domains, then describes the mechanism, usage triggers, examples, and escalation paths. Every sentence adds value, and the front-loading of 'PREFER OVER WEB SEARCH' makes the primary guidance immediately clear.

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 broad router tool with no output schema, the description is remarkably complete. It covers what it does, when to use it, alternatives, examples, and return format ('structured answer with stable pipeworx:// citation URIs'). It even includes operational details like 'works on every tier, one fast call' and addresses the breaking-news edge case. This gives an agent everything needed to select and invoke the tool correctly.

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

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

Schema coverage is 100%, with one semantically meaningful required parameter (question) plus five aliases. The description adds meaning beyond the schema by providing examples of valid questions ('current US unemployment rate', 'Apple's latest 10-K') and explaining that the tool 'fills arguments' itself, implying the user only needs to provide the question. This goes beyond the bare 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 what the tool does: 'Routes the question to the right one of 5,529 tools across 1455 verified sources, fills arguments, returns the structured answer with stable pipeworx:// citation URIs.' It also lists many specific domains (SEC filings, FDA data, FRED/BLS, etc.), giving a concrete sense of scope. The description explicitly distinguishes it from siblings by naming ask_pipeworx_grounded and deep_research as alternatives.

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?

Extensive usage guidance is provided: 'PREFER OVER WEB SEARCH' for factual questions, 'Use whenever the user asks...' with concrete trigger phrases, and 'START HERE for most questions.' It explicitly states when to step up to alternatives: 'for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research.' It also clarifies that breaking-news is handled by 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?

The description adds substantial behavioral context beyond annotations: it explains the beta status, that routing improvements are enabled live, that no candidate is currently active (with a specific retirement date), and that it fully works as a router. It clearly states it does not fall back to another route, which is valuable for understanding its operation.

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, including specific numbers like '5,529 tools' and a retirement date that are unlikely to change agent behavior. While informative, it could be trimmed to a more concise statement without losing key guidance.

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

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

The description covers the tool's purpose, current state, relationship to stable ask_pipeworx, and usage context. Since it references the same response shape as ask_pipeworx and there is no output schema, it does not need to detail return values. It is complete enough for an agent to select and invoke it correctly.

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

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

The input schema has 100% coverage with descriptions for all parameters, including aliases for 'question'. The description mentions 'same arguments' but does not add deeper meaning beyond what the schema provides. This meets the baseline for high schema coverage.

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

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

The description clearly states this is a beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape, but with candidate routing improvements. It distinguishes itself from the stable ask_pipeworx by emphasizing its experimental edge, making the purpose unmistakable.

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

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

It explicitly says to use it 'exactly like ask_pipeworx when you want the newest routing' and mentions results are compared against the stable router. While it identifies the alternative (ask_pipeworx), it does not explicitly state when not to use this beta version, but the context strongly implies it is for experimental routing.

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 reveals the exact return shape, refusal reasons, and the extra LLM call cost. It also explains that it refuses to answer when data doesn't directly answer, which is key 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 compact but covers multiple aspects: definition, behavior, return format, and usage guidance. It is slightly dense but every sentence adds value, so a 4 is warranted.

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 specifies the success and refusal return structures. It also covers use cases and cost trade-offs, making it contextually complete for an agent.

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

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

All six parameters are aliases for the question, and the schema already documents each as an alias with 100% coverage. The description adds no additional parameter semantics, so a baseline score of 3 is appropriate.

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

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

The description explicitly states it is a 'hallucination-resistant answer mode for high-stakes reads' and contrasts with 'ask_pipeworx' by noting it extracts answers only from tool results. This clearly identifies the tool's function and differentiates it from sibling tools.

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

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

It provides explicit usage guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and 'prefer ask_pipeworx for casual lookups.' This gives clear when-to-use and when-not-to-use guidance, including a cost trade-off.

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 details: response shapes, resolver contract (confidence, alternatives, suggestions), parent event extractor, news fallback handling, safety for low-confidence/closed markets, and resolution-rule risk parsing. No contradictions.

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

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

The description is comprehensive but verbose at ~700 words. It uses section headers and bullet points for structure, which helps. However, it includes extensive examples and commentary that could be trimmed without losing essential guidance. A more concise version would improve scannability.

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 (multiple data sources, classification, fan-out, error handling) and lack of output schema, the description covers most aspects: response fields, safety checks, edge cases like low-confidence matches, closed markets, wide spreads, and resolution rules. It misses explicit documentation of the full evidence packet structure but remains highly informative.

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

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

Schema coverage is 100%, but the description adds meaning: explains market parameter flexibility (slug, URL, text), depth enum values 'quick' vs 'thorough' (default thorough), and include_raw behavior (summarized vs full payloads). This exceeds schema documentation.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, specifying input types (slug, URL, question text) and output (evidence packet + comparison). It distinguishes from sibling tools like polymarket_edges by focusing on a single bet's data, not edge detection.

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

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

The description explicitly states when to use: 'should I bet on X', 'what does the data say', 'is there edge in Z'. It provides examples and classifiers but does not explicitly state when not to use or name alternatives, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: for company type it pulls latest 10-K data from SEC EDGAR/XBRL with correct fiscal year handling, for drug type it pulls FAERS and FDA data, and results are sorted by primary metric. This goes beyond annotations but is not exhaustive.

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

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

The description is relatively long but each sentence adds meaningful information. It front-loads common query examples. While it could be slightly more concise, it avoids verbosity and is well-structured for quick scanning.

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

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

Given the tool has only 2 parameters, no output schema, but rich annotations, the description provides sufficient context: it covers both entity types' data sources, sorting behavior, and gives usage examples. For a comparison tool, this is complete enough for an agent to understand when and how to use it.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for both parameters: it explains the enum type with 'company' vs 'drug' giving data sources, and for 'values' it clarifies that for company it expects tickers/CIKs and for drug names, along with min/max constraints. This enhances understanding beyond the schema.

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

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

The description begins with explicit user intents like 'Compare X and Y' and clearly states it performs side-by-side comparison of 2-5 companies or drugs in one call. It distinguishes itself from sequential lookups, making the purpose unmistakable.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear guidance on when to use this tool. It also implies not to use for single entity lookups, and distinguishes between company and drug types with specific data sources.

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

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

Adds substantial behavioral context beyond annotations: latency expectations (15-90s), depth mode iteration semantics, gaps[] handling, contradictions[] scan, semantic excerpting, and guaranteed fetchable citations. Annotations already indicate readOnly/idempotent/non-destructive, and the description is consistent, so no contradiction.

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

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

The description is long but exceptionally dense with operational detail. Every sentence adds value, though some repetition exists (e.g., decomposition and citation fetchability). The critical auth gate is front-loaded appropriately.

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

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

For a complex tool with no output schema, the description fully covers authentication, data sources, output packet contents, gaps/contradictions behavior, latency, and alternatives. It answers likely questions an agent would have before 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 covers both parameters with descriptions, but the tool description enriches the 'depth' parameter by explaining the exact fan-out and iterative behavior for quick/standard/thorough, which goes beyond the schema enum values.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources'. It clearly distinguishes itself from sibling tools by explicitly noting 'this is NOT open-web search' and contrasting with ask_pipeworx for single lookups.

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

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

Provides explicit when-to-use guidance: best for broad/multi-part structured data questions, while recommending ask_pipeworx for single lookups and breaking news. Also communicates the account requirement and fallback behavior when not signed in.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that results include schemas and are ready to call directly, which is useful but not critical beyond what annotations imply.

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

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

Concise and well-structured: first sentence states purpose, then lists domains, then explains return format, then usage instruction. No wasted words.

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

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

Covers all aspects: purpose, usage, return format, examples. No output schema, but description explains what is returned. Complete for a simple search tool.

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

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

Schema coverage is 100%, so baseline is 3. Description mentions aliases but adds no meaning beyond the schema's own descriptions.

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

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

Clearly states 'Find tools by describing the data or task', which is a specific verb+resource. It distinguishes from sibling tools by being a meta-discovery tool for browsing what exists.

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 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides clear context and when 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?

Description adds substantial behavioral details beyond annotations, such as fanning out across multiple sources, soft-failure of patents post-May 2025, and returning specific URIs. Annotations already indicate readOnly and idempotent, and description reinforces without contradiction.

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

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

The description is information-dense but well-organized, front-loading with example queries and a clear statement of purpose. While slightly verbose, every sentence earns its place with actionable detail. Could be slightly trimmed but is effective.

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

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

Given the tool's complexity (multiple data sources, fallbacks, URIs, temporal constraint on patents), the description is remarkably complete. It explains what each source returns, sorting, and soft-failure behavior. No output schema, but the description adequately covers return structure.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that value accepts ticker or zero-padded CIK (not names), gives examples, and clarifies the type enum (only 'company'). This adds useful 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 the tool's function: 'full cross-source profile of a US public company in ONE parallel call.' It provides numerous example queries and lists the data sources and returned fields, making the purpose very specific and easily distinguishable 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?

Explicitly recommends preferring this over chaining multiple lookups for holistic views. Clearly states unsupported inputs (names) and suggests using resolve_entity first if only a name is available. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by explaining the data source (Federal Register), extraction of dates, return format, and sorting. It does not contradict annotations. No mention of rate limits or authentication, but annotations cover the safety profile.

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

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

The description is verbose and includes marketing language ('leading biotech regulatory catalyst'). While it is structured and front-loaded with purpose, it contains redundant phrases that could be trimmed. It earns a 3 for being functional but not maximally concise.

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

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

No output schema exists, so the description correctly explains the return fields (committee, date, topic, etc.) and sorting. It also covers data source, coverage, and default behavior. For a calendar-fetching tool, this is fairly complete and leaves few open questions.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description repeats some details (e.g., committee filter is substring, upcoming_only defaults true) but adds no new information beyond the schema. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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

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

The description clearly states the tool lists upcoming FDA advisory committee meetings from the Federal Register, specifying the verb 'lists' and resource 'FDA AdCom calendar'. It covers multiple committees and returns meeting details. However, it does not explicitly differentiate from the sibling tool 'pdufa_catalysts', which may have similar functionality.

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

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

The description provides usage contexts at the end (e.g., 'Use for AdCom, advisory committee, panel vote...') and explains the scope (all committees). It does not mention when not to use the tool or offer alternatives, but the guidance is clear enough for typical use cases.

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

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

Annotations already declare destructiveHint=true, indicating destruction. Description confirms deletion and adds context about clearing sensitive data. It does not disclose idempotent behavior (already in annotations) or other side effects, but given annotations, the description adds moderate value.

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

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

Two sentences: first states action, second provides usage guidance and pairing. No wasted words, front-loaded with 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?

For a simple tool with one parameter and no output schema, the description covers purpose, usage, and pairing. It could mention idempotent behavior or behavior when key doesn't exist, but not essential.

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

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

Schema coverage is 100% for the single parameter 'key', with schema description 'Memory key to delete'. Description does not add additional meaning beyond what the schema already provides.

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

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

Description clearly states 'Delete a previously stored memory by key' which identifies the verb and resource. It explicitly pairs with 'remember and recall', distinguishing it from sibling tools like 'remember' and 'recall'.

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

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

Description explicitly lists when to use: when context is stale, task is done, or to clear sensitive data. It mentions pairing with remember and recall, 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 indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the process: fetching the page, extracting title/description/links, and outputting markdown. 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 concise: three sentences covering purpose, process, and use cases. Front-loaded with the key action and target users. No fluff.

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

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

Complete for a simple generation tool. Without an output schema, the description explicitly states the output is a single text blob in llms.txt format. Annotations cover safety. All necessary behavioral context is present.

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

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

Schema coverage is 100% with descriptions for both parameters. The description does not add new semantic details beyond the schema, but it reinforces the output context. 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?

Clearly states the tool generates a specific file (llms.txt) for a defined purpose (AI crawler indexing). The verb 'generate' and resource 'llms.txt' are explicit, and the use cases distinguish it from sibling tools like 'scan_competitor_ai_presence'.

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

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

Provides three concrete use cases (client indexing, personal drafting, competitor auditing). While it does not explicitly state when not to use or name alternatives, the context is sufficient for an agent to decide applicability.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds value by listing returned fields (id, type, params, timestamps, fire_count), which is useful but not critical.

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

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

Two sentences, no fluff. Front-loaded with action and return info. 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?

Fully adequate for a simple list tool. Describes purpose, return fields, and usage context. No output schema needed; fields are listed in description.

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 description does not need to add more. It correctly omits parameter details, as they are already documented in the schema.

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

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

Clearly states action 'list' and resource 'subscriptions', specifies returned fields, and distinguishes from sibling tools 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?

Provides explicit use cases: 'review what you're monitoring before adding more' and 'find an id to cancel'. Does not explicitly state 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 already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about keyless access, the default date window, and explains that a period without a date indicates vagueness, not an error.

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

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

The description is well-structured, starting with the core purpose, then method, definition, return fields, edge cases, and use cases. Every sentence adds value without redundancy.

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

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

Despite no output schema, the description lists all return fields and explains edge cases. It covers purpose, parameters, and use cases adequately, though the default window for 'since' is already in 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?

Input schema covers all 4 parameters with 100% description coverage, including defaults. The description does not add new semantics beyond what the schema already provides, achieving the baseline.

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

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

The description clearly states the tool searches SEC EDGAR 8-K filings for PDUFA dates, defines what a PDUFA date is, and lists the returned fields. It distinguishes from siblings like fda_adcom_calendar by focusing on binary biotech catalysts.

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 (e.g., 'Use for PDUFA date, FDA decision date, upcoming FDA decisions') but does not mention when not to use it or compare to alternatives.

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

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

Annotations only provide hints (readOnlyHint=false, destructiveHint=false), but the description adds substantial behavioral context: rate limiting ('5 per identifier per day'), quota exemption ('doesn't count against your tool-call quota'), anonymous usage with a claim_token for later retrieval, and the human review process ('team reads digests daily'). 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 longer than average but every sentence serves a purpose: definition, use cases, exclusions, claim_token mechanics, rate limits, and quota. It is well-structured with clear logical flow. It could be tightened slightly (e.g., the 'Not sure?' sentence is somewhat redundant with the exclusion sentence) but remains highly readable and front-loaded.

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

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

Despite lacking an output schema, the description fully covers the return behavior (claim_token, how to poll for resolution) and all important contextual details (rate limits, quota, what constitutes appropriate feedback). It addresses the nested `context` object and enum values implicitly through examples. This is complete for a feedback 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?

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds extra semantics beyond the schema, particularly for claim_token (demonstrating the call pattern `pipeworx_feedback({claim_token:"pwfb_…"})` and the constraint 'with no other arguments') and for context (describing pack/tool/vertical as 'Optional structured context'). This goes beyond what the schema provides, justifying a 4.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this from sibling tools (all information/research tools) by framing it as a feedback channel for the Pipeworx toolset itself.

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 criteria ('Use when a tool returns wrong/stale data (bug)... feature/data_gap... praise') and equally explicit when-not-to-use guidance ('ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead'). It also gives a disambiguation strategy ('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 convey readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: self-aggregating signal from CF analytics engine, no PII, and caching behavior (5min-1h). This goes beyond the annotations and fully informs the agent.

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) with clear structure: a definition sentence followed by three bulleted use cases and a note on derivation and caching. Every sentence adds value without redundancy.

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

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

Given the single optional parameter, no output schema, and rich annotations, the description is complete. It explains the returned data (top tools, packs, call volume), the caching behavior, and the source. No gaps remain for effective tool invocation.

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

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

The schema covers 100% of parameters, and the description adds contextual meaning for the 'window' parameter: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This enhances the enum values and helps the agent choose appropriately.

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

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

The description clearly states the tool's purpose: returning trending tools, packs, and call volume over a recent window. It uses specific verbs ('Returns') and resources, and distinguishes from sibling tools like 'discover_tools' by focusing on trending 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 provides three explicit use cases (discovering hot data sources, confirming canonical choice, checking alignment). While it doesn't explicitly state when not to use, the context is clear and useful for selecting the tool among many siblings.

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

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

Annotations already declare readOnly, idempotent, etc. The description adds valuable behavioral context such as the fill check (realizable_edge_pp <= 0 means no trade), semantic anchor (Jaccard similarity), partition filter (placeholder slugs), and detailed output structure. No contradictions.

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

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

The description is dense and well-structured, starting with a clear purpose and then explaining modes and edge cases. However, it is somewhat long and could be trimmed by summarizing internal details (e.g., exact Jaccard threshold). Still, it is appropriately detailed for the complexity.

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

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

Despite having no output schema, the description fully explains the return format, including fields like gap_pp, suggested_trade, reasoning, and fill check details. It also covers edge cases like placeholders and low similarity, making it complete for an agent to understand what to expect.

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

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

Schema coverage is 100% with descriptions for both parameters. The description goes beyond by explaining the semantics of no args, providing example slugs, clarifying URL acceptance, and detailing the different behaviors of event vs topic modes.

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: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes itself from sibling tools by focusing on arbitrage and multiple modes, providing specific usage examples.

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

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

The description provides explicit guidance on when to use each mode (no args for trending scan, event for specific markets, topic for cross-event scans) and mentions an alternative for custom sizing (polymarket_fill_risk). However, it does not explicitly contrast with sibling tools like polymarket_edges, leaving some ambiguity.

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

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

Description adds extensive behavioral context beyond annotations: explains cache behavior (KV-level, keyed on knobs), models (crypto_price, news_momentum, partition_overround, concentrated_longshot), limitations (Fed bets excluded), diagnostics, and tradeable-edge knobs. Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and description aligns fully.

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

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

Description is long but well-structured with clear sections and front-loaded purpose. Every sentence adds value, though some technical details could be condensed. Not excessively verbose given the complexity.

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

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

Given the complexity (9 parameters, no output schema), the description is extremely complete. It explains output structure by_segment, diagnostics, caching, limitations, and parameter use cases. Provides sufficient context for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The tool description does not add parameter-specific semantics beyond the schema's own parameter descriptions, which are already quite detailed. The description groups parameters under 'TRADEABLE-EDGE KNOBS' but doesn't enhance per-parameter meaning.

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

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

Description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('scan', 'return') and 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?

Description explicitly states it is built for 'what should I bet on today' and that agents discover opportunities without paging through hundreds of markets. It provides context for usage but does not explicitly mention when not to use it or name alternative tools.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds detailed behavioral context: the response structure (tracked, expired, snapshot_dates), how decay is computed (on |edge_pp_net|, daily closes, not intraday), and limits (60-day TTL, snapshot availability). 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 well-structured, front-loaded with purpose, then response structure, then limitations. It uses bold for key terms and clear bullet points. Slightly verbose in details but each sentence adds value. Could be slightly more concise, but effective.

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

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

Given the tool has 2 optional parameters and no output schema, the description provides a complete picture: defines the response fields (tracked, expired, snapshot_dates) with subfields, explains the meaning of each, and covers limitations like TTL and snapshot gaps. This is sufficient for an agent to use the tool correctly without external 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 descriptions cover 100% of parameters, providing default values and ranges. The description supplements with additional context: 'snapshot family' for window, and explains that days default is 14 with max 30 (though schema says clamp 2-30). This adds meaning beyond the schema, improving clarity.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' from daily snapshots, differentiating it from sibling tools like polymarket_edges which show current edges. It answers the key question 'how long has this edge existed and is it shrinking?' with a specific verb (tracking) and resource (edge persistence).

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 (to understand edge age and decay) vs. relying on a single snapshot. It contrasts a fresh wide edge with an old one, but does not explicitly list alternative tools or state when not to use this tool. Sibling names provide context but the description could be more explicit.

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

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

The description adds significant behavioral context beyond annotations: it explains that the tool walks the order book ladder, returns verdicts (clean|degraded|cannot_fill), and for baskets warns about forced directional risk and thin_legs. It is consistent with readOnlyHint and idempotentHint annotations.

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

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

The description is front-loaded with the core purpose and well-structured with sections for requirements, single-market, and basket. It is slightly verbose but every sentence adds value, especially given the tool's complexity.

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

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

Despite no output schema, the description thoroughly explains return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, thin_legs, forced_directional_risk for baskets). It covers edge cases and rationale.

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 extra meaning: default values (side default, size_usd default), interpretations of size_usd (max spend for buys, target proceeds for sells; settlement notional for baskets), and the auto-detection logic for side in basket mode.

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 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by specifying when to use it before acting on arb signals or trades above ~$500.

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

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

The description provides explicit guidance on when to use the tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also explains why theoretical overround is not capturable on thin books and how partial fills convert arb to directional position.

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

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

Adds rich behavioral context beyond annotations: safety fields, temporal alignment, skipped counters. No contradiction with readOnlyHint, openWorldHint, or idempotentHint.

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?

Dense but focused. Every sentence adds value, front-loaded with core purpose. Could be slightly more concise, but no fluff.

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

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

Thorough for a complex tool with no output schema. Details response structure, safety fields, and edge cases.

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

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

Schema coverage 100%, but description adds meaning: explains topic values, explicit override behavior, and interplay between parameters.

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

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

The description clearly states the tool calculates cross-venue spread between Kalshi and Polymarket, with two modes. It distinguishes from sibling tools like polymarket_arbitrage which focus on single-venue arbitrage.

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

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

Explicitly explains when to use topic mode vs explicit mode, and warns that pre-mapped topics often return compatibility warnings. Does not contrast with sibling tools, but context is clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is clearly safe. The description adds context about scoping and pairing, which is valuable. No contradictions or hidden behaviors are present.

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

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

The description is concise (two sentences), front-loaded with the primary action, and contains no extraneous information. Every sentence serves a clear 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 the lack of an output schema, the description could mention the return format (e.g., a value string or list of key names). However, it adequately covers the core functionality, scoping, and relationship to siblings, making it fairly complete for a simple retrieval tool.

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

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

The single optional parameter 'key' is fully described in the schema (100% coverage). The description reinforces that omitting it lists all keys, but adds no new semantic meaning beyond what the schema already provides.

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

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

The description clearly identifies the verb (retrieve/list) and resource (saved values/keys). It distinguishes itself from sibling tools 'remember' and 'forget' by explicitly naming them and describing the pairing, leaving no ambiguity about its function.

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

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

The description provides clear guidance on when to use the tool: 'to look up context the agent stored earlier.' It also mentions scoping by identifier, which adds important context. However, it does not explicitly state when not to use it or list alternatives beyond the paired 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?

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description reveals that events carry source, citation_uri, and raw payload, and that mark_read:true acknowledges events so next call returns newer ones. This adds meaningful context about the acknowledgment mechanism and polling suitability. 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 four sentences, each serving a clear purpose: stating the action, describing return contents, mentioning filters, and explaining acknowledgment and polling. No redundant information; it is front-loaded with the primary 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 the tool has no output schema, the description adequately covers what each alert contains (source, citation_uri, raw payload). It also provides an alternative endpoint for scripts, which adds context. The coverage of parameter usage is sufficient for effective invocation.

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

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

All five parameters are described in the schema (100% coverage), and the description adds value by explaining the 'type' filter with an example ('sec_8k') and clarifying that 'since' expects an ISO timestamp. It also explains the behavior of 'mark_read' beyond the schema description, enhancing understanding.

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

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

The description clearly states the tool pulls fired events from a subscription feed and returns recent alerts with source, citation_uri, and raw payload. It mentions filtering options, distinguishing its function from other tools, though it does not explicitly differentiate from sibling tools. The verb 'pull' and resource 'fired events' provide specific purpose.

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

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

The description explains when to use the tool (to retrieve recent alerts from a subscription feed) and mentions filtering by type and since. It also notes that polls work fine, implying repeated calls are acceptable. However, it does not explicitly state when not to use the tool or compare to alternatives like subscribe or list_subscriptions.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds significant behavioral context: it fans out to multiple sources with fallback logic (GDELT preferred, GNews fallback), patents soft-fail, and returns structured changes with citation URIs. 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 slightly long but front-loaded with query examples. Every sentence adds value; no fluff. Could be marginally tighter 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?

Given the tool's complexity (multi-source, fallbacks, soft-fail, return format) and no output schema, the description covers all necessary aspects: sources, behavior, input formats, output structure, and differentiation. It is fully adequate for an agent to use correctly.

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

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

Schema description coverage is 100%. The description adds useful context beyond the schema: 'type' is limited to 'company', 'since' accepts relative shorthand with recommended '30d' or '1m', and 'value' accepts tickers or CIK. It enriches parsability.

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: 'change feed for a company in the last N days/weeks/months in ONE parallel call.' It uses specific verbs and resources (SEC filings, GDELT/GNews news, USPTO patents) and distinguishes from sibling 'entity_profile' by noting when to use that instead.

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

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

The description provides example queries and clear context for when to use the tool. It explicitly tells when to use the sibling 'entity_profile' instead, but does not list exhaustive when-not scenarios.

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

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

Beyond annotations, discloses key behavioral traits: scoping by identifier, persistence differences between authenticated (permanent) and anonymous (24h) users. 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?

Front-loaded with main purpose, followed by usage context and storage details. Every sentence adds value; no superfluous content. Efficient and 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?

No output schema, but description sufficiently covers storage semantics and pairing with recall/forget. Lacks mention of success/failure response, but acceptable for a simple store operation.

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 3. Description adds meaningful examples for key and value beyond schema, e.g., 'subject_property', 'user_preference', and 'findings, addresses, preferences, notes'.

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

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

Explicitly states the tool saves data for later reuse across conversations/sessions, with clear verb 'Save' and resource 'data'. Distinguishes from siblings like 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?

Provides explicit guidance on when to use ('when you discover something worth carrying forward') with concrete examples (resolved ticker, target address). Names alternatives recall and forget for complementary actions.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description discloses meaningful behavioral traits: internal cascading of multiple lookup endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit reporting of unresolved identifiers under `unresolved`, source-labelling of every identifier, and inclusion of RxNorm citations. These details give the agent a clear model of how the tool behaves, especially for error/partial-failure cases.

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

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

The description is longer than typical but well-structured: opening with user-query examples, then the core purpose, then detailed supported types. Every section adds useful context, though a more compact phrasing could achieve the same effect. It earns a 4 rather than 5 because of its length, but it remains focused and front-loaded.

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

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

With no output schema, the description adequately explains return values for both supported types: company returns CIK, ticker, company_name, LEI with ownership hierarchy, FIGI, and a list of unresolved identifiers; drug returns RxCUI, ingredient, brand, and a citation link. It also covers fallback behavior and the context that this tool feeds other tools requiring IDs, making it complete for an agent.

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

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

The input schema already provides 100% coverage with descriptions and examples for both parameters. The tool description largely repeats this information (e.g., 'accepts ticker, CIK, or company name') without adding new parameter-level semantics. The rich return-value details belong to contextual completeness, not parameter semantics, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: resolving user-spoken names to canonical identifiers such as CIK, ticker, LEI, FIGI, and RxCUI. It distinguishes from sibling tools by emphasizing this is the first-stop for ID resolution and explicitly listing supported entity types (company/drug). The initial user-query examples make the function immediately recognizable.

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

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

Explicit guidance is given: 'Use FIRST whenever you have a name but need an ID.' The description also clarifies which input formats work (ticker, CIK, name for company; brand/generic for drug) and mentions that it replaces 2-3 manual lookups. While it doesn't name alternative tools for other tasks, the 'Use FIRST' directive and the focus on ID resolution effectively signal when to invoke 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 read-only, idempotent, non-destructive behavior. The description adds that it internally probes each entity with ai_visibility_check and returns a ranked list with score, confidence, and signal density. 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 at three sentences, front-loaded with the main action, and contains no superfluous information. Every sentence adds value.

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

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

Covers input parameters and output format adequately. Lacks specifics on score range or normalization, but overall sufficient for an agent to understand and invoke the tool correctly.

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

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

The description explains that the first entry in the 'entities' array is treated as the 'subject' for narrative, while others are competitors. It also clarifies the 'models' parameter options (workers-ai default, anthropic requires key) 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, using ai_visibility_check internally. It distinguishes itself from the sibling 'ai_visibility_check' by focusing on multi-entity comparison and ranking.

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 a clear use case (competitive AI-marketing audits) and example question. However, it does not explicitly state when not to use this tool (e.g., for a single entity, use ai_visibility_check instead).

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

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

Annotations already indicate readOnly, idempotent, and openWorld. The description adds important behavioral context: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed lists timeouts. This goes beyond annotations and provides accurate behavioral expectations.

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

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

The description is a single paragraph but is well-structured: purpose first, then usage, then behavioral details. It is concise for the amount of information conveyed, but could be slightly tightened. Still, it earns a 4 for clarity without excessive verbosity.

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

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

Despite lacking an output schema, the description fully explains the return value: a summary block with specific fields, per-advisory details, links, and alternative versions. It also covers failure modes and timing. The description is complete 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%, so the schema already documents both parameters. The description does not add additional meaning beyond what the schema provides (e.g., defaults, scoped packages). Baseline score of 3 is appropriate as the description is not needed 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 'Composite should I add this npm package to my project check in ONE call' and enumerates the data sources and attributes checked. It clearly distinguishes itself from siblings by specifying NPM ecosystem only and directing to deps.dev:version for other ecosystems.

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

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

Usage guidance is explicit: 'Use whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'.' It also provides when-not-to-use by stating 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly.' This clearly differentiates from alternatives.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds rich behavioral details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation and flagging, and output with offsets. No contradictions.

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

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

The description is a single paragraph that efficiently packs purpose, usage, and technical details. It is front-loaded with the core purpose. Slightly dense but no wasted sentences.

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

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

Given no output schema, the description explains output (passages, offsets, similarity scores), covers behavioral traits (embedding model, chunking, char cap, truncation), and mentions complementary tools. Fully sufficient for agent invocation.

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

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

Schema description coverage is 100% (all three parameters described). The description adds some value beyond schema (query examples, text limit context), but the schema already adequately documents parameters. 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 uses a specific verb ('search') and resource ('source'), clearly stating it performs semantic search inside a fetched record. It distinguishes from siblings like 'ask_pipeworx_grounded' by mentioning pairing and 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 advises use when 'the record is too big to cram into the prompt' and mentions pairing with 'ask_pipeworx_grounded'. It provides query examples but lacks explicit when-not-to-use or alternative tool exclusions.

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

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

Discloses authentication needs, type-specific parameters, delivery channel details (e.g., SMS cap, webhook auto-disable), and that the feed is always on. Annotations already indicate idempotentHint and no destruction; description adds significant value beyond that.

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 well-organized: purpose first, then requirements, then types with examples, then delivery channels. No redundant sentences; every sentence adds value.

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

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

For a 3-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and all parameter details. 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%, so baseline is 3. Description adds examples for each type and clarifies external requirements (e.g., OAuth account, phone verification). This extra context justifies a 4.

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

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

Description clearly states it creates a subscription and returns an ID. The verb 'Create' and resource 'subscription' are explicit, and it is distinct from siblings like list_subscriptions, unsubscribe, or recent_alerts.

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

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

States requirement for Pipeworx OAuth account, supported types with examples, and delivery channels. Does not explicitly say when not to use, but context from siblings provides alternatives. Still clear and helpful.

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

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

Annotations already cover read-only, open-world, idempotent, non-destructive. Description adds detail: returns categorized examples from live catalog, no arguments for full spread. 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 relatively long but each sentence adds context. Front-loads with common user queries. Could be slightly more concise, but 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?

With no output schema, the description fully explains return structure: category-bucketed example questions with tool+argument shapes. Also describes optional topic focus and source from live catalog. Complete for a single-param 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?

Only one optional parameter 'topic' with schema covering 100%. Description restates and gives more examples (e.g., 'finance', 'pharma'), adding minor value beyond schema.

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

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

The description clearly states the tool is an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It distinguishes from siblings by focusing on 'what can I ask?' rather than direct querying or searching.

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

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

Explicitly says to use this first when unsure what Pipeworx can do, and to learn meta-tools. Includes topic parameter guidance. Lacks explicit when-not vs alternatives like ask_pipeworx, but still 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?

Adds beyond annotations: ownership enforcement and soft deletion (deactivated not deleted) with hint about historical data via recent_alerts. Annotations already indicate idempotency and non-destructiveness, so description complements them well.

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

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

Two sentences front-loaded with verb and resource. Every sentence provides distinct value: cancellation action, ownership rule, and soft-delete behavior. No waste.

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 simple input (1 param), annotations, and no output schema, the description fully explains the effect (deactivation, not deletion) and connects to related tool (recent_alerts). Complete for its 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 covers the single 'id' parameter (100% coverage) and describes it as a UUID from subscribe. Description merely refers to 'by id' without adding new semantics, so baseline 3 is appropriate.

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

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

Description specifies verb ('Cancel'), resource ('subscription'), and method ('by id'). It clearly distinguishes from siblings like 'subscribe' (creating) and 'list_subscriptions' (listing) by adding ownership enforcement and deactivation detail.

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 as a usage constraint ('you can only cancel your own subscriptions'), providing clear context. Does not explicitly mention when not to use or list alternatives, but the purpose and scope are adequate.

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

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

The description discloses significant behavioral traits beyond annotations: the dual-path pipeline (SEC EDGAR vs. grounded), full verdict list, the nuance that could_not_verify means the check did not happen (with verification_error details), and that unsupported means no source was found. This adds crucial context for interpreting results that annotations alone do not provide.

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

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

The description is appropriately structured: it opens with natural-language query patterns, states the core purpose, explains the two pipeline paths, returns, and critical caveats. Every sentence carries value—the list of phrasings aids intent recognition, and the length is justified by the tool's complexity and lack of output schema.

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?

Because there is no output schema, the description fully covers return values: it lists all six verdicts, mentions the actual value with pipeworx:// citation, and describes reasoning. It also explains ambiguous verdicts (could_not_verify, unsupported), addresses error handling, and notes that the tool replaces multiple sequential calls, making it self-contained for agent invocation.

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

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

Schema coverage for both parameters is 100% (claim and tolerance_pct have detailed descriptions). The tool description does not add meaningfully to the parameter semantics; it merely reinforces examples already present in the schema. The mention of 'percent-delta math' is tangential and does not clarify parameter usage beyond schema.

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

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

The description clearly states the tool's purpose: 'natural-language claim verification against authoritative sources.' It uses a specific verb (verify/validate/check) and distinguishes itself from siblings by focusing on factual claim verification with a verdict system, explicitly replacing multiple sequential calls.

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 when to use it: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates the financial-claim fast path from the general grounded pipeline, and explains critical verdict interpretations (could_not_verify vs. unsupported), providing clear usage context without ambiguity.

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