Gaming Feeds

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

Annotations already mark readOnly, openWorld, idempotent, not destructive. Description adds that probing is read-only, returns per-model results, and mentions pricing implications for Anthropic. No contradictions.

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

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

Two sentences, front-loaded with main action, then details. Every sentence serves a purpose: action, default behavior, key parameter, return format, use cases. No redundancy.

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

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

Despite no output schema, description outlines return structure (per-model score, confidence, signals, raw_response + combined view). Covers all parameters and optionality. Fully sufficient for an AI agent to understand and invoke correctly.

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

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

Schema coverage is 100%, but description adds value: explains default model, that _apiKey is passed through to Anthropic, and context helps disambiguation. This goes beyond schema descriptions.

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

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

The description explicitly states the tool probes LLMs for brand visibility and scores it 0-100 per model. It names specific use cases (AI-marketing audits, pre-launch checks, competitive monitoring) and distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on per-model scoring.

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

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

Provides clear context: default model is free Workers AI, additional model requires own API key. Explicitly lists use cases. No explicit when-not or alternatives, but the 'Useful for' statement gives clear guidance.

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

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

Annotations already declare read-only/open-world/idempotent, and the description adds operational detail: it routes to sub-tools, fills arguments, returns structured answers with pipeworx:// citation URIs, and is 'one fast call'. This goes beyond the annotation profile. It does not mention rate limits or failure behavior, but the core behavioral contract is disclosed.

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

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

The description is long but front-loaded and sectioned: core directive, behavior, trigger phrases, examples, and escalation path. A few items are redundant (the domain list and trigger phrases overlap), but every major decision an agent needs is present.

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, no-output-schema router, the description covers input (natural-language question), output (structured answer with citation URIs), and escalation rules. It also handles the breaking-news edge case. It does not describe what happens when no source matches, but that is a minor gap for a default entry-point 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%; the `question` parameter already documents natural-language input and its aliases. The description reinforces with examples but adds no semantic detail beyond the schema, so a 3 baseline 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 names a specific action ('Routes the question to the right one of 5,724 tools across 1497 verified sources') and a clear resource (authoritative structured data with citations). It differentiates ask_pipeworx from siblings by naming ask_pipeworx_grounded and deep_research as fallback alternatives. The core purpose — factual query routing and answering — is unambiguous.

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

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

Explicitly instructs 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', with trigger phrases like 'what is', 'look up', 'find'. It also states when not to use: 'Step up only when needed... for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research' — supplying named alternatives and conditions.

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/idempotent annotations, the description discloses the experimental status, live candidate routing changes, and the assurance that it 'Falls back to nothing — this IS a full working router.' It also explains that results are compared with the stable router to decide merges, which is useful behavioral context. It does not discuss latency, logging, or response details, but it covers the essential beta-specific traits.

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 front-loads the core identity and uses each sentence for a distinct purpose: definition, current status, usage guidance, and assurance about being a full router. Despite including a specific date and tool count, nothing is wasted or redundant. It is dense but appropriately sized for a beta tool with a live-state caveat.

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 what the tool is, how to invoke it, when to prefer it, and its current behavior matching stable ask_pipeworx. It references the same response shape as ask_pipeworx rather than independently spelling out return-value details, but given the simple one-required-argument interface and no output schema, an agent has enough to call and use it correctly. It could be more self-contained, but it is not materially incomplete.

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 documents question and five aliases at 100% coverage, so the description doesn't need to restate them. The phrase 'same arguments' references ask_pipeworx but adds no parameter-level meaning beyond what the schema provides. This is the baseline case where the schema carries the semantic burden.

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 by identifying the tool as the beta version of ask_pipeworx and an 'identical universal router' with the same tools, arguments, and response shape, which clearly distinguishes it from the stable sibling. It frames the role as the experimental edge of the same routing capability rather than a separate operation. This is specific enough for an agent to know exactly what the tool does and how it relates to ask_pipeworx.

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

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

The description says to 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router. It also notes that no candidate is currently active, so the tool 'currently matches ask_pipeworx exactly,' giving a clear current-usage condition. It does not spell out a formal when-not scenario or contrast with ask_pipeworx_grounded, but the key alternative and trigger are 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 goes well beyond annotations by disclosing the internal routing across 5,724 tools/1497 sources, the extraction-only constraint, the structured success envelope ({answer, evidence, confidence, source, fetched_at, refusal_reason:null}), and explicit refusal reasons. It also explains the extra LLM call cost, which aligns with the openWorldHint and readOnlyHint annotations. 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 dense but purposeful, front-loading the key distinguishing trait (hallucination-resistant) and then providing routing behavior, return shape, refusal reasons, and usage guidance. It is longer than ideal but every sentence carries information an agent needs to choose and invoke the tool correctly.

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

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

For a read-only, idempotent tool with a simple single-required-parameter schema and no output schema, the description fully covers selection criteria, behavioral expectations, return shape, refusal cases, and cost tradeoffs. The only thing absent is a concrete example, but the natural-language question parameter makes that unnecessary.

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% because the schema describes the question parameter and lists five aliases. The description adds natural-language usage guidance and the behavioral impact of the question, so it adds some semantic context beyond the schema. Baseline 3 would apply; the description's mention of 'fills arguments' and the answer/refusal envelope provides a bit more, so 4.

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

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

The description states a specific verb ('answer mode') with a clear resource (Pipeworx) and a distinctive behavioral trait: hallucination resistance via extraction only from tool results. It distinguishes itself from the sibling ask_pipeworx by naming it and contrasting the grounded mode with casual lookups.

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

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

Explicitly says when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements).' It also tells when not to prefer it: 'prefer ask_pipeworx for casual lookups,' and explains the cost tradeoff of one extra LLM call.

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?

As annotations indicate read-only, idempotent, non-destructive behavior, the description adds extensive behavioral context: market resolution, classification, fan-out, response shapes, resolver contract, parent event extraction, news fallback, safety cutoffs, wide spread handling, and resolution rules. No contradiction with annotations.

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

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

Description is long but not wasteful; each section adds necessary context for correct usage. Could benefit from better organization (e.g., sections or bullet points) but front-loads essential purpose and usage, then dives into details.

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

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

Despite no output schema, the description comprehensively explains response structure, statuses, edge cases, and safety considerations. Covers resolution confidence, parent events, news fallback, closed markets, wide spreads, and cancellation rules—all critical for correct interpretation.

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 provides 100% coverage with descriptions, so baseline is 3. Description adds meaningful context: market can be slug, URL, or question; depth explains quick vs thorough; include_raw explains when to use true vs false. This extra detail justifies a slightly higher score.

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?

State explicitly that the tool researches Polymarket bets by pulling Pipeworx data. Lists use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z'). Distinguishes from siblings like polymarket_arbitrage and polymarket_edges by focusing on research and evidence.

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 clear when-to-use guidance with example queries and classifiers. However, does not explicitly state when NOT to use or suggest alternative tools. The detail on safety and low-confidence matches helps agents understand limitations.

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 data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handles off-calendar fiscal years, sorting by primary metric, and return format (paired data + citation URIs). Complements annotations with specific behavioral details.

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

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

Somewhat verbose but well-structured, front-loaded with trigger phrases. Every sentence adds value, though minor redundancy could be trimmed.

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 necessary aspects: purpose, when to use, parameter details, data sources, sorting, and output format. No output schema, but description sufficiently explains 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%, but description adds extra meaning: example values for 'values', explanation of what each 'type' does, and constraints (max 5, min 2). Enhances understanding beyond schema.

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

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

The description clearly states the tool performs side-by-side comparisons of 2-5 companies or drugs, with specific trigger phrases. It distinguishes itself from siblings by stating it replaces sequential single-pack lookups.

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

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

Explicitly says when to use (comparing entities, ranking) and when not to ('ALWAYS PREFER over sequential single-pack lookups'). Provides clear guidance on type and values parameters.

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

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

Annotations already mark the tool read-only, non-destructive, and idempotent; the description adds substantial behavioral context beyond that: account/plan requirements, parallel decomposition across 5,724 tools, explicit gaps[] instead of invented answers, contradictions[], citation_uri fetchability guarantees, semantic excerpting, and expected latency. No contradiction with annotations exists.

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

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

The description is long but information-dense and well front-loaded: signup warning first, then core purpose, usage guidance, exclusions, behavioral guarantees, and latency. A few points are repeated (structured/not open-web, never invented), so it is not maximally concise, but every sentence does meaningful work.

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

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

With no output schema, the description explains return values thoroughly: findings packet with verbatim evidence, confidence, source, fetched_at, pipeworx:// citations, gaps[], contradictions[], hop field, and citation_uri. It also covers auth, costs, when not to use the tool, and expected runtimes, making it complete for an agent to decide and invoke correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters thoroughly. The description adds some tool-level context like paid depth tiers and latency expectations, but most parameter-specific meaning (depth variants, broad questions) is already present in the input schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: grounded multi-source research across Pipeworx's 1,497 structured data sources in one call. It clearly distinguishes itself from open-web search and from ask_pipeworx, so an agent can tell exactly what deep_research does and does not do.

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 and when-not-to-use guidance: best for broad/multi-part structured-data questions, use ask_pipeworx for single lookups, prefer ask_pipeworx for breaking/current-news topics, and use ask_pipeworx if not signed in. It also names the alternative tools and the conditions that select them.

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

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

Annotations already indicate safe, idempotent, non-destructive behavior. The description adds that it returns top-N relevant tools with full schemas and examples, ready to call without a second lookup. No contradictions with annotations.

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

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

The description is a single paragraph that front-loads the purpose and is fairly concise. It could be slightly tighter but contains no filler.

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

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

Given the tool's complexity (6 params, no output schema), the description covers purpose, usage, return format (top-N tools with schemas and examples), and domain examples. It is fully complete for effective use.

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

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

Schema coverage is 100%, so the description adds minimal value beyond the schema. It repeats the alias info and mentions limit defaults, but these are already in the schema. The baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists many example domains and explicitly says to call this first when many tools are available, differentiating it from sibling tools that execute tasks rather than discover them.

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 says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It provides clear context but does not explicitly state when not to use or name alternatives beyond implying the sibling tools are used after discovery.

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 safe, idempotent read behavior. Description adds helpful context: parallel execution, source fan-out, and specific return fields. Patents sunset soft-fail is disclosed.

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

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

Packed with information in a single paragraph, front-loaded with examples. Could be broken into sections for readability, but no unnecessary words.

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

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

Despite no output schema, description fully explains all return fields (cik, filings, fundamentals, patents, news, LEI) and their sources. Covers complexity and edge cases (patents sunset, name vs. identifier).

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 is not strictly needed. It adds useful nuance: 'type' is limited to 'company', 'value' format (ticker or CIK), and that names are unsupported.

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 provides a full cross-source profile of US public companies, with explicit example queries and a detailed list of returned data. Distinguishes from siblings like compare_entities and 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 advises to prefer over chaining multiple lookups, specifies input requirements (ticker or CIK, not names), and directs to resolve_entity if only a name is available. Also notes the patents component's sunset date.

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. The description adds behavioral details: normalization and fallback proxy retry. No contradictions.

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

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

Two sentences, front-loaded with core purpose, no wasted words. Efficient and 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?

With 3 parameters fully described in schema and no output schema, the description covers normalization and fallback behavior. Could mention return format but not essential for a fetch tool with examples.

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 itself documents all parameters. The description does not add new parameter information beyond the examples, meeting 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 fetches and normalizes any RSS/Atom/RDF feed by URL, specifying the verb and resource. It distinguishes from sibling list_feeds by mentioning curated sources.

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 advises to use list_feeds first for curated sources, providing a when-not-to-use hint. It also mentions CF-robust fallback behavior, but does not compare to read_feed, 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?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description states 'Delete' which is consistent. No additional behavioral details (e.g., if deletion fails silently, or cascading effects) are disclosed, but the annotation coverage is sufficient.

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 achieve high density of information: first states the core action, second provides usage guidance. No filler or redundant content.

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

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

For a simple tool with one parameter, clear annotations, and no output schema, the description adequately covers purpose, usage, and parameter meaning. No missing context.

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

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

Schema coverage is 100% with a single parameter 'key' described as 'Memory key to delete'. The description does not add any further details about the parameter, so it meets the baseline expectation but provides no extra value.

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

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

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

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 scenarios for use: stale context, task completion, clearing sensitive data. Mentions pairing with remember and recall. Lacks explicit when-not-to-use or alternative tools for similar operations.

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 details the process: fetches the page, extracts title/description/key links, and emits standard markdown. This adds context beyond the annotations (which already indicate read-only, idempotent, non-destructive), such as the crawling and extraction behavior.

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

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

The description is four sentences, front-loaded with the action, and contains zero unnecessary words. Each sentence contributes to understanding the tool's purpose, output, and use cases.

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

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

For a tool with no output schema, the description clearly states the output format ('single text blob ready to drop at site-root/llms.txt'), which is sufficient. The two parameters are well-documented, and the use cases are covered.

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

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

Both parameters are described in the schema with 100% coverage. The description adds extra value by specifying for 'max_links' the default (25) and maximum (50), which are not in the schema.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, with a specific verb ('Generate') and resource ('llms.txt file'). It distinguishes from siblings by being the only tool focused on AI crawl file generation.

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

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

The description provides explicit use cases: getting a client's site indexed, drafting for own project, or auditing competitor indexing. It lacks explicit when-not-to-use or alternatives, but the context is clear and helpful.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description's mention of listing curated feeds adds context without contradicting annotations.

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

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

Two sentences: the first states the core purpose and output fields, the second explains optional use and ties to sibling. No superfluous words.

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

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

For a simple list tool with 2 optional parameters and no output schema, the description covers output fields and directs to read_feed. Omits pagination or ordering, but annotations already assure safety and idempotence.

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 both parameters. The description repeats the filter options (category and keyword) without adding significant semantic detail 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 lists curated gaming feeds with specific fields (id, title, category, source) and distinguishes from sibling read_feed by directing to use that for a specific feed.

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

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

It explains optional filters by category or keyword and points to read_feed for individual feeds, but does not explicitly state when to avoid this tool or compare with other siblings like search_within.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destructiveness. The description adds value by specifying the return fields and clarifying the default scope (active subscriptions). This context enhances the agent's understanding beyond annotations.

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

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

Two concise sentences: first states purpose and return fields, second provides usage guidance. No redundant information, every sentence serves a clear role.

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

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

Given the simple parameter set and strong annotations, the description is adequate. It covers purpose, return fields, and usage context. Missing details like pagination are acceptable for a straightforward list 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?

Schema coverage is 100%, and the description does not add meaning beyond what the schema provides for the single parameter. It mentions 'active subscriptions' which aligns with the default false for include_inactive, but this is implicit from the schema description.

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

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

The description explicitly uses 'list' as verb with 'subscriptions' as resource, specifying 'caller's active subscriptions' and listing return fields. This clearly distinguishes it from sibling tools like subscribe and unsubscribe, which perform write operations.

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

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

It states exactly when to use the tool: 'to review what you're monitoring before adding more or to find an id to cancel.' This implicitly advises against using it for adding or cancelling subscriptions, which are handled by siblings.

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

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

Without helpful annotations (all false), the description carries full behavioral disclosure. It reveals the claim_token return mechanism, the two-mode usage (filing vs. checking status), rate limiting (5/day), and that it does not count against tool-call quota. This is far beyond what annotations offer.

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

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

The description is long but every sentence earns its place: purpose, use cases, exclusion, tool identification, content rules, claim token behavior, and operational limits. The logical flow makes it efficient despite its length. Could be slightly trimmed, but density is high.

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

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

For a feedback tool with no output schema, the description fully covers the lifecycle: when to file, what to include, how to check follow-up status, and operational constraints. The claim_token mechanics are explained clearly, so no output schema is needed. Nothing essential is missing.

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

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

Since schema coverage is 100%, the baseline is 3. The description elevates this by providing concrete usage guidance for message ('describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt') and for claim_token with the exact call format pipeworx_feedback({claim_token:'pwfb_…'}).

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 immediately states 'Tell the Pipeworx team something is broken, missing, or needs to exist' and then enumerates specific feedback categories (bug, feature, data_gap, praise). It clearly distinguishes itself from all sibling tools by scoping itself to the Pipeworx connection's own tools and explicitly excluding other MCP servers.

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 when' triggers for each feedback type and a strong 'ONLY for tools served by this Pipeworx connection' exclusion, telling the agent to file elsewhere for other servers. It even offers a practical check: '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 declare readOnlyHint, openWorldHint, idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: self-aggregating signal from CF analytics-engine, no PII, caching behavior (5min-1h depending on window). This goes beyond annotation defaults.

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

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

The description is concise (4 sentences) and front-loaded with the core function. Use cases are presented as a clear bullet list. Every sentence adds value with no redundancy or filler.

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

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

For a read-only tool with no output schema, the description explains what is returned (top tools, packs, volume). Caching and data source details are provided. However, the exact structure of the response (e.g., format of 'top') is implicit, leaving some ambiguity.

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

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

Schema coverage is 100% with the window parameter fully described. The description adds insight into window semantics ('shorter windows surface what's hot right now; longer windows show steady-state demand'), providing decision guidance beyond the 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 clearly states it returns 'top tools, top packs, and total call volume' with a specific verb ('Returns') and resource ('what other AI agents are calling on Pipeworx'). It distinguishes from siblings by focusing on trending/aggregate data, not individual queries or research.

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

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

Three explicit use cases are provided (discovering hot sources, confirming canonical tool, checking alignment). While it doesn't state when not to use it or name alternatives, the context is clear and actionable.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds rich behavioral context: how it walks child markets, performs partition checks, uses Jaccard similarity filter, drops placeholder slugs, and includes fill check against order book depth. 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 lengthy but well-structured with sections for each mode and technical details. While not extremely concise, every sentence adds necessary information for correct usage. Could be slightly trimmed without loss.

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

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

Despite no output schema, the description thoroughly explains the response structure (opportunities array with fields) and the fill_check results. It covers edge cases like skipped_low_similarity and placeholder filtering. Complete for a complex tool.

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

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

Input schema descriptions are present for both parameters (coverage 100%). The tool description adds further meaning with examples of valid values (e.g., 'fed-decision-may-2026', 'Strait of Hormuz traffic returns to normal') and explains the behavior of each 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 the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It specifies different modes (no args, event, topic) and distinguishes it from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicit guidance on when to use each parameter: no args for trending scan, event for specific market slug, topic for cross-event scanning. Also advises against trading when realizable edge ≤ 0, and references polymarket_fill_risk for custom sizing.

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

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

Annotations confirm read-only, idempotent, and non-destructive behavior. The description greatly expands on this by detailing model families, edge calculation, caching (1h at KV level), diagnostics, and response structure. It fully explains behavioral traits beyond what annotations provide, with no contradictions.

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

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

The description is thorough and well-structured with bolded headers, but it is lengthy. Each section adds value, though some details (e.g., specific alpha values) could be streamlined. Overall, it is effective 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?

Given the tool's complexity (9 params, multiple model families, diagnostics), the description is remarkably complete. It explains the response structure (by_segment, fed_candidates, _diagnostics), edge computation, and caching. The absence of an output schema is compensated by detailed behavioral disclosure.

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

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

All 9 parameters have schema descriptions, achieving 100% coverage. The description summarizes tradeable-edge knobs (min_liquidity, max_spread_pp, min_partition_leg_kelly) but adds little new meaning beyond the schema. It provides useful contextual grouping, but the schema already carries the semantic load.

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: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It is built for the 'what should I bet on today' use case, directly distinguishing it from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on Pipeworx signal disagreement.

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

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

The description implicitly guides usage by targeting opportunity discovery without paging hundreds of markets, and details the three segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) along with tradeable-edge knobs. It does not explicitly state when to avoid this tool in favor of siblings, but the specificity of its purpose provides clear context.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description details the response structure, trend computation, decay metrics, snapshot gaps, and limits (60-day TTL, decay from daily closes). No contradiction with annotations.

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

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

The description is dense but well-structured, starting with the core purpose and then detailing the response. Some redundancy (e.g., repeating defaults) could be trimmed, but overall 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?

The description compensates for the missing output schema by thoroughly explaining the response fields (tracked, expired, snapshot_dates) and their meaning. It also covers limitations and edge cases (gaps, history bounds).

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 documents both parameters with defaults and constraints. The description repeats this information without adding new semantic meaning (e.g., effect of window choice on data aggregation). Schema coverage is 100%, so baseline 3 applies.

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

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

The description clearly states the tool's purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific question about edge longevity and differentiates itself from sibling tools like polymarket_edges by focusing on time-series analysis.

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

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

No explicit guidance on when to use this tool versus alternatives. While it's implied for edge persistence tracking, there's no comparison to related tools like polymarket_edges or polymarket_arbitrage to help the agent decide.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds significant behavioral details: walks the ladder, returns specific fields like slippage_pp, verdict, forced_directional_risk, and notes the dominant loss mode in real arb-bot P&L. No contradiction with annotations.

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

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

The description is dense with information but well-organized into single-market and basket sections. While not perfectly concise, each sentence adds value and the structure improves readability. A slightly tighter edit could improve, but it's effective.

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

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

Despite no output schema, the description fully explains return fields (top_of_book, vwap_fill_price, capture_ratio, thin_legs, etc.) and covers edge cases like partial fills, directional risk, and notional limits. This is complete for a risk-check tool.

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

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

Schema coverage is 100%, providing baseline 3. The description adds interpretation details for size_usd (spend vs target proceeds, settlement notional) and side defaults in basket mode, but much of this is already covered in the schema descriptions. Still, the additional context warrants a 4.

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

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

The description clearly states it checks realizable vs theoretical edge against live order-book depth, distinguishes between single-market and basket modes with specific output fields, and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly advises using this tool before acting on polymarket_arbitrage signals or trades above ~$500, explains that partial basket fills convert arb into unhedged directional positions, and provides clear context for when to use versus alternatives.

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

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

Despite readOnlyHint, idempotentHint, and destructiveHint already signaling a safe read operation, the description adds substantial behavioral nuance: matching is keyword/word-overlap only, pairing_unverified is always set when pairs are returned, spreads are gross and ignore Kalshi fees, temporal_alignment null does not mean aligned, and unknown metric_type/match_subtype legs are never paired. This is exactly the kind of edge-case context an agent needs.

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 front-loads the core purpose and modes and uses labeled sections such as RESPONSE and SAFETY FIELDS to organize dense warnings. It is long, and some code lists could be tightened, but nearly every sentence carries safety or behavioral context rather than filler.

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 carries the full burden of explaining return semantics and does so comprehensively: per-venue prices, top_spreads_pp, compatibility codes, skipped counters, temporal_alignment, and fees_note. It also sets honest expectations that most pre-mapped topics return warnings today, so an agent has what it needs to 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 schema already documents all three parameters at 100% coverage, including the topic options and examples. The description adds value by explaining how the modes interact, namely that explicit tickers override the topic-mapped side and that both modes run the identical token-overlap matcher, which is meaning beyond the field-level 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 computes the cross-venue spread between Kalshi and Polymarket for the same resolving question, and it identifies two concrete modes. It does not explicitly differentiate itself from sibling tools like polymarket_arbitrage or polymarket_edges, but the venue-pairing scope is specific and actionable.

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

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

The description gives explicit mode-selection guidance: use topic shortcuts for pre-mapped macros or provide an explicit kalshi_event_ticker plus polymarket_event_slug for custom pairings. It also warns that pre-mapped topics are often not tradeable, but it does not compare against sibling arbitrage or edge tools, so cross-tool when-to-use guidance is missing.

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 cover read-only, open-world, idempotent, and non-destructive traits. The description adds value by detailing the return structure (title, link, published, summary), beyond what annotations provide.

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

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

Two sentences with front-loaded purpose and efficient mention of return format and optional filtering. No unnecessary words.

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

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

For a simple read tool with rich annotations, the description covers purpose, return format, and filtering. It doesn't mention limit default or range, which is in schema, so it's adequate but not exhaustive.

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's mention of 'curated gaming feed' and 'normalized items' adds context but does not significantly expand on parameter usage beyond the schema.

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

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

The description clearly states it reads a curated gaming feed by ID from list_feeds, returning normalized items. It distinguishes from siblings by specifying the source of feed IDs and the normalized output format.

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 implies using list_feeds first to get the feed ID, and mentions optional keyword filtering. However, it does not explicitly exclude alternatives like fetch_feed or provide 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: scoping to identifier and the nature of data (previously saved values). 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 concise, front-loaded with the primary action, and each sentence adds value without repetition. It efficiently explains usage, scoping, and pairing with siblings.

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

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

The tool is simple with one optional parameter and no output schema. The description fully covers input behavior, output (value or list), scoping, and relationships with remember/forget. No gaps remain.

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

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

Schema coverage is 100%, but the description clarifies the parameter's behavior: 'omit the key argument to list all saved keys'. This adds meaning beyond the schema's description.

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

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

The description clearly states the tool retrieves a previously saved value or lists all keys, distinguishing it from remember and forget. The verb 'retrieve' and resource 'saved memory values' are specific and differentiate it from siblings.

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

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

The description provides explicit when-to-use guidance: 'look up context the agent stored earlier... without re-deriving it from scratch.' It also mentions scoping and pairing with remember/forget, but lacks explicit when-not-to-use or alternatives.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds valuable behavioral context: returns specific fields (source, citation_uri, payload), mark_read side effect (flags events read), polling suitability, and alternative URL. This exceeds what annotations provide, though 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 compact (4 sentences) with front-loaded purpose. Each sentence adds essential information: verb+resource, return structure, filter+mark_read behavior, polling note. No redundancy or fluff.

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

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

For a read-only polling tool with 5 optional parameters and no output schema, the description covers what the tool returns, parameter usage, and edge cases (mark_read effect, polling fine). It even provides alternative access for scripting. 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 coverage is 100%, so baseline is 3. The description adds semantic value with examples (type: 'sec_8k'), explains mark_read's effect on subsequent calls, and combines filtering guidance. This enhances understanding beyond schema descriptions.

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

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

The description clearly states the tool pulls fired events from subscription feed. It specifies the resource (recent alerts), verb (pull/returns), and distinguishes from siblings like fetch_feed by focusing on alerts. Alternative access via URL is mentioned, but the tool's specific role is well-defined.

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

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

The description provides clear context for usage: filtering by type and since, setting mark_read for read tracking, and polling suitability. It does not explicitly contrast with sibling tools, but the purpose is self-contained, making when-to-use implicit. A brief exclusion mention would improve score.

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

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

Beyond annotations (readOnlyHint, etc.), description details fans-out to multiple data sources, fallback mechanism, and return format (structured changes[] with source grouping, count, and citation URIs). 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?

Well-structured with front-loaded examples, but slightly lengthy. Every sentence adds value, though could be tightened slightly without losing clarity.

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

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

Completes missing output schema by describing return structure. Covers edge cases (USPTO soft-fail, rate-limit fallback). Adequate for a complex multi-source tool with no output schema.

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

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

Schema coverage is 100%, but description adds value: explains 'since' accepts ISO date or relative shorthand (e.g., '7d', '1y'), suggests typical monitoring ('30d' or '1m'), and clarifies 'value' can be ticker or CIK.

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

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

Description starts with natural language examples ('What's new with X') and explicitly states it provides 'change feed for a company in the last N days/weeks/months in ONE parallel call.' It lists sources (SEC EDGAR, GDELT→GNews, USPTO) and distinguishes from sibling 'entity_profile' by noting when to use the latter 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?

Explicitly tells when to use ('What's new with X' queries) and when not to ('Use entity_profile instead when you want the static profile'). Also describes fallback logic (GDELT→GNews) and soft-fail behavior for USPTO.

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 idempotent and non-destructive write. Description adds valuable context: scoped by identifier, persistence differences for authenticated vs anonymous users. 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?

Five sentences, efficiently front-loading purpose and usage. Every sentence adds value with no redundancy or fluff.

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

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

For a simple two-parameter tool with annotations and full schema coverage, the description covers all necessary aspects (purpose, usage, persistence, companion tools) leaving no gaps.

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

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

Schema coverage is 100% and parameter descriptions in schema are clear. Description reinforces key-value nature and adds scoping context, but does not add meaning beyond schema descriptions.

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

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

The description clearly states this tool saves data for reuse later, using strong verbs ('Save') and specifying the resource (key-value pairs). It distinguishes itself from sibling tools like recall and forget by explicit mention.

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

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

Provides explicit when-to-use guidance: 'Use when you discover something worth carrying forward...'. Also mentions alternatives: 'Pair with recall to retrieve later, forget to delete.'

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 detail beyond the annotations: it cascades through multiple lookup endpoints, degrades gracefully when LEI/FIGI enrichment is unavailable, explicitly reports unresolved identifiers, and returns figi_candidates rather than asserting a single match. This is rich, non-obvious behavior clearly disclosed.

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

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

The description is long and dense, but the length is warranted given the tool's complexity and multiple entity types. The front-loaded examples and 'Use FIRST' instruction make the core message immediate, though the text could be organized with clearer section breaks for faster 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's complexity, two parameters, and no output schema, the description is exceptionally complete: it covers supported types, input formats, ambiguity handling, source attribution, unresolved identifiers, non-US issuers, non-equity instruments, and failure behavior. An agent has enough context to select and invoke this tool correctly in a wide range of situations.

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

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

Although schema coverage is 100%, the description adds significant semantic value: accepted input formats include ticker, CIK, ISIN, or company name, and the drug branch accepts brand or generic names. It also explains the important constraint that only the entity name should be passed, with a concrete example of what trailing words would break the lookup.

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

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

The description opens with concrete user phrasings and states the core function: resolving a spoken name to canonical identifiers that other tools require. It distinguishes itself from siblings like entity_profile and compare_entities by focusing on identifier resolution rather than broader entity queries.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID.' It also gives nuanced guidance for edge cases, such as passing only the issuer name for bonds and not the full noun phrase, and describes what happens when ambiguity exists.

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

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

Annotations already indicate read-only, open-world, idempotent. Description adds that it internally calls ai_visibility_check, ranks scores, and returns specific fields, which is valuable 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?

Two well-structured sentences, front-loaded with purpose, no redundant text. Every sentence adds value.

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

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

Despite no output schema, description fully explains returned data (ranked list with score, confidence, signal density). Also mentions internal call, making it complete for agent understanding.

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 all parameters (100%), but description adds context: first entity is treated as 'subject', context disambiguates common names. Provides extra meaning beyond schema.

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

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

Clearly states it compares AI visibility across multiple entities side-by-side, ranks by score, and surfaces most/least recognized. Distinct from siblings like single-entity ai_visibility_check or generic compare_entities.

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

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

Provides explicit use case: competitive AI-marketing audits. Implies when to use vs single-entity check or other comparison tools, though does not explicitly list 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?

Description adds behavioral details beyond annotations: fans out to two external services, potential latency (5-30s), graceful degradation via sources_failed, and return structure. Annotations already indicate read-only and idempotent, which are consistent.

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 lengthy but every sentence adds value for a complex composite tool. Front-loaded with main purpose and usage, then technical details. No redundancy.

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

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

Given no output schema, the description adequately explains all return information: summary block, advisory details, links, alternative versions. Covers ecosystem restriction and partial failure behavior.

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 has 100% coverage with clear parameter descriptions (package name with scoped packages, version defaults to latest). Description does not add extra parameter-level semantics beyond the schema.

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

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

The description clearly states it is a composite check for npm packages, aggregating data from deps.dev and bundlephobia, and distinguishes from other tools by specifying ecosystem scope.

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

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

Explicitly tells when to use: when an agent asks about safety, popularity, size, or cost of adding a package. Also specifies not to use for other ecosystems (PyPI, Maven, etc.) and directs to alternate tool usage.

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

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

Discloses beyond annotations: 200K char cap, truncation flag, embedding details, output includes offsets and scores. No contradiction with annotations.

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

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

Front-loaded with core purpose, then details. No wasted information; every sentence is informative.

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

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

No output schema, but description covers return values (passages, offsets, scores), limits, and truncation behavior, making it complete for a complex tool.

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

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

Schema coverage is 100%, but description adds examples (e.g., SEC 10-K) and explains the query format, providing contextual value beyond the schema.

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

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

Clearly states 'Semantic search INSIDE a fetched record.' Uses specific verb and resource, and distinguishes from siblings like ask_pipeworx_grounded.

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

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

Explicitly tells when to use: 'when the record is too big to cram into the prompt' and suggests pairing with ask_pipeworx_grounded.

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 context beyond annotations: details delivery constraints (verified phone, 10/day cap, webhook auto-disable), types, and prerequisites. No contradiction with annotations; idempotency hint is not contradicted, though not explicitly reinforced.

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-structured and front-loaded with purpose, but is somewhat lengthy. However, every sentence adds necessary information, so it earns its length.

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

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

Covers all essential aspects: types, parameters, delivery options, prerequisites, and limitations. Without output schema, description provides sufficient context about return value (subscription ID).

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

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

Schema coverage is 100%, but description adds significant value with detailed examples for each subscription type and delivery channel, including specifics like item codes for sec_8k and topic for polymarket_edge.

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 creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. Distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

Specifies prerequisite (Pipeworx OAuth account) and explains types and delivery channels. Provides context for when to use this tool to create subscriptions, but lacks explicit when-not or alternative tools for similar 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?

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds behavioral context: it returns example questions with tool shapes, can be called with or without a topic, and serves as an entry point. No contradictions with annotations.

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

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

The description is somewhat lengthy but well-structured with a list of topics and clear front-loading of core purpose. It could be slightly trimmed without losing meaning, but it remains effective and earns a 4.

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 role as an onboarding helper with a single optional parameter and no output schema, the description covers purpose, usage, behavior, and parameter semantics thoroughly. It is complete 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% (one parameter 'topic' fully described). The description adds semantics: it explains the purpose of the parameter (focus area), lists example values, and clarifies that omitting it gives a cross-category spread. This adds significant value beyond the schema.

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

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

The description clearly states the tool's purpose: it is the onboarding entry point that returns category-bucketed example questions. It uses specific language ('onboarding entry point', 'returns category-bucketed example questions') and distinguishes itself from siblings like 'discover_tools' by focusing on what can be asked and providing tool+argument shapes.

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

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

The description explicitly states when to use the tool: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. It also provides guidance on optional filtering via the 'topic' parameter and notes the alternative of calling with no arguments for full spread.

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 (idempotentHint=true, destructiveHint=false), the description adds that ownership is enforced, the row is deactivated not deleted, and historical events remain accessible via recent_alerts. No contradictions.

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

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

Two sentences, front-loaded with action verb, no unnecessary words. Every sentence adds essential information.

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

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

Complete for a simple 1-parameter tool with no output schema. Covers purpose, ownership, side effects (soft deactivation), and relationship to sibling tool 'recent_alerts'.

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 does not add new info about the 'id' parameter 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 uses a specific verb ('Cancel') and resource ('subscription by id'), clearly distinguishing it from sibling tools like 'subscribe' and 'list_subscriptions'. It adds ownership enforcement and soft-deactivation nuance.

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 when to use (cancel a subscription) and includes a constraint (ownership enforced). Does not explicitly exclude alternatives or mention when not to use, but context with siblings makes intent 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?

Beyond the annotations (read-only, open-world, idempotent), the description reveals critical behavior: the distinction between structured and grounded paths, the verdict enum with specific meanings, and importantly the semantics of could_not_verify (check did not happen, not evidence) versus unsupported (no source coverage). This is rich behavioral context 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 long but densely packed with high-value information: trigger phrases, routing logic, output semantics, and error handling. Every sentence contributes, though its length is notable. It could be slightly tightened without losing substance, but overall it is well-structured 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?

Given the tool's complexity, the absence of an output schema, and the need to correctly interpret verdicts, the description is exceptionally complete. It covers input, processing paths, return values, edge-case semantics, and the value proposition, leaving little ambiguity 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?

Schema coverage is 100%, but the description adds meaning: it gives concrete examples for 'claim' and explains how tolerance_pct overrides the implied tolerance, with specific guidance for hallucination detection (set 1–2%). This adds actionable detail well beyond the schema descriptions.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with explicit trigger phrases ('fact check', 'verify the claim that'). It distinguishes itself from siblings by stating it replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison), making its unique role unambiguous.

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

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

It states exactly when to use: 'whenever the agent needs to check whether something a user said is factually correct.' It also differentiates the two execution paths (company-financial claims via SEC EDGAR + XBRL vs. any other factual claim via grounded pipeline), and explains it supersedes a multi-step approach, giving clear context versus alternative tools like resolve_entity or compare_entities.

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