Data Fulton

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds that the default model is Workers AI (free) and that using Anthropic requires a BYO API key, plus returns per-model and combined views. 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?

Two sentences that front-load the primary purpose and scoring, then succinctly cover default model and optional API key. Every sentence earns its place with no filler.

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

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

Despite no output schema, the description explains the return format (per-model {score, confidence, signals, raw_response} plus combined view). It covers parameters, use cases, and cost implications, making it complete for the tool's complexity.

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

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

Schema coverage is 100% with parameter descriptions. The description adds context about model defaults and the optional nature of '_apiKey', clarifying the interplay between models and API key, 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?

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility 0-100 per model. It distinguishes from siblings by focusing on AI-visibility auditing, unlike 'deep_research' or 'scan_competitor_ai_presence' which serve different purposes.

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 use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It explains when to use optional API key for Anthropic, but does not explicitly exclude alternatives or compare to siblings directly.

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 safety profile (readOnly, idempotent, not destructive). The description adds value by explaining the routing to 5,008 tools, argument filling, and returning citations. No contradiction with annotations.

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

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

Front-loaded with key instruction, every sentence is informative. Efficiently covers purpose, usage, examples, and relationships to siblings 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 high annotation coverage and broad scope, the description adequately covers when and how to use, what returns (structured answer with citations), and how it differs from alternatives. No output schema needed.

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

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

Schema coverage is 100% with all parameters described. The description adds examples and clarifies the central 'question' field accepts natural language, but does not add significant meaning beyond the schema.

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

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

The description clearly states the tool answers factual questions using 5,008 verified sources with structured data and citations. It distinguishes from siblings ask_pipeworx_grounded and deep_research, and gives specific examples like 'current US unemployment rate' and 'Apple's latest 10-K'.

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 'PREFER OVER WEB SEARCH' and instructs when to use the grounded variant for hallu-resistant answers and deep_research for broad queries. Provides example question types and signals it is the default entry point for most questions.

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, such as source-preference ranking behavior and that it is a fully functional router. Annotations already provide readOnlyHint, idempotentHint, destructiveHint; the description adds specific routing logic detail.

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 efficiently convey the tool's identity, key difference from the stable version, usage instruction, and a note about its nature. Every sentence serves a purpose 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?

For a beta tool that mirrors another tool, the description adequately covers purpose, usage, and behavioral info. The absence of output schema description is mitigated by reference to 'same response shape' as ask_pipeworx, but a brief mention of what the response contains would enhance completeness.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description adds semantic value by explaining that the question is used for source-preference routing, which helps the agent understand how the input is processed beyond its type.

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's a beta version of ask_pipeworx with identical routing but candidate improvements, specifically source-preference ranking. It distinguishes itself from the stable ask_pipeworx and other sibling tools.

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

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

Explicitly tells when to use ('when you want the newest routing') and that results are compared against the stable router. Also clarifies it's a full working router, not a fallback, giving clear context for usage.

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

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

Annotations already indicate safe read operations (readOnlyHint, openWorldHint, idempotentHint). The description adds significant behavioral context: the tool fetches data from 5,008 tools across 1,318 sources, extracts answers only from tool results, and returns explicit refusal reasons. It also mentions the extra LLM call cost, which is valuable 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 relatively long but each sentence contributes essential information (use case, behavioral guarantee, return format, trade-offs). It is front-loaded with the core concept 'hallucination-resistant answer mode' and structured logically. A slight reduction in verbosity could improve conciseness, but overall it earns its length.

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

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

Given that the tool has no output schema and only one required parameter (with aliases), the description comprehensively covers the return payload, failure modes, and rationale for use. It also differentiates from the sibling tool effectively. The tool's complexity is well-handled, leaving no obvious gaps for an agent to infer.

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 all parameters being aliases for 'question'. The description notes that the parameter accepts natural language and lists aliases, but adds no additional semantic information beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function as a 'hallucination-resistant answer mode for high-stakes reads' and explicitly distinguishes it from its sibling 'ask_pipeworx' by noting the extra LLM call cost and appropriate use cases. It uses specific verbs and resources, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool (high-stakes reads requiring citation, e.g., financial verdicts, legal claims) and when to prefer the alternative ('prefer ask_pipeworx for casual lookups'). It also lists specific refusal reasons, aiding the agent in deciding appropriateness.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description goes far beyond: it explains market resolution, classifier selection, fan-out behavior, response shapes, resolver contract with confidence levels, parent event extraction, news fields with fallback handling, safety short-circuits for low-confidence and closed markets, illiquid spread warnings, and cancellation rule parsing. Every behavioral edge case is disclosed.

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

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

The description is long but well-structured, starting with a concise one-line summary followed by detailed sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.). Every sentence adds significant information; there is no fluff. While it could be more concise, the complexity of the tool justifies the length.

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

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

Despite having no output schema, the description thoroughly covers all return fields: market (bid/ask/liquidity/price changes), analysis (model probability, edge, kelly fraction, 24h move warning), evidence (keyed by source), resolver contract (confidence, alternatives, suggestions), parent_event (legs, partition size), news fields (fallback info), and safety returns (low_confidence_match, market_closed_or_inactive, illiquid_wide_spread). It also explains cancellation rules and their implications. 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?

Input schema covers all three parameters with descriptions. The description adds value by explaining the depth parameter's modes ('quick = 2-3 evidence sources, thorough = full fan-out') and the include_raw parameter's effect on response size and use cases. It also recommends defaults and provides guidance (e.g., 'When false (recommended)...'). This goes beyond schema descriptions, earning 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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input types (slug, URL, question text) and output (evidence packet + market-vs-model comparison). It distinguishes from sibling tools like polymarket_edges or polymarket_arbitrage by focusing on general research rather than specialized calculations.

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 usage scenarios: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It gives many examples of when to call the tool. It does not explicitly state when not to use it, but the context implies that other tools may be better for specific edge cases (e.g., fill risk, arbitrage).

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 behavioral traits: it is read-only, idempotent, and non-destructive (consistent with annotations). It adds context about data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling off-calendar fiscal years, and the return format (paired data with citation URIs). No contradictions with annotations.

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

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

The description is a single focused paragraph, front-loaded with common trigger phrases. Every sentence adds unique value—no repetition of schema or annotations. Efficient and well-structured.

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

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

Given the tool's complexity (two entity types, up to 5 entities comparison, detailed financial data handling), the description covers all essential aspects: trigger phrases, data sources, edge cases (off-calendar fiscal years), and output format. No output schema is needed because the description sufficiently explains return values.

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

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

The input schema covers 100% of parameters with descriptions, and the description enriches them by detailing exactly what data each type pulls (e.g., revenue, net income for companies; adverse-event counts for drugs) and providing examples for the values parameter.

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

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

The description clearly states the tool performs side-by-side comparisons of 2–5 companies or drugs, with specific data sources and metrics. It distinguishes from sibling tools like entity_profile by emphasizing it replaces 8–15 sequential lookups and should be preferred for comparisons.

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

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

The description gives explicit usage triggers (e.g., 'which is bigger', 'rank these companies') and advises preferring it over sequential lookups. It covers both entity types and data sources. While it does not explicitly list exclusions, the context is clear enough for an AI agent to infer when to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that it returns specific fields and mentions a follow-up action (pass resource_id), but doesn't disclose pagination behavior or response limitations.

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

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

Two sentences with clear, front-loaded information. No unnecessary words.

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

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

The description explains the return fields and hints at the workflow (pass resource_id to another tool). Though output schema is missing, the return spec is sufficient given the tool's simplicity.

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

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

Schema coverage is 100%, so the description doesn't need to add much. It doesn't provide extra context beyond what the schema already conveys for each parameter.

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

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

The description clearly states it searches the Fulton County Open Data catalog by keyword and lists the returned fields. It distinguishes from siblings by specifying a unique data source.

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

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

No explicit guidance on when to use this tool versus alternatives. The context implies it's for the specific catalog, but no when-not-to or alternative references.

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 many behaviors: account required, parallel decomposition, output format including gaps/contradictions, hop field, duration, and iteration logic. Annotations already indicate read-only, idempotent, non-destructive, and open-world; description adds rich context without contradiction.

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

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

The description is lengthy but well-structured with clear sections and front-loading of critical info (account required, what it is not). While every sentence adds value, it could be slightly more concise; still, it's well-organized and prioritizes key information.

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

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

Covers prerequisites, limitations, output format, performance expectations, and iteration behavior. With only 2 parameters and no output schema, the description compensates fully by detailing the return structure and edge cases. Complete for a complex research tool.

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

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

Both parameters (question and depth) are fully explained with examples. The depth enum values have detailed descriptions of what each does (quick=3 facets, standard=5 with gap recovery, thorough=8 with lead chasing). Schema coverage is 100%, but description adds significant value beyond enum values.

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

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

The description clearly states the tool performs grounded multi-source research across structured data sources in one call, and explicitly distinguishes it from siblings like ask_pipeworx and bet_research. It specifies its best use for broad/multi-part questions over structured data.

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

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

Provides explicit guidance on when to use vs. alternatives: for single lookups use ask_pipeworx, for breaking news prefer ask_pipeworx, and mentions account tiers. Also explains when not to use (topics not in structured catalog return empty gaps).

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

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

Annotations already declare safe, read-only, and idempotent behavior. The description adds that each result includes 'full input schemas (with curated examples)' and is 'ready to call directly,' which adds useful behavioral context beyond annotations. No contradictions.

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

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

The description is a single paragraph that front-loads the core purpose. The list of example domains is long but adds clarity. Each sentence contributes, and the structure is logical: purpose, usage, return value. Could trim slightly but remains effective.

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

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

Given no output schema, the description fully explains what is returned: 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples).' It also mentions default/max limits from schema. This is complete for a discovery tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that multiple aliases (task, q, description, search) exist for the query parameter and provides concrete examples. This goes slightly beyond the schema's alias descriptors.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It explicitly distinguishes from siblings by calling it a discovery/browsing tool to be used first, not for a single answer. The list of example domains reinforces clarity.

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

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

The description provides clear usage guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It implies when not to use by emphasizing that this is for browsing, not direct answering. The sibling context shows many specific tools, so the guideline is effective, though it doesn't name them explicitly.

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 important behaviors beyond annotations: it fans out across multiple sources, returns specific fields with URIs, notes sorting order for fundamentals, and mentions the USPTO PatentsView API sunset with a soft-fail behavior. This adds significant context that complements the read-only, idempotent 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 examples and a clear purpose statement. While it is somewhat lengthy, every sentence contributes meaningful information. The structure organizes return fields logically, but could be slightly more compact without losing clarity.

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

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

Given the tool's complexity (multiple data sources) and the absence of an output schema, the description thoroughly explains what the tool returns: CIK, company name, recent filings with URIs, fundamentals sorted by period_end, patent status, news, and LEI. This covers all necessary details for an agent to understand and use the tool correctly.

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

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

The input schema already describes both parameters, including the enum for type. The description adds value by clarifying that value expects a ticker or zero-padded CIK, and that names are not supported—information not fully conveyed by the schema alone. The additional example and constraint on name resolution are helpful.

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

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

The description begins with example queries that clearly show the tool's purpose of providing a holistic company profile. It explicitly states it is a 'full cross-source profile of a US public company in ONE parallel call' and lists the data sources, making the purpose unmistakable and distinct from sibling tools.

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

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

The description explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' providing direct guidance on when to use this tool. It also states that names are not supported and advises using resolve_entity first if only a name is available, offering clear alternatives.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. Description adds that it deletes by key but no additional behavioral traits like auth requirements or side effects beyond what annotations convey. Acceptable given annotation coverage.

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 wasted words. Front-loaded with action, then usage guidance. Perfectly concise for the complexity of the tool.

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

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

For a simple delete tool with one required parameter and no output schema, the description covers purpose and usage context adequately. Slight gap: no mention of return value or error handling, but acceptable given tool simplicity.

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

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

Schema covers 100% of parameters with a clear description for 'key'. The description repeats the parameter's purpose ('memory key to delete') without adding new semantics. Baseline score 3 for high schema coverage.

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

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

Description clearly states the verb 'Delete' and the resource 'previously stored memory by key'. It distinguishes from sibling tools 'remember' and 'recall' by mentioning pairing with them, making purpose unambiguous.

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

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

Provides explicit use cases: stale context, task completion, clearing sensitive data. Mentions pairing with remember and recall. However, lacks explicit when-not-to-use guidance, such as advising against deletion if memory is still needed.

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 value beyond the annotations by detailing the process: fetches the page, extracts title/description/key links, and emits standard markdown format. Annotations already cover safety (readOnlyHint, idempotentHint), so the description enriches with operational details.

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

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

The description is highly concise with two sentences and a bullet list, front-loading the purpose in the first sentence. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (2 params, no output schema) and rich annotations, the description comprehensively covers purpose, input, output format ('single text blob ready to drop at site-root/llms.txt'), and use cases. 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%, so baseline is 3. The description adds meaning by providing an example URL format and specifying defaults (default 25, max 50) for max_links, which goes beyond the schema descriptions.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb ('generate') and the resource ('llms.txt file'). It distinguishes from siblings by focusing on a specific standard file format, unlike related tools like 'scan_competitor_ai_presence' which likely assess presence differently.

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 cases (getting a client's site indexed, drafting for own project, auditing competitors) but does not explicitly state when to avoid using this tool or name alternative tools. The context is sufficient for an agent to infer appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about returning active subscriptions by default and the include_inactive parameter behavior. No contradictions.

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

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

Two sentences, front-loaded with purpose, no redundant information. Efficient and clear.

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

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

For a simple tool with one optional parameter, the description fully covers what it does, when to use it, what it returns, and the effect of the parameter. Annotations provide safety context.

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

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

Schema coverage is 100% with a clear description for the one parameter. The description reinforces that it lists active subscriptions but does not add significant new semantics beyond the schema.

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

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

The description clearly states 'List the caller's active subscriptions' and specifies the exact return fields (id, type, params, created_at, last_fired_at, fire_count). It distinguishes from sibling tools like subscribe and unsubscribe by focusing on listing.

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

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

The description provides explicit use cases: 'review what you're monitoring before adding more or to find an id to cancel.' This implies when to use this tool versus alternatives, though it does not name siblings directly.

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

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

Annotations already indicate safe, idempotent read. The description adds valuable detail on returned fields (columns, types, row count, etc.), enhancing transparency.

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 front-loads purpose; efficient with no wasted words, though could be more structured.

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

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

Adequate for a simple tool with one param and no output schema; covers what it returns and the required ID format.

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

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

Schema covers the single parameter fully; description adds an example but minimal extra semantic value beyond the schema.

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

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

The description clearly states the tool retrieves schema and metadata for a dataset by resource_id, with an example. It distinguishes from sibling tools like 'datasets'.

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

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

No explicit when-to-use or alternatives mentioned; usage is implied by the tool's purpose but lacks comparison to other 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 indicate the tool is not read-only, not idempotent, etc. The description adds important behavioral context: rate-limited to 5 per identifier per day, free, doesn't count against quota, and that the team reads digests daily affecting roadmap. 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 yet comprehensive: one paragraph front-loaded with action and use cases. Every sentence provides essential information without redundancy. 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 no output schema, the description still explains what the tool does, how the feedback is used (affects roadmap), rate limits, and quota info. It covers all relevant aspects for a feedback submission tool.

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

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

Schema coverage is 100%, so the schema already documents parameters well. The description adds value by explaining when each type (bug, feature, etc.) is appropriate and specifying message constraints (1-2 sentences, 2000 chars max). This goes beyond schema.

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

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

The description clearly states the tool's purpose: sending feedback (bug, feature, data_gap, praise) to the Pipeworx team. It distinguishes from siblings as it is a feedback tool, not a query or action tool, and provides specific use-case examples.

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

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

Explicitly states when to use (bug, feature, data_gap, praise) and what not to do (don't paste end-user prompt). It also instructs users to describe issues in terms of Pipeworx tools/packs, providing clear guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds beyond: explains data source (CF analytics-engine), privacy (no PII), output format (pack, tool, count), and caching behavior (5min-1h). 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?

Approximately 100 words, front-loaded with the core action and output, followed by bulleted use cases. Every sentence adds value; 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?

For a single-parameter read-only tool with no output schema, the description covers purpose, use cases, data source, privacy, and caching. It is complete without needing additional details.

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

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

The schema already describes the window parameter with enum values and a short description. The description adds semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand,' enhancing parameter understanding.

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

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

The description clearly states the tool returns trending data ('top tools, top packs, total call volume') over configurable windows. It uses specific verbs ('returns') and explicitly distinguishes from siblings by focusing on aggregate AI agent usage, not feedback or edges.

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

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

Three concrete use cases are provided (discovering hot data sources, confirming canonical tools, aligning use case). While it doesn't explicitly say when not to use or name alternatives, the context is clear enough for an AI agent to decide.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds substantial behavioral context: algorithms used, fill check behavior, semantic anchor (Jaccard similarity threshold), partition filter (placeholder removal). Does not contradict annotations.

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

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

The description is thorough and front-loaded with the core purpose, then expands on modes and details. While slightly verbose, every sentence adds value. Could be shortened slightly, but the structure is logical and easy to follow.

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

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

Despite no output schema, the description fully explains the response format (opportunities[] with fields, partition_check details, fill check results). It covers all aspects of a complex tool: input modes, algorithms, edge cases (placeholders), and references to sibling tool for further needs.

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

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

Schema coverage is 100% with descriptions. The description adds meaning beyond the schema: explains event slugs and URL acceptance, topic seed questions, and the consequences of each parameter choice (e.g., 'walks child markets' for event, 'searches related events' for topic).

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

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

The description opens with a specific verb+resource: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly distinguishes three modes (trending_scan, event, topic) and differentiates from sibling tools like polymarket_fill_risk.

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

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

Explicit guidance on when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. It explains why topic mode is useful and warns when not to trade (if realizable_edge_pp ≤ 0). Also references polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description greatly expands on behavioral details: it explains the three model families with specific methodologies (e.g., lognormal barrier from FRED, GDELT ratio, partition_overround with bias correction), caching at KV level, diagnostic outputs, and specific exclusion of Fed bets. This far exceeds the annotation information.

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 extremely detailed and structured with clear sections for each model family, but it is a single dense paragraph without explicit formatting for easy scanning. While every sentence provides value given the complexity, the length could be reduced for better conciseness, and the front-loaded purpose is good, but the overall structure is not highly efficient.

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

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

Given the tool's complexity (three model families, nine parameters, no output schema), the description is remarkably complete. It explains the response structure (by_segment, diagnostics, fed_candidates), caching behavior, and user-configurable knobs. All necessary context for an agent to select and invoke the tool correctly is present.

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

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

Schema coverage is 100% with all parameters described in the schema. The main description does not add additional meaning or context for the parameters beyond what is in the schema. Therefore, the description provides no added semantic value for parameters, maintaining the baseline score.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It frames the purpose as 'what should I bet on today' and details three model families. However, it does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_edge_tracker, missing a chance to clarify when to use this specific tool over alternatives.

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

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

The description indicates the tool is for discovering opportunities without paging through hundreds of markets, providing a clear use case. However, it lacks explicit guidance on when not to use it or when alternatives like polymarket_arbitrage might be more appropriate. The usage context is implied but not fully clarified.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. Description adds critical context: history is bounded by 60-day TTL and snapshot start date; decay uses daily closes not intraday; gaps in snapshot dates indicate no scanning occurred. Also details the response structure (tracked, expired, snapshot_dates). No contradiction with annotations.

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

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

Description is comprehensive but slightly verbose; it packs behavioral details and return structure in one paragraph. Front-loads purpose well. Could be slightly more concise but every sentence adds value.

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

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

Given 2 optional parameters and no output schema, the description fully covers tool behavior, constraints, and output shape. It explains response fields, limits (TTL, snapshot start), and data meaning (decay from daily closes). Complete for effective use.

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

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

Schema covers both parameters with descriptions. Description adds value by explaining the 'window' parameter as 'snapshot family' and listing possible values (24hr, 1wk, 1mo), which the schema does not enumerate. Also notes default and clamp for 'days'. This goes beyond schema.

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

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

Description clearly states the tool tracks edge persistence and decay telemetry from daily snapshots, explicitly distinguishing it from a current-edges tool by focusing on time-series analysis. It answers the specific question of how long edges have existed and whether they are shrinking.

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

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

Description implies usage context by contrasting fresh vs. old edges and mentioning when to use (to decide if an edge is worth trading). It does not explicitly exclude alternatives, but the sibling 'polymarket_edges' is implicitly for current edges, and the description's focus on decay provides clear guidance.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds significant detail: 'walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict.' It also explains basket mode behavior including forced directional risk, which 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?

The description is well-structured with clear sections and bolded mode headers. It is front-loaded with the core purpose. Every sentence adds value, and the length is justified by the tool's complexity. No wasted words.

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

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

Given the tool's complexity (two modes, multiple outputs, risk assessment) and lack of output schema, the description is exceptionally complete. It defines all return fields, explains edge cases (thin_legs, forced_directional_risk), and provides numerical examples.

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

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

Although schema coverage is 100% (baseline 3), the description adds meaning: explains size_usd interpretation per mode, side options with defaults, and auto-detection for basket. This adds value 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 immediately states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It then differentiates between single-market and basket modes, detailing what each returns. This clearly distinguishes it from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicit usage guidance is provided: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why (theoretical overround not capturable, partial fills create directional risk), giving clear when-to-use and when-not-to-use context.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds detailed behavioral context: safety fields (compatibility_warning, temporal_alignment), skipped cross-type/subtype counters, and explains when spreads are mathematically meaningless. No contradictions with annotations.

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

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

The description is somewhat verbose (nearly 300 words) but well-structured: main purpose first, then modes, response format, safety fields. It is front-loaded and every sentence adds information. Slight verbosity due to thoroughness.

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

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

Given no output schema, the description adequately details the response structure (leg-by-leg prices, spread, safety fields) and covers edge cases. It could be more explicit about the JSON format, but the provided explanation is sufficient 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?

The input schema covers all 3 parameters with descriptions. The description adds significant value by explaining the behavior of topic parameter with 10 pre-mapped values, and gives example formats for kalshi_event_ticker and polymarket_event_slug, along with mode behavior.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It identifies two distinct modes (topic shortcuts and explicit tickers) and distinguishes itself from siblings like polymarket_arbitrage by focusing on cross-venue comparison.

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

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

The description provides explicit guidance on when to use each mode, including examples of topic shortcuts and custom pairings. It also warns that most pre-mapped topics return compatibility warnings, advising that they are not tradeable. However, it does not mention sibling tools as alternatives when compatibility fails.

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. The description adds specific behavioral details: SoQL clauses without leading $, pagination with limit/offset, and JSON return format. No contradictions.

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

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

The description is a single, well-structured sentence that conveys all essential information concisely. It front-loads the action and includes examples, 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?

Given the tool has 7 parameters and no output schema, the description adequately covers the query language, required resource_id, and return format. It could mention pagination default limit, but that is minor.

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

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

Schema coverage is 100%. The description adds meaning beyond the schema by explaining SoQL syntax (e.g., 'without the leading $') and providing examples for where and select, which helps the agent construct accurate queries.

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 runs a Socrata SoQL query against a Fulton County Open Data dataset by resource_id, with specifics on clauses and return format. This distinguishes it from sibling tools like 'datasets' which list datasets.

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

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

The description explicitly tells when to use the tool: to query a dataset by resource_id using SoQL filters. It does not explicitly state when not to use or name alternatives, but the context and sibling tool names imply clear boundaries.

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 scoping detail (by identifier) beyond annotations (readOnlyHint, idempotentHint). No contradiction; it complements the safety profile with context about key omission 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?

Extremely concise: three sentences covering all essential information—action, condition for listing, use case, scoping, and related tools. No waste.

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

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

For a simple tool with one optional parameter and no output schema, the description fully addresses retrieval, listing, scoping, and tool relationships. No gaps.

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

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

Schema coverage is 100%, but the description adds meaning by explaining the significance of omitting key to list all keys, reinforcing the parameter's optionality and purpose.

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

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

The description clearly states it retrieves a value saved via remember or lists all keys if omitted, uniquely distinguishing it from sibling tools like remember and forget by name.

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 use case is provided (look up stored context without re-deriving), along with pairing instructions. It could mention when not to use, but the context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: setting mark_read affects future calls, and the feed structure (fields included). 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 three sentences, front-loading the purpose and quickly covering return fields, filtering, and alternative access. It is dense but efficient; no extra fluff.

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

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

Covers purpose, return fields, filtering, mark_read behavior, and alternative access. For a read-only polling tool with 5 optional parameters and no output schema, this is fairly complete. Minor gaps on pagination and error conditions are acceptable given simplicity.

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 each parameter described. The description mentions filtering by type and since, and mark_read behavior, but adds no significant semantic detail beyond the schema descriptions. Baseline score of 3 is appropriate.

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

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

The description clearly states it pulls fired events from the subscription feed and returns recent alerts with specific fields. It distinguishes itself from sibling tools by mentioning an alternative access method for scripts, but does not explicitly differentiate from similar tools like 'list_subscriptions' or 'subscribe'.

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 'Polls work fine' and provides an alternative REST endpoint, but gives no explicit guidance on when to use this tool versus sibling tools such as 'recent_changes' or 'list_subscriptions'. There is no 'when not to use' or comparison to alternatives.

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

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

Annotations already indicate safety (readOnly, idempotent, non-destructive). Description adds fan-out strategy, GDELT→GNews fallback, USPTO soft-fail, and response structure 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?

Well-structured and front-loaded with query examples, but slightly wordy. Every sentence adds value, though some redundancy in listing sources.

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 details return structure (changes[] grouped by source, total_changes count, citation URIs). Also covers failure modes and soft-fail, making it self-contained.

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

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

Schema has 100% coverage, but description adds concrete examples ('7d', '30d', '1y'), explains ISO vs relative, and gives usage hints ('30d' for typical monitoring), adding significant value.

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

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

Description clearly states it provides a change feed for a company, lists specific sources (SEC EDGAR, GDELT/GNews, USPTO), and contrasts with entity_profile for static profiles.

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 (questions like 'what's new') and when not to (use entity_profile for static profile). Provides fallback behavior and window handling.

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 idempotentHint and destructiveHint. Description adds scoping by identifier, persistence differences for authenticated vs anonymous users, and retention duration.

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

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

Concise, front-loaded with main purpose. Every sentence adds value (usage guidance, scoping, pairing with other tools). No wasted words.

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

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

Covers purpose, usage, parameters, scoping, and retention. No output schema needed; return values are implicit. Complete for a simple key-value store tool.

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

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

Schema coverage is 100% with good descriptions. The description repeats similar examples ('subject_property') but adds no new information beyond the schema's parameter descriptions.

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

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

The description clearly states the tool saves data for reuse later, specifies example use cases (ticker, address, preference), and distinguishes from sibling tools recall and forget.

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

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

Explicitly tells when to use ('when you discover something worth carrying forward') and pairs with recall/forget. Mentions scoping and retention details.

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 valuable context: it cascades through several lookup endpoints, returns canonical identifiers with citations, and explains auto-disambiguation for companies. This goes beyond the annotations, making the tool's behavior transparent without contradiction.

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

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

The description is well-structured with a clear front-loading of common queries. It uses bullet-like formatting for supported types, making it scannable. While slightly lengthy, every sentence adds value and there is no redundancy. Minor streamlining could be possible, but it remains effective.

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

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

Given the tool handles two distinct entity types with different input and output formats, the description thoroughly explains both. It covers return values (ticker, CIK, RxCUI, citations) and input variations. With no output schema provided, the description fully compensates by detailing what the agent can expect.

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

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

Schema coverage is 100%, but the description adds significant meaning: it provides concrete examples of valid values (ticker, CIK, name for company; brand/generic for drug) and explains the output structure for each type. This aids the agent in constructing correct inputs and understanding the response format.

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 specifies the verb 'resolve' and the resource 'entity', with concrete examples like 'What's the ticker for…' and lists supported types (company, drug). It clearly distinguishes the tool's purpose from siblings by stating 'Use FIRST whenever you have a name but need an ID.' The purpose is unambiguous and tied to specific use cases.

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

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

The description explicitly provides usage guidance: 'Use FIRST whenever you have a name but need an ID.' It gives context on when to use the tool and mentions that it replaces 2-3 manual lookups. However, it does not explicitly state when not to use it or list alternative tools, which would strengthen the guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. Description adds valuable behavioral context: notes it probes each entity with ai_visibility_check, ranks results, returns 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?

Three sentences: first states main purpose, second details mechanics, third gives usage example. Front-loaded and efficient. Every sentence earns its place.

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

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

No output schema, but description explicitly mentions return format ('ranked list with score, confidence, signal density per entity'). All four parameters are described in schema and description adds useful ordering note. For a comparative probing tool, this is 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 has 100% description coverage, so baseline is 3. Description adds extra meaning for 'entities' parameter: 'First entry treated as the "subject" for narrative; rest are competitors.' This nuance is not in the schema. Also clarifies 'models' default behavior. Thus adds value beyond schema.

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

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

Description uses specific verb 'Compare AI visibility' and identifies the resource ('multiple entities'). clearly distinguishes from sibling 'ai_visibility_check' by stating 'side-by-side' and 'probes each entity ... ranks by score'. Additionally, it frames the use case for competitive AI-marketing audits, leaving no ambiguity.

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 'Useful for competitive AI-marketing audits' and gives an example question. Implicitly tells when to use (multiple entities) vs. a single-entity check (ai_visibility_check). However, it does not explicitly state when not to use or mention alternatives beyond the 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 adds significant behavioral context beyond annotations: composite fan-out, partial failure degradation (sources_failed list), and specific return fields. It discloses that bundlephobia's first measurement can take 5-30s. 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 comprehensive but slightly verbose. Every sentence serves a purpose: purpose, use case, return summary, ecosystem scope, failure behavior. Could be tightened, but still well-structured and front-loaded with key info.

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

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

Given the tool's complexity (combining two services, partial failures, two parameters, no output schema), the description is complete. It enumerates return fields, failure handling, and ecosystem scope, making it self-contained for agent 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% with both parameters described. The description adds semantic value by confirming scoped packages are accepted and default behavior for version parameter (latest if omitted), which is not in the schema.

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

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

The description explicitly states the tool's purpose as a composite check for evaluating npm packages using deps.dev and bundlephobia, with specific use cases like 'is X safe / popular / small'. It clearly distinguishes itself from sibling tools by focusing on npm package dependency analysis.

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

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

The description provides explicit when-to-use guidance ('whenever an agent asks about safety/popularity/size'), and notes limitations: NPM only in v1, alternative for other ecosystems via deps.dev:version directly. It also warns about potential delay in bundlephobia measurements.

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

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

Describes embedding model (BGE-base-en), similarity metric (cosine), windowing (500-char overlapping), character cap (200K) with truncation behavior. Adds significant context beyond annotations which already declare safe, idempotent operation.

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

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

Four sentences, front-loaded with key purpose. Every sentence adds value: what, when, how, constraints. No redundancy.

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

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

Given no output schema, description explains return format (top-N passages with offsets and scores). Covers purpose, usage, behavioral specifics, and parameter details. Fully 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 covers all 3 params (100% coverage). Description adds examples and usage context for 'text' and 'query' (e.g., 'supply-chain risk', 'fiscal year 2024 revenue'). Does not repeat schema but enhances 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?

Clear verb 'semantic search INSIDE a fetched record' with specific resource type (fetched record) and examples (SEC 10-K, article). Distinguishes from sibling ask_pipeworx_grounded by stating the pairing workflow.

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: 'when the record is too big to cram into the prompt'. Mentions pairing with ask_pipeworx_grounded. Lacks explicit when-not-to-use but context is clear.

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

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

Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds significant behavioral details: returns new subscription id (non-idempotent in result), requires Pipeworx OAuth account, phone verification for SMS, SMS cap of 10/day, webhook auto-disable after 10 failures. 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 front-loaded with purpose and returns. It is relatively long but every sentence adds value (types, delivery details, constraints). Could be slightly more concise, but the structure with bullet-like enumeration is effective. No wasted words.

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

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

Given the complexity (3 parameters, nested objects, multiple types and delivery options, no output schema), the description is remarkably complete. It covers all types with examples, all delivery options with constraints, and edge cases like webhook signing and auto-disable. No gaps.

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

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

Schema coverage is 100%, baseline 3. The description adds substantial meaning beyond schema: explains each type with concrete examples (e.g., sec_8k items for officer change), details delivery channel constraints (phone verification, SMS cap, webhook signing). This greatly aids understanding of parameter behavior.

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

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

The description clearly states the tool's purpose: 'Create a proactive monitoring subscription to a live-data event stream'. This distinguishes it from sibling tools like list_subscriptions, unsubscribe, and recent_alerts. The verb 'create' and resource 'subscription' are specific.

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 when-to-use guidance by explaining supported types, required account, and delivery channels. It implicitly contrasts with alternatives (e.g., listing subscriptions) but does not explicitly state when not to use it or name specific sibling tools. The context is clear enough for most use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable context about what the output contains (category-bucketed examples with exact tool+argument shape) and that it is an onboarding tool. It does not contradict annotations and provides more detail than the annotations alone.

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

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

The description is well-structured and front-loads the key purpose. It uses dashes and line breaks for readability. While it is somewhat long, every sentence adds necessary information (list of topics, explanation of output, usage guidance). It could be slightly more concise but remains informative.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is fully complete. It explains what the output looks like, how to use it for full spread or focused topics, and when to call it. There are no gaps in understanding the tool's behavior or return value.

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 description for the optional 'topic' parameter. The description enhances this by providing concrete examples of topic values (finance, pharma, betting) and clarifying that omitting the argument gives a cross-category spread. This adds meaningful guidance beyond the schema's generic description.

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

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

The description clearly states the tool returns category-bucketed example questions to help users understand what Pipeworx can do. It specifies the verb 'returns' and the resource 'example questions', and distinguishes itself from siblings like 'ask_pipeworx' by being the onboarding entry point.

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 to use this FIRST when the user does not know what Pipeworx can do, or to learn how to call meta-tools. It provides guidance on no arguments vs. topic argument, and implies that for other purposes (e.g., getting actual answers) other tools should be used.

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

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

Adds valuable behavioral context beyond annotations: ownership enforcement, deactivation vs deletion, and that historical events remain accessible via recent_alerts. Annotations already indicate non-destructive and idempotent, and description aligns well.

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

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

Extremely concise: two sentences with no fluff. Front-loaded with primary action, then key behavioral 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?

For a simple tool with one parameter and no output schema, the description covers purpose, ownership, side effects, and related tool (recent_alerts). No gaps.

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

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

The single parameter 'id' is well-documented in the schema (UUID from subscribe). The description does not add extra meaning beyond mentioning it's an id, but schema coverage is 100% so baseline is appropriate.

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

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

The description clearly states the tool's purpose: 'Cancel a subscription by id.' It distinguishes from siblings (e.g., subscribe, list_subscriptions) by specifying cancellation via id.

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

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

Provides context about ownership enforcement and that the row is deactivated rather than deleted, implying when to use (cancel own subscriptions) and why not to worry about data loss. However, lacks explicit comparison to sibling tools like 'use list_subscriptions to view active subscriptions'.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description goes beyond by detailing the two processing paths (EDGAR vs grounded pipeline), the return fields (verdict, value, citation, reasoning), and that it replaces multiple sequential calls. No contradictions with annotations. Slightly more behavioral detail (e.g., latency, auth) could push to 5.

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 a front-loaded list of trigger phrases, followed by behavior details. It is concise for the depth of information (~150 words). Every sentence adds value. Minor verbosity in examples, but overall very efficient.

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

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

Despite having no output schema, the description fully explains the return values: verdict types, actual value with citation, and reasoning. It covers input parameters, processing logic, and output format. For a tool with only 2 parameters and high schema coverage, this is complete and leaves no obvious gaps.

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

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

Schema covers both parameters with descriptions (100% coverage). The description adds value beyond schema by explaining tolerance_pct default values, override use cases (e.g., hallucination detection), and how tolerance is implied by wording. This enriches the semantic understanding, meriting 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 verifies factual claims using natural language, with specific verb+resource ('validate claim'), and covers two distinct pipelines (SEC EDGAR for financial, grounded for others). However, it does not explicitly differentiate from sibling tools like ask_pipeworx_grounded or deep_research, missing an opportunity to clarify when to prefer this tool over alternatives.

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

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

The description provides clear guidance on when to use: 'whenever the agent needs to check whether something a user said is factually correct.' It also distinguishes between financial and non-financial claim handling, implying when not to use (e.g., for subjective questions). However, it lacks explicit 'when not to use' or references to alternatives, reducing the score from 5.

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