Opencages

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint true, destructiveHint false. The description adds behavioral context: default model is free, Anthropic requires BYO API key (you pay Anthropic), returns per-model and combined results. 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?

Two sentences, front-loaded with the core action, no redundant words. Each sentence adds essential information (purpose, default, optional key, return format, 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?

Despite no output schema, the description specifies return structure (per-model {score, confidence, signals, raw_response} + combined view). All 4 parameters are described in schema and partly in description; the description is complete enough 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%. The description adds meaning beyond schema: explains default model usage, the need for _apiKey when using 'anthropic', and the purpose of context for disambiguation. Provides practical cost/usage context.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100) per model. It names the default model and optional Anthropic integration, distinguishing it from sibling tools like ask_pipeworx which focus on specific 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?

The description explicitly lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not provide explicit when-not-to-use guidance but the context is clear enough for appropriate selection.

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

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

Annotations already cover read-only/idempotent/non-destructive safety. The description adds valuable behavior: it routes to one of 5,798 tools across 1,517 sources, fills arguments automatically, returns a structured answer with stable pipeworx:// citation URIs, and is a fast default entry point. It does not describe rate limits or exact output detail, but the annotation coverage plus router-focused description is enough.

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 core behavior and usage guidance are front-loaded, but the description is a dense block with redundant emphasis such as 'PREFER OVER WEB SEARCH', 'even if web search could also answer it', and 'START HERE'. It packs useful trigger phrases and examples, yet it would benefit from trimming repeated command-like statements. Adequate but not a model of concision.

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 router's breadth and absence of an output schema, the description covers the key invocation context: input form, domains, trigger phrases, output shape (structured answer with pipeworx:// citations), and routing to alternatives like grounded/deep_research/news feeds. It does not specify the exact response JSON structure, but the 100% input-schema coverage and examples make calling it unambiguous.

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

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

Schema coverage is 100%: question is documented as natural language, and the five aliases (q, text, input, query, prompt) are each explicitly labeled as aliases with schema examples. The description adds no parameter-specific semantics beyond confirming the input is a natural-language question, so the baseline of 3 applies. It does implicitly clarify that the user supplies only a question and the tool fills the remaining arguments.

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 role: route factual/current/historical questions to the right source tool and return a cited structured answer. It lists concrete domains (SEC, FDA, FRED/BLS, USPTO, ATTOM, weather, clinical trials, news, stocks, crypto, sports, academic papers) and names sibling alternatives like ask_pipeworx_grounded and deep_research, distinguishing this entry point from 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?

This is the strongest part: it explicitly says to prefer this over web search, lists trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), and says 'START HERE for most questions'. It also gives when-not and alternatives: use ask_pipeworx_grounded for a hallucination-resistant exact-wording single answer and deep_research for broad/multi-part questions, while noting this tool already covers breaking-news feeds.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive traits. The description adds valuable behavioral context beyond that: this is an experimental live router, candidate behavior may change while under test, currently no candidate is active, and it is a full working router with no fallback.

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

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

The description is informative and mostly front-loaded, starting with the beta relationship and then explaining current behavior. It contains some extra detail like the specific tool count and retirement date that is useful but slightly verbose.

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

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

Given the tool is a complex universal router with no output schema, the description provides enough orientation: same arguments and response shape as ask_pipeworx, current exact-match behavior, no fallback, and natural-language question input. It relies on the agent knowing ask_pipeworx for full output details, but that sibling context is available.

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

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

Schema description coverage is 100%, and each alias parameter is already documented in the input schema. The description reinforces that the tool behaves like ask_pipeworx and accepts natural-language questions, but it does not add substantive parameter 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 specifically identifies the tool as the beta variant of ask_pipeworx, a universal router with the same 5,798 tools, arguments, and response shape. It clearly distinguishes this from the stable ask_pipeworx sibling by explaining that candidate routing improvements may be active.

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

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

It explicitly says to 'Use it exactly like ask_pipeworx when you want the newest routing' and notes that results are compared against the stable router to decide merges. It also clarifies that no candidate is currently active, so behavior matches ask_pipeworx exactly right now.

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 richly discloses behavior beyond annotations: it details the success return shape with evidence as a verbatim quote, enumerates all five refusal_reason values, and explains the extra LLM call cost. This does not contradict the readOnly/openWorld/idempotent annotations; rather, it complements them with operational 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 dense but every sentence earns its place: purpose, routing, return contract, refusal contract, high-stakes use cases, and cost-based alternative selection. It is front-loaded with the most important behavioral differentiator and uses the remaining sentences for decision-relevant detail.

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?

Even without an output schema, the description fully specifies the return value and refusal reasons, names the sibling alternative and the tradeoff, and states the intended usage context. An agent has everything it needs to decide whether to invoke this tool and to interpret the result.

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

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

The input schema has 100% description coverage, fully documenting the question parameter and its aliases. The description itself adds no additional parameter-level detail, so the schema carries the semantic burden and the baseline of 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 identifies a specific verb-resource pair: a grounded, hallucination-resistant answer mode that extracts answers only from tool results. It explicitly distinguishes itself from ask_pipeworx by describing the same routing but stricter evidence-based extraction, making sibling differentiation immediate.

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

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

It provides explicit when-to-use guidance: use for quoted, cited, or acted-on answers and high-stakes domains like financial verdicts, legal claims, medical lookups, and public statements. It also gives a clear exclusion: prefer ask_pipeworx for casual lookups, citing the extra LLM call cost.

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

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

The description extensively discloses behavioral traits beyond annotations: low-confidence resolutions short-circuit, closed markets return status, wide spreads flagged, cancellation rules parsed. It also warns about inspecting market_match_confidence before trusting analysis. 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 lengthy and detailed, but the complexity of the tool justifies the length. It is well-structured with clear sections (classifiers, fan-out examples, response shapes, safety). Could be slightly more concise, but every section adds necessary context.

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

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

The description fully covers all aspects: input formats, parameters, behavior for various cases (low confidence, closed markets, wide spreads), cancellation rules, response structure, and safety mechanisms. No gaps given the tool's complexity and absence of output schema.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema: explains market input flexibility (slug, URL, text), depth levels with defaults and trade-offs, and include_raw effects on response size. Examples further clarify usage.

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 researches a Polymarket bet by pulling Pipeworx data. It specifies input formats (slug, URL, question text) and provides example use cases. Distinguishes itself from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on single-bet 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?

The description includes explicit use cases like 'should I bet on X' and explains the tool's workflow (resolve, classify, fan out, return evidence). However, it does not explicitly state when not to use it or compare to alternatives, though context from sibling names provides some differentiation.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: it details the specific data pulled for each entity type (financial metrics for companies, adverse event and approval counts for drugs), handles off-calendar fiscal years, explains result sorting, and mentions 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?

The description is a single paragraph that packs substantial information. While it is efficient, it could be more structured (e.g., bullet points for data pulled per type) to improve skimmability. However, it is front-loaded with user-facing queries and gets to the point quickly.

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

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

Despite no output schema, the description explains the return format (paired data with citation URIs), the data sources (SEC EDGAR/XBRL, FAERS, FDA, trials), and edge cases (off-calendar fiscal years). For a tool with moderate complexity and good annotations, this is complete and sufficient.

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 already includes enums and constraints. The description adds meaning by explaining that 'values' should be tickers/CIKs for companies and names for drugs, provides examples, and clarifies what data each type returns. This goes beyond the schema's basic descriptions.

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

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

The description starts with natural language triggers ('Compare X and Y', 'X vs Y') and clearly states the action: side-by-side comparison of 2-5 companies or drugs in one parallel call. It distinguishes from sequential single-pack lookups and specifies the resource (SEC EDGAR/XBRL for companies, FAERS/FDA/clinical trials for drugs).

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 prefers this tool over sequential lookups and gives example queries. It explains behavior for 'company' vs 'drug' types and mentions result sorting. However, it does not specify when NOT to use it, such as when a detailed individual entity profile is needed (like entity_profile), missing an opportunity for clearer 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?

Beyond the read-only/idempotent annotations, the description discloses access requirements, paid depth tier, expected latency, gap-filling behavior, contradictions[], hop fields, fetchable citation URIs, and semantic excerpting. It adds substantial operational 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?

The description is long and dense, but every sentence carries operational or selection-significant information. It front-loads the account requirement and alternative tool, and while it could be better structured, there is little redundancy.

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

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

With no output schema, the description carries the burden of explaining return behavior. It covers the findings packet contents, gaps[], contradictions[], citation resolvability, timing, and usage boundaries, making it complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema already covers both parameters and the depth enum with 100% description coverage. The main description adds value by linking depth to paid plans and explaining how quick/standard/thorough differ in iteration and contradiction handling, which goes 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 performs grounded multi-source research across 1,517 structured data sources, decomposes questions into facets, and routes them to 5,798 tools in parallel. It also explicitly distinguishes itself from open-web search, 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 gives explicit when-to-use guidance: best for broad/multi-part questions over structured data. It also provides alternatives, telling users to use ask_pipeworx when not signed in or for a single lookup, which is concrete selection criteria.

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

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

Description adds behavioral context beyond annotations: returns top-N tools with schemas and examples, each ready to call. Annotations already indicate safety and idempotency.

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

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

Single paragraph, front-loaded with purpose, no redundant sentences, efficient use of language.

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 6 parameters (1 required) and no output schema, description adequately covers what the tool does and what it returns. Could mention pagination but not required.

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

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

Schema coverage is 100%. Description adds meaning by explaining the query parameter's role as natural language and listing aliases. Limit parameter is explained.

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 finds tools by describing data or task, lists explicit domains, and distinguishes it from specific tools in sibling list.

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

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

Explicitly says 'Call this FIRST' for browsing the option set, providing clear usage context. Doesn't explicitly state when not to use but implies it's for 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?

Even with readOnly/openWorld/idempotent annotations present, the description adds substantial behavioral disclosure: it lists all fanned-out sources, explains that USPTO patents soft-fail after the May 2025 sunset, clarifies empty sections are real 'no data, not a bug,' and describes the resolved:false private-company path. It also documents fallbacks (GDELT→GNews) and the meaning of sources_used/sources_failed, going well beyond the annotations.

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

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

The description is front-loaded with trigger phrases and the 'ALWAYS PREFER' directive, then moves through return fields and caveats. It is dense and every sentence contributes useful information, but it is one long semicolon-heavy paragraph that would benefit from bullets or headings; appropriate for the complexity, though not optimally structured.

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

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

With no output schema, the description thoroughly covers the return envelope: cik/company_name, recent_filings with URIs, fundamentals, patents, federal contracts, FDA products, hiring, news, LEI, sources_used/sources_failed, and resolved:false behavior. It even explains expected empty results (small-molecule-only companies get no FDA products), making it complete enough for an agent to correctly interpret both successes and non-failures.

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

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

Schema description coverage is 100%: the schema already explains that type accepts 'company' or 'ticker' interchangeably and that value can be a ticker, zero-padded CIK, or company name resolved via SEC EDGAR. The description restates the same examples and adds phrasing like 'names now resolve via SEC EDGAR's company-name match,' but this is effectively a duplicate of the schema rather than genuinely new parameter semantics.

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

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

The description clearly specifies a verb-and-resource scope: produce 'a full cross-source profile of a US public company' in one parallel call, with trigger examples like 'Tell me about X' and 'company profile for Microsoft.' It is not a tautology and is distinguishable from generic lookups, but it does not explicitly differentiate itself from siblings such as deep_research or compare_entities, so clarity stops short of excellent sibling differentiation.

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

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

It provides strong when-to-use guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' plus concrete query examples. It also sets expectations for edge cases (private companies, no FDA products), but it does not explicitly state when to choose a sibling like deep_research or compare_entities instead.

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

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

Annotations already indicate destructiveHint=true, which the description aligns with ('delete'). The description adds context about clearing sensitive data, but does not contradict annotations. No additional behavioral traits are needed.

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-load the purpose and usage guidance with no wasted words. Perfectly concise for the tool's simplicity.

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

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

The description fully covers the tool's action, when to use it, and how it relates to siblings. No missing context given the tool's simplicity and good annotation coverage.

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 adds no extra semantics beyond the schema, meeting the baseline expectation.

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 deletes a memory by key (verb 'Delete', resource 'memory'). It distinguishes from siblings like 'remember' and 'recall' by contrasting the action.

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

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

Explicit usage guidance: 'Use when context is stale, the task is done, or you want to clear sensitive data.' It also pairs with siblings 'remember' and 'recall', providing context for alternative 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 declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that the tool fetches the page and emits a text blob, but this is expected given the annotations. No contradiction and adds some context.

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

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

The description is concise (4 sentences) and front-loaded: purpose first, then process, output, and use cases. Every sentence adds value with no redundancy.

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

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

Given the simple tool with well-documented parameters and annotations, the description covers purpose, process, output format, and use cases. It lacks error handling or prerequisites but is adequate for this level of complexity.

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

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

Schema coverage is 100% and both parameters (url, max_links) are already fully described in the input schema with details like default and max. The description adds no additional meaning beyond what the schema provides.

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

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

The description clearly states it generates a production-ready llms.txt file for any URL, specifying the actions (fetch, extract, emit) and the output format. However, it does not explicitly differentiate from siblings like ai_visibility_check or scan_competitor_ai_presence, which have overlapping use cases.

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

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

The description provides clear use case scenarios (getting client's site indexed, drafting, auditing competitor) but does not mention when not to use it or suggest alternative tools.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds context beyond annotations: mentions external API dependency (OpenCage), authentication requirement (API key), and return types (coordinates and structured address components). 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?

Single sentence efficiently conveys the tool's purpose, prerequisite, and key features. Front-loaded with the main action, no wasted words.

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

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

Given an output schema exists (as per context signals), the description appropriately omits return value details. However, it could mention rate limits or authentication setup alongside the API key requirement. Overall, sufficiently complete for a geocoding tool.

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

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

Schema description coverage is low (29%), with only bounds and countrycode having descriptions. The description broadly mentions supported filters but does not detail each parameter's meaning or format. Many parameters (abbrv, limit, language, no_annotations) lack clarification, and the description does not compensate adequately.

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

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

The description clearly states the action ('Forward-geocode'), the resource ('address or place name to latitude/longitude'), and the data source ('OpenCage'). It differentiates from sibling tools like 'reverse' by specifying forward geocoding.

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 states a prerequisite ('requires API key') and lists supported features (country-code filtering, bounding box, language). It implies when to use this tool but does not explicitly exclude alternatives or provide when-not-to-use guidance.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds value by specifying the returned fields and optional parameter, without contradicting annotations.

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

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

Two concise sentences front-loading purpose and usage guidance, with no wasted words.

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

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

For a simple list tool with no output schema, the description covers purpose, return fields, usage guidance, and the optional parameter adequately.

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

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

Schema description coverage is 100% for the single parameter; the description does not add additional meaning beyond what the schema provides.

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

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

The description explicitly states 'List the caller's active subscriptions' with a specific verb and resource, and distinguishes from siblings like 'subscribe' and 'unsubscribe'.

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

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

The description advises using this tool to 'review what you're monitoring before adding more or to find an id to cancel', providing clear context for its use.

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

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

Discloses critical behavior beyond the sparse annotations (all false): anonymous filing returns a claim_token, how to use that token later to check status, daily rate limit of 5 per identifier, free usage without quota impact, and that feedback is read daily and affects roadmap. This gives the agent a clear mental model of side effects and stateful 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 longer than typical (10 sentences) but each sentence earns its place: purpose, use cases, exclusions, claim_token mechanics, rate limit, and business context. It is front-loaded with the key purpose and well-structured. Slightly verbose for a feedback tool, but not wasteful.

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 and all annotations false, the description carries full burden. It fully covers: what to report, scoping exclusions, how to follow up on a submission, rate limits, cost implications, and when to use which type. Even the nested context object is implicitly covered by 'Describe the issue in terms of Pipeworx tools/packs.' No important behavioral gap remains.

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 value by explaining the claim_token lifecycle (how to pass it back), the meaning of type categories (already in schema but reinforced), and the instruction to reference Pipeworx tools/packs rather than pasting user prompts. This enriches the context/message parameters beyond the raw schema.

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

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

Description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes from sibling tools (e.g., ask_pipeworx, discover_tools) by scoping exclusively to tools served by this Pipeworx connection and framing feedback categories (bug, feature, data_gap, praise).

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

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

Explicitly states when to use the tool ('Use when a tool returns wrong/stale data, when a tool you wish existed isn't in the catalog, or when something worked surprisingly well') and provides a clear when-not: it is ONLY for tools served by this Pipeworx connection, with instructions to file elsewhere for other MCP servers. Includes specific guidance on what to describe (Pipeworx tools/packs, not end-user prompts).

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by explaining the data source (CF analytics-engine), the composition (pack, tool, count), privacy (no PII), and caching behavior (5min-1h). This goes beyond what annotations convey.

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

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

The description is three concise sentences followed by a bullet list of use cases. It is front-loaded with the core purpose and avoids fluff. Every sentence provides meaningful information without redundancy.

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

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

While the description covers purpose, usage, and parameter semantics, it lacks explicit detail about the return format (e.g., JSON structure, field types). Given no output schema, this omission leaves the agent uncertain about what to expect. However, the tool is simple enough that most agents can infer the output.

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

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

With 100% schema coverage and a single parameter well-described via enum and description, the description adds additional context about how window choice affects results (short vs long windows) and provides a default, which aids selection 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 returns top tools, top packs, and total call volume over configurable time windows. It includes three specific use cases that differentiate it from any sibling tool, which all focus on different functionalities.

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

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

The description lists three explicit use cases (discovering hot data sources, confirming canonical choices, aligning use cases) and explains the parameter trade-off (short vs long windows). It does not provide when-not-to-use guidance, but the purpose is sufficiently unique among siblings.

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

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

While annotations declare readOnlyHint=true, the description adds substantial behavioral context beyond this: details of internal checks (monotonicity, partition checks, Jaccard similarity, placeholder filtering, fill check). It explains response structure and limitations (e.g., 'do not trade it' when fill check fails). 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, bullet points, and bold labels. Every sentence adds value, explaining complex logic clearly. However, it could still be slightly more concise without losing essential 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?

Given the tool's complexity (multiple modes, sophisticated checks, and detailed response), the description covers all necessary aspects: modes, parameters, internal logic, response structure, fill check, and references to related tools (polymarket_fill_risk). No output schema is provided but description compensates by detailing response fields.

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

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

Schema description coverage is 100% with clear descriptions. The description adds extra context for each parameter: explains the recommended usage, accepted formats (e.g., 'Full Polymarket URLs also accepted' for event), and the consequences of each choice. With high schema coverage, the extra value earns 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 the tool's purpose: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes from siblings by specifying the unique methods and multiple modes (event, topic, no-args).

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 mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. It includes examples and explains when cross-event mode is beneficial over single-event. Also warns when not to trade (if realizable_edge_pp ≤ 0).

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds extensive detail: caching policy (1h KV), three response segments, edge calculation formulas, diagnostics for empty segments, and 24h move warnings. Goes well 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?

Highly informative but very long (over 500 words). Structure is logical (purpose, segments, edge details, knobs, response) and front-loaded with purpose, but the density and length reduce conciseness. Not minimal; sentences carry value but could be simplified.

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 9 parameters, no output schema, and complex behavior, the description covers all aspects: response structure with three segments, fed bet handling, diagnostics, edge fields, caching, and parameter effects. Complete enough for an agent to use effectively.

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

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

All 9 parameters have schema descriptions (100% coverage). The tool description further explains the 'tradeable-edge knobs' in context, linking them to filtering logic and practical usage (e.g., min_liquidity to avoid thin books). Adds meaningful usage guidance beyond schema.

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

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

Clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. The purpose is specific and differentiated from sibling tools like polymarket_arbitrage by focusing on Pipeworx data and edge discovery.

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

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

Implies usage for daily betting decisions ('what should I bet on today') but does not explicitly state when to use versus siblings like polymarket_edge_tracker or polymarket_arbitrage. No exclusion criteria or alternative suggestions.

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, non-destructive. The description adds rich behavioral details: it uses snapshots, provides time-series, doesn't access intraday data, and limits history by TTL. No contradiction with annotations.

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

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

The description is well-structured with sections for arguments, response breakdown, and limits. Every sentence adds value, no fluff. It's long but necessary for completeness and 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?

Despite no output schema, the description thoroughly explains response structure (tracked, expired, snapshot_dates) and limitations (TTL, snapshot start). It fully compensates for missing schema and provides all needed 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%, so baseline is 3. The description adds meaning by giving defaults, ranges (max 30 for days), and examples ('1wk' for window). It also explains response fields tied to parameters, enhancing understanding.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It explicitly answers specific questions ('how long has this edge existed and is it shrinking?') and distinguishes itself from siblings like polymarket_edges by focusing on historical trends.

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

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

The description includes detailed parameter explanations and limits (e.g., lookback bounds, snapshot TTL). It implies when to use (for historical edge analysis) but doesn't explicitly state when not to use or mention alternatives, though siblings provide 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?

The description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint=false), confirming no mutation. It adds significant behavioral context: 'walks the ladder,' returns a verdict (clean|degraded|cannot_fill), and explains partial fill risks. This goes well beyond what annotations provide, disclosing operational details and hazard scenarios.

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

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

The description is long but well-structured with capitalized sections (SINGLE-MARKET, BASKET) and lists of return fields. Every sentence carries information—no filler. It's slightly verbose given the complexity, but the structure aids readability. A minor point prevents a 5.

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

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

Despite no output schema, the description fully explains return values for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, thin_legs, forced_directional_risk for basket). It also covers edge cases like partial fills and unhedged risk, making the tool self-contained for an AI agent.

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

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

Schema description coverage is 100%, and the tool description adds substantial meaning: it explains the 'side' parameter's default and basket-specific interpretation, clarifies that 'size_usd' is interpreted differently for buys vs sells, and notes clamping range (10–1,000,000). This enriches the schema descriptions significantly.

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 as a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and specifies two distinct modes (single-market and basket). It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by explicitly stating when to use it ('USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500').

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

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

The description provides explicit guidance on when to use the tool (before arbitrage signals or trades above $500) and warns about risks of partial basket fills converting an arb into an unhedged directional position. It indirectly specifies when not to use it (for small trades below $500) and references alternative tools as sources of signals that should be pre-checked.

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 this read-only and idempotent, and the description adds substantial behavioral nuance: compatibility_codes can be non-empty even when pairs are returned, temporal_alignment null means 'unknown' not 'aligned', unknown legs are never paired, fees are not modeled, and skipped-category counters explain dropped comparisons. This is exemplary disclosure.

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

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

The description is long, but it is organized with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS) and every sentence carries a meaningful caveat or specification. It could be trimmed slightly, but the density is largely justified given there is no output schema to offload details to.

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 must carry the full burden of explaining the response contract, and it does: per-venue leg prices, top_spreads_pp, compatibility warnings and codes, temporal alignment objects, fee disclosures, skipped counters, and low-confidence pairs. Nothing needed to correctly interpret a response is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: topic is a pre-mapped shortcut macro, while kalshi_event_ticker and polymarket_event_slug are explicit overrides. It also states both modes run the identical token-overlap matcher, clarifying that parameter choice changes the lookup source, not the comparison logic.

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

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

The description opens with a precise verb-resource pair: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It further distinguishes this from nearby trading/arbitrage tools by stating the delta is only a real signal when bet shapes are equivalent and by labeling spreads as gross, not tradeable.

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

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

The description clearly explains when to use the topic mode versus explicit kalshi_event_ticker/polymarket_event_slug pairing, and proactively warns that most pre-mapped topics return compatibility warnings today. It does not explicitly compare against sibling tools like polymarket_arbitrage or polymarket_edges, so a small gap remains.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint. Description adds scoping detail ('to your identifier') and relationship to remember/forget, which annotations do not cover. 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?

Two sentences, front-loaded with the core action. No wasted words. Every sentence contributes meaningful information.

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

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

For a single-parameter, read-only tool with rich annotations, the description covers purpose, usage, scoping, and pairing. 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%. Description adds meaning by explaining that omitting the key lists all keys, which goes beyond the schema's description. Examples in schema complement this.

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

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

Clearly states verb 'retrieve' and resource 'value saved via remember', with the alternative action of listing all keys when the argument is omitted. Distinguishes from sibling tools remember and forget by naming 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?

Explicitly says when to use ('look up context the agent stored earlier') and how (omit key to list). Pairs with remember and forget. Lacks explicit 'when not to use' or alternatives beyond 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?

The description fully discloses the side effect of mark_read:true (flags events as read so subsequent calls show only newer ones), which goes beyond the annotations (readOnlyHint=true, idempotentHint=true). It explains the returned fields and the feed behavior, adding 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 packed into five concise sentences, with the main action front-loaded. Every sentence adds value—no redundancy or filler. It efficiently covers purpose, parameters, return data, side effects, and alternatives.

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

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

Despite having no output schema, the description covers return format, filtering options, pagination via limit, and the read-flagging mechanism. It is complete enough for an agent to invoke correctly without external documentation.

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

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

With 100% schema coverage, the description adds meaning beyond the schema: clarifies that mark_read affects next call results, that since expects an ISO timestamp, and that type filters subscription types. It also mentions typical response fields (source, citation_uri, payload), which is not in the schema but aids understanding.

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

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

The description opens with a clear verb+resource ('Pull fired events from your subscription feed'), specifies the return type (recent alerts with source, citation_uri, payload), and mentions filtering by type and since. This differentiates it from siblings like list_subscriptions or recall which operate on different 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?

The description explicitly states that polling works fine and provides an alternative endpoint for scripts/dashboards. While it doesn't exhaustively cover all sibling alternatives, it gives practical guidance on when to use this tool versus a direct HTTP 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?

Annotations already declare readOnly, idempotent, openWorld hints. Description adds details about multiple data sources, fallback behavior, USPTO soft-fail reason, and return format including citation URIs.

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

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

Every sentence adds value. Front-loaded with usage examples. No redundant or unclear phrasing. Efficiently covers all necessary aspects.

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 explains return format (grouped changes, total count, citation URIs). Covers behavioral aspects, fallbacks, and failure modes completely 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 covers all 3 parameters. Description adds examples for 'since' (ISO date and relative shorthand) and suggests '30d' or '1m' for monitoring. Clarifies 'value' can be ticker or zero-padded 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 clearly states tool provides a change feed for a company, combining multiple sources. Explicitly distinguishes from sibling 'entity_profile' by stating when to use each.

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

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

Provides explicit guidance with example queries and a clear condition for when to use entity_profile instead of recent_changes. Also suggests typical monitoring window values.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), description adds key behavioral traits: key-value scoping by identifier, persistence differences for authenticated vs anonymous sessions, and 24-hour retention limit. 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?

Four sentences with no wasted words. Front-loaded with main purpose, followed by usage guidance and behavioral details. Every sentence contributes 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?

For a simple 2-param tool with no output schema, the description thoroughly covers usage, persistence, scoping, and relationship to sibling tools. Complete and self-contained.

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

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

Schema coverage is 100% with clear descriptions for both parameters. Description adds value by providing naming conventions and examples ('subject_property', 'target_ticker'), making parameter intent clearer.

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 'Save data the agent will need to reuse later' with a specific verb and resource. Distinguishes itself from siblings 'recall' and 'forget' by mentioning them explicitly in usage guidance.

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

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

Explicitly describes when to use ('when you discover something worth carrying forward') and pairs with sibling tools ('Pair with recall to retrieve later, forget to delete'), providing clear usage context and alternatives.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive hints. The description adds substantial behavioral context beyond those: graceful degradation when GLEIF/OpenFIGI is unavailable, ambiguity resolution via figi_candidates, explicit labeling of identifier sources, the unresolved field, and internal cascading through multiple lookup endpoints. No contradictions with annotations.

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

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

The description is dense with valuable information, and it front-loads user phrasing examples and the core purpose. However, it is long and somewhat stream-of-consciousness, relying on nested parenthetical clauses. The length is largely justified by tool complexity, but restructuring into bullet points would aid 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?

This is a complex tool with no output schema, yet the description compensates thoroughly. It explains return contents (CIK, LEI, FIGI, figi_candidates, unresolved), edge cases (non-equity instruments, non-US issuers via ISIN-to-LEI), and failure behavior (EDGAR still returns if GLEIF/OpenFIGI is down). An agent has everything needed to use it correctly.

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

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

Even though schema description coverage is 100%, the description adds significant meaning over the schema. It clarifies acceptable inputs for value: ticker, CIK, ISIN, or name for companies; brand or generic name for drugs. It also gives critical formatting guidance, such as passing only the issuer name rather than trailing security-class words, with a concrete example.

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 the verb 'resolve' and the exact resource: user-spoken names to canonical/official identifiers. It opens with concrete example queries and explicitly distinguishes itself by producing identifiers 'other tools require as input', which clearly separates it from siblings like entity_profile and reverse.

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', giving a direct trigger condition. It also mentions that it replaces '2-3 manual lookups', implying it is the preferred entry point. However, it does not name specific alternative tools or state when not to use it, so exclusion 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 already indicate readOnly, idempotent, and non-destructive behavior. The description adds that it uses an external API (OpenCage) and requires an API key, which is beyond annotation info. It does not mention rate limits or potential errors, but overall adds useful context.

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

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

The description is a single sentence that is action-front-loaded, providing the core purpose, dependencies, and key output fields. No extraneous 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?

An output schema exists but is not detailed here. The description covers the main inputs and outputs but omits explanation of optional parameters. Given the tool has 5 parameters and 0% schema coverage, the description is incomplete for full parameter 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 coverage is 0%, so the description must compensate. It explains the input lat/lon and lists return fields, but does not describe the optional parameters (abbrv, language, no_annotations). This leaves the agent without understanding the optional parameters' meaning.

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

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

The description clearly states the tool performs reverse geocoding (converting lat/lon to address) using OpenCage. It specifies the tool's action, resource, and distinguishes from sibling 'geocode' which is forward geocoding.

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

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

The description mentions 'requires API key,' indicating a prerequisite. The sibling list includes 'geocode,' implying this is for reverse geocoding. However, it does not explicitly state when to use or when not to use this tool versus alternatives, 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 indicate read-only, non-destructive, idempotent behavior. The description adds valuable context: it probes each entity with 'ai_visibility_check' and returns a ranked list with score, confidence, signal density. No contradictions with annotations.

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

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

Two concise sentences that front-load the purpose and include context and output format without 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 tool with 4 parameters, no output schema, and moderate complexity, the description adequately explains behavior, output format, and use case. Could mention limitations like max entities, but not essential.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds meaning beyond schema by stating the first entity is treated as the 'subject' for narrative, which aids agent understanding of how to use entities.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using specific verbs like 'probes', 'ranks', and 'surfaces'. It distinguishes from sibling 'ai_visibility_check' by focusing on multiple entities together.

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

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

The description provides a clear use case ('competitive AI-marketing audits') with an example question. It does not explicitly mention when not to use or compare to alternatives like 'compare_entities', but the context is well-defined.

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

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

Annotations indicate read-only, idempotent, non-destructive, open-world. Description adds behavioral details: fans out across two services, returns specific summary fields, per-advisory detail, links, alternatives. Warns about bundlephobia latency and sources_failed field for timeouts.

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 informative but slightly lengthy; however, every sentence adds value. Front-loaded with core purpose.

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

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

No output schema, but description fully explains return fields (summary block, per-advisory detail, links, alternatives) and handles partial failures. Covers input, output, behavior, and failure modes for a composite tool.

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

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

Schema has 100% description coverage. Description adds that scoped packages (@types/node) are accepted and that version defaults to latest published when omitted, which adds 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 it's a composite check for npm packages combining deps.dev and bundlephobia, with specific use case 'should I add this npm package to my project'. Distinguishes from siblings by noting NPM only in v1 and alternatives for other ecosystems.

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

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

Explicitly says 'Use whenever an agent asks is X safe/popular/small' and provides guidance on partial failures. Mentions ecosystem limitation and fallback to deps.dev:version for other ecosystems.

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

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

Annotations already indicate readOnlyHint, idempotentHint, etc. The description adds valuable details: the algorithm (BGE-base-en embeddings + cosine overlap), windowing (500-char overlapping windows), character cap (200K chars with truncation/flagging), and verification mechanism (character offsets). 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 (three sentences) and front-loaded with the core purpose, then usage, then technical details. Every sentence adds essential information without redundancy.

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

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

Given the tool has no output schema, the description adequately explains the return values (top-N passages with character offsets and similarity scores) and mentions truncation flag. It covers usage context, behavioral traits, and parameter constraints, leaving little ambiguity for an agent.

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

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

Schema description coverage is 100%, so the schema already documents all parameters adequately. The description adds some context (e.g., the cap of 200K chars for 'text' and examples for 'query') but does not significantly extend 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 performs semantic search inside a provided text, with specific verb 'search inside' and resource 'fetched record'. It distinguishes itself from siblings by focusing on searching within a pre-fetched text rather than external 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 explicitly states when to use this tool ('when the record is too big to cram into the prompt') and mentions a complementary sibling tool (ask_pipeworx_grounded). It does not provide explicit when-not scenarios, but the guidance is clear.

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

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

The description discloses behavioral traits beyond annotations: it requires an OAuth account, explains that anonymous/BYO cannot persist subscriptions, details delivery channel specifics (SMS cap, webhook signing, auto-disable), and states the return value (subscription ID). 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 well-structured, front-loading the core purpose and output. It then proceeds logically to account requirements, supported types with examples, and delivery channels. While it is quite detailed and somewhat verbose, every sentence adds value, and the structure aids readability.

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

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

Given the tool's moderately high complexity (3 parameters, one with enum, nested objects), the description fully covers account prerequisites, type-specific parameters, delivery options, and constraints. It also states the return value despite no output schema, making it complete for most use cases.

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

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

Despite 100% schema coverage, the description adds significant meaning: it explains each subscription type in detail (e.g., parametrized examples for sec_8k, polymarket_edge, fred_series), describes delivery channel semantics (email validation, SMS verification, webhook restrictions and signing), and clarifies constraints not fully captured by the schema (e.g., webhook URL HTTPS-only, localhost rejected).

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the subscription ID. The verb 'Create' and resource 'subscription' are specific, and it distinguishes from siblings like list_subscriptions and unsubscribe.

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

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

The description specifies the account requirement (Pipeworx OAuth) and provides detailed guidance on supported subscription types with examples (e.g., sec_8k for SEC filings, polymarket_edge for mispricings). It also explains delivery channel options and their restrictions, though it does not explicitly state when not to use this tool or list alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, etc. Description adds that the tool draws from a live catalog and returns example questions. No behavioral surprises. Adequate transparency beyond annotations.

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

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

The description is relatively long but well-structured with alternative queries, output explanation, and usage instructions. It earns its length by being informative; minor trimming possible but not necessary.

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 optional parameter and no output schema, the description covers all necessary aspects: purpose, parameters, output, use case, and context. It is complete for an agent to decide when to invoke.

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

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

Schema coverage is 100%. Description adds value by listing example values for 'topic' (e.g., finance, pharma) and explaining behavior when omitted (cross-category spread). This enriches the schema-only information.

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

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

The description clearly states the tool returns category-bucketed example questions with tool calls, and positions it as the onboarding entry point. It distinguishes from sibling tools by specifying its role: 'Use this FIRST when you do not yet know what Pipeworx can do for you.'

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 agent doesn't know what Pipeworx can do. Also gives optional 'topic' parameter to focus. Lacks explicit 'when not to use' but the context sufficiently guides 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: cancellation is a state change rather than deletion, ownership constraint, and historical data remains available via 'recent_alerts'. Complements idempotentHint and destructiveHint.

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

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

Two sentences, no filler, front-loaded with essential information. Every word contributes to understanding.

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

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

For a simple one-parameter tool with no output schema, the description fully covers purpose, behavior, ownership, side effects, and connection to related tools.

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 only parameter 'id' is described as 'Subscription id (uuid) returned by subscribe.', adding context beyond the schema. Schema coverage is 100%, and the description adds useful linkage.

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 'cancel a subscription' with the resource 'subscription', and uses the verb 'cancel' and resource 'subscription by id'. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly states ownership enforcement ('you can only cancel your own subscriptions') and the effect ('row is deactivated, not deleted'), providing clear guidance on when and how to use the tool.

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

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

The description adds substantial context beyond the annotations: it explains the two-tier routing (fast path vs grounded pipeline), return structure (verdict, citation, reasoning), and critically clarifies the semantics of 'could_not_verify' (check did not happen, with error field) versus 'unsupported' (no source coverage). This is exactly the kind of behavioral nuance needed for correct interpretation.

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-organized: it opens with trigger phrases and a definition, then outlines usage, processing paths, return values, and a highlighted IMPORTANT note. Every sentence adds value, and the structure flows logically from purpose to details to caveats. No filler or redundancy.

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

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

The tool is complex (two processing paths, six possible verdicts, error semantics), yet the description covers all essential aspects: when to use, what routes, what it returns, and how to handle the critical could_not_verify vs unsupported distinction. Annotations cover safety, and no output schema exists, so the description carries the full burden—and it does so completely.

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

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

Schema coverage is 100%, so the schema already fully documents both parameters (claim and tolerance_pct) with examples and defaults. The description adds minimal parameter-specific information beyond what the schema provides—it references 'exact percent-delta math' but does not elaborate on tolerance usage. Therefore, the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb+resource: natural-language claim verification. It provides trigger phrases and explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also outlines the two distinct processing paths (SEC EDGAR/XBRL for company financials, grounded pipeline otherwise), which distinguishes it from generic search or QA tools.

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

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

The description gives clear usage context ('Use whenever the agent needs to check whether something a user said is factually correct') and explains how different claim types are routed. However, it does not name specific alternatives or state explicit exclusions (e.g., 'do not use for open-ended research'). This is strong but not fully explicit about when-not-to-use.

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