Makstat Mk

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the output format (per-model {score, confidence, signals, raw_response} + combined view) and clarifying billing implications for the Anthropic probe. No contradictions with annotations.

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

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

The description is concise (three sentences) and well-structured. It front-loads the core action, lists key parameters, and provides output summary. 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 no output schema and rich annotations, the description covers the essential behavior: probing LLMs, scoring, return structure, and key usage condition (apiKey). It omits error handling or rate limits, but for a non-destructive read tool with good annotations, 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 description coverage is 100%, so baseline is 3. The description adds context beyond the schema: it explains the default model, that _apiKey is only needed if 'anthropic' is in models, and that 'context' helps disambiguate. This additional clarity justifies a 4.

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

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

The description clearly states it probes LLMs for brand visibility and scores them. It specifies the verb 'Probe' and resource 'business/brand/product/topic'. However, it does not explicitly distinguish from sibling tools like 'scan_competitor_ai_presence', which seems similar.

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

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

The description explains it's useful for AI-marketing audits, pre-launch checks, and competitive monitoring. It also notes when to use the _apiKey parameter (only if probing Anthropic). But it does not provide explicit when-not-to-use guidance or alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true – the description confirms the tool is read-only and authoritative but adds detail about routing to 5,564 tools and returning pipeworx:// citation URIs. No contradictions. Slight deduction because it doesn't note that results are single-answer only (as opposed to streaming or multi-part) – that nuance is left to the sibling hint rather than explicitly stated.

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 (4 sentences) but every sentence adds value: preference guidance, use cases, examples, and escalation paths. The first sentence immediately establishes priority over alternatives, which is front-loaded well. Could potentially trim the explicit list of sibling tool names that are already listed in sibling-tools, but not a major issue.

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 (routing to 5,564 tools) and the lack of output schema, the description adequately covers input semantics (natural language question), behavioral expectations (returns structured answer with citations), and usage context. No gaps for an agent to select and invoke it correctly. The examples and sibling distinctions make it self-contained.

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

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

Schema description coverage is 100% – the schema already documents all 6 parameters, including aliases for 'question'. The description adds value by giving concrete examples ('Apple's latest 10-K', 'current US unemployment rate') that illustrate the range of accepted natural language inputs, but doesn't add new parameter-level constraints beyond what the schema provides. Baseline 3, bumped to 4 for the rich example list.

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

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

The description starts with 'PREFER OVER WEB SEARCH' and lists extensive use cases (SEC filings, FDA data, etc.), clearly specifying the verb (route questions) and resource (5,564 tools across 1,462 verified sources). It distinguishes from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for specific 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?

Explicitly states when to use ('START HERE for most questions'), example queries, and when to step up to alternatives like ask_pipeworx_grounded or deep_research. Also clarifies that breaking news is handled, no need for separate news tool.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description explains that this is a full working router, not a fallback, and that it has experimental edge. It also clarifies that it currently matches the stable version due to no active candidate. This adds valuable behavioral context without contradicting annotations.

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

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

The description is compact and well-structured, using a few sentences to convey the tool's relationship to ask_pipeworx, current status, and usage intent. It is front-loaded with the key identity. Minor improvement could be trimming redundant phrases, but overall 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 complexity (universal router with 5,564 tools) and no output schema, the description explains the tool's nature and relationship to the stable version. However, it does not detail the response shape or how to interpret results, relying on the agent's knowledge of ask_pipeworx. For a beta tool, this is adequate but not fully complete.

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

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

Schema coverage is 100% with descriptions for all parameters (including aliases). The description does not add any additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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 that this is a beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape. It distinguishes itself from the stable sibling by explaining the candidate routing improvements and current status. The purpose is clear and 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 tells the agent to use it exactly like ask_pipeworx when wanting the newest routing, and that results are compared against the stable router. It acknowledges that no candidate is active, so it currently matches ask_pipeworx. It does not explicitly state when not to use it, but the context is sufficient for appropriate selection.

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

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

Annotations already declare readOnly/Idempotent/non-destructive. The description adds rich behavioral details: hallucination resistance, exclusive use of tool results, explicit refusal reasons including 'not_in_source', 'no_tool_match', etc., and cost information. No contradiction with annotations.

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

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

The description is a single focused paragraph with front-loaded key purpose. Every sentence adds value: purpose, routing behavior, return structure, use cases, cost comparison. No filler or redundancy.

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

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

Given the tool's complexity (routing across 5,564 tools), the description covers routing, extraction behavior, return format with success/failure fields, refusal reasons, cost implications, and use case guidance. No output schema is needed because return shape is described textually.

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 six parameters documented as aliases for 'question' and their descriptions. The description adds no additional parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description explicitly states the tool as a 'hallucination-resistant answer mode for high-stakes reads' and distinguishes it from the sibling 'ask_pipeworx' by noting the grounded extraction behavior. It clearly identifies the verb (extracts answer), resource (tool results), and scope (only uses returned 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?

The description provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete domains. It also states the alternative: 'prefer ask_pipeworx for casual lookups' and notes the cost trade-off of one extra LLM call.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description adds substantial behavioral detail: market resolution, classifier fan-out, response shapes, safety short-circuits, wide-spread warnings, resolution-rule risk. No contradictions. Fully transparent.

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

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

The description is long but well-structured with front-loaded purpose, examples, and detailed sections. Every part adds value. Could be slightly more concise, but not overly verbose given complexity.

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

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

Given no output schema, the description thoroughly explains return shapes, resolver contract, parent event extractor, news fields, safety, wide spread, and resolution-rule risk. It covers all necessary context for an agent to 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?

Schema coverage is 100% with good parameter descriptions. The description adds minimal extra semantics beyond the schema (e.g., examples for market, clarification of depth options). Baseline 3 is appropriate; description does not significantly enhance 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 researches a Polymarket bet by pulling Pipeworx data. It provides specific verb 'Research' and resource 'Polymarket bet', and distinguishes from siblings by its unique multi-source fan-out and classifier system. Use cases like 'should I bet on X' are explicit.

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

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

The description explicitly says 'Use for 'should I bet on X'', etc., giving clear context. It does not explicitly exclude other uses or compare to siblings, but the classifiers and examples imply when to use. No misleading 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return of 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 paragraph but well-structured with example queries upfront, followed by specific details per entity type. Every sentence adds value, there is no redundancy, and it is appropriately concise for the complexity.

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

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

Given the complexity (two entity types, different data sources) and lack of output schema, the description covers all essential aspects: data sources, sorting, citations, and efficiency gains. It is sufficiently complete for an AI agent to understand what the tool returns and how to use it.

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

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

Schema coverage is 100%, so baseline is 3. However, the description adds substantial meaning beyond the schema: it explains that 'type=company' pulls financial metrics and 'type=drug' pulls adverse event data, and that 'values' are tickers/CIKs or drug names. It also reiterates constraints like 2-5 items.

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

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

The description uses specific verbs like 'compare' and 'side-by-side comparison' and clearly identifies the resources: companies or drugs. It distinguishes itself from sibling tools like entity_profile and sequential lookups, fulfilling the criteria for a high score.

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

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

The description explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing clear when-to-use guidance. It also lists example queries and describes what data is pulled per entity type, effectively excluding alternatives.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive, so the safety profile is clear. The description adds substantial behavioral detail: parallel execution, gap recovery hops, contradictions scan, semantic excerpting, citation URIs, latency expectations (15-90s), and the fact that deep_research returns empty gaps for unsupported topics. No contradiction with annotations.

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

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

The description is dense and front-loaded with critical prerequisites (account, alternatives), but it's very long (12+ sentences) and could be split into clearly labeled sections. Every sentence serves a purpose, but the wall of text format reduces scannability for an agent.

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

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

Given 2 parameters, 100% schema coverage, no output schema, and the tool's complexity (5,564 sub-tools, multiple depth tiers, gap recovery, contradictions), the description fully covers what the tool does, how it works, when to use alternatives, return structure (findings packet with gaps[], contradictions[], hop, citation_uri), and latency. Nothing essential is missing.

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

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

Schema coverage is 100% (both parameters are described in the schema). The description adds meaning to the 'question' parameter by illustrating appropriate scope (broad/multi-part) and to 'depth' by clarifying the number of facets, hops, and extra features per tier, going well beyond the schema's brief enum 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 specifies a verb ('researches') and a resource ('Pipeworx's 1462 STRUCTURED data sources'), and distinguishes the tool from siblings like ask_pipeworx and ask_pipeworx_grounded by explaining it does multi-facet, parallel, deep research across structured databases, not open-web or single-query lookups.

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

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

Explicitly states when to use (broad/multi-part questions over structured data), when NOT to use (breaking news, colloquial topics, single lookups), and names alternatives (ask_pipeworx, ask_pipeworx_grounded). Also explains account prerequisites and depth tier distinctions.

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 value by explaining it returns top-N results with full schemas ready to call, but does not mention rate limits or potential performance issues. No contradiction.

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

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

The description is moderately long but front-loaded with the core purpose. The list of domains is extensive but useful. Every sentence adds value, though some could be more concise.

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

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

Given no output schema, the description explains what the tool returns (names, descriptions, full schemas with examples). It covers the key aspects for an agent to decide to call it, though more detail on return structure would help.

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 all parameters. The description does not add new meaning beyond mentioning 'top-N' which refers to limit. Baseline 3 is appropriate.

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

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

The description clearly states the tool finds tools by describing data or task, listing many example domains. It explains it returns top-N relevant tools with full schemas, distinguishing it from sibling tools that are domain-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?

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides clear context on when to use it, and implies it's for browsing/discovery rather than direct answers.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it fans out across multiple sources, mentions a soft-fail for patents (USPTO sunset), a fallback mechanism (GDELT→GNews), and that it returns pipeworx:// URIs. It could mention potential rate limits or performance, but overall it complements annotations 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?

The description is dense but well-organized, starting with example queries, then stating core purpose, then listing return fields. Every sentence adds value, though it could be slightly more concise. The structure is logical and easy to parse.

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, partial failures), the description is fairly complete. It details what is returned (cik, filings with URIs, fundamentals, patents, news, LEI) and notes the patent sunset. Without an output schema, it adequately describes the return structure. It could specify the response format (JSON) explicitly, but the context 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 coverage is 100%, so baseline is 3. The description adds meaning by providing concrete examples ('AAPL', '0000320193'), explaining that value can be a ticker or zero-padded CIK, and reiterating that names are not supported. This clarifies the parameter usage 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 defines the tool's purpose: producing a full cross-source profile of a US public company in a single parallel call. It uses specific verbs ('profile', 'research', 'brief me') and resources ('US public company', 'SEC/XBRL/news'). It distinguishes itself from sibling tools like resolve_entity by explicitly stating that names are not supported and directing to that tool instead.

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

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

Provides explicit guidance on when to use: 'ALWAYS PREFER over chaining single-pack... lookups when the user asks for a holistic view.' It also specifies when not to use: 'Names not supported — use resolve_entity first if you only have a name.' This is excellent usage 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?

Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds context about clearing sensitive data, but no contradiction. Additional behavioral context is provided beyond annotations.

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

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

Two sentences, front-loaded with core action, no fluff. 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?

With one parameter, destructive hint provided, and no output schema, the description covers all needed context for an AI agent to 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?

Schema coverage is 100% for the single 'key' parameter. Description only repeats the schema description 'Memory key to delete' without adding new meaning beyond what the schema already provides. Baseline score applies.

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

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

The description clearly states 'Delete a previously stored memory by key' with a specific verb and resource, and distinguishes it from sibling tools like 'remember' and 'recall'.

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

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

Explicitly provides when to use: 'Use when context is stale, the task is done, or you want to clear sensitive data...' and suggests pairing with remember and recall.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds behavioral context: 'fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format' and clarifies the output is a single text blob for site-root/llms.txt. No contradictions.

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

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

The description is concise (two paragraphs) and front-loaded with the main action. Every sentence adds value: first paragraph defines the tool and output, second lists use cases. No fluff or repetition.

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

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

With only 2 parameters, no output schema, and rich annotations, the description fully covers what the tool does, its inputs, output format, 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% with clear descriptions for both parameters (url and max_links). The description adds minimal extra meaning (e.g., example URL format) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, using specific verbs ('generate', 'fetches', 'extracts', 'emits') and specifies the resource ('llms.txt file'). It distinguishes itself from siblings like scan_competitor_ai_presence by focusing on file generation rather than 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 use cases (getting a client's site indexed, drafting for own project, auditing a competitor) and context. However, it does not explicitly state when not to use the tool or compare it to alternatives, but the sibling list implies differentiation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds transparency by listing the exact fields returned (id, type, params, etc.) and default behavior (active only). No contradiction. Could mention pagination or rate limits, but not necessary for this simple tool.

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. First sentence states core function and return values. Second sentence provides usage guidance. Every sentence earns its place; no fluff.

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

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

Despite no output schema, the description explicitly lists what is returned. Together with annotations and schema, it fully covers the tool's behavior, parameters, and usage context. No gaps.

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

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

Schema coverage is 100% and the only parameter 'include_inactive' is fully described in the input schema. The description does not add any additional meaning beyond the schema, so 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?

Clearly states the action ('list') and resource ('subscriptions'), and scopes to 'the caller's active subscriptions'. Distinguishes from sibling tools like subscribe and unsubscribe by implying listing for review before adding or finding id to cancel.

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

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

Explicitly advises when to use: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This implies not to use when intending to add or cancel directly, guiding the agent to the correct sibling 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?

Even though annotations provide no hints (all false), the description adds substantial behavioral context: it explains the claim_token flow (filing returns a token, which can be reused to read status), rate limiting (5/day), cost (free, not quota), and privacy guidance ('don't paste the end-user's prompt'). This goes well beyond annotation signals and is not contradictory.

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

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

The description is long but information-dense; every sentence contributes: purpose, usage triggers, exclusions, claim-token behavior, rate limit, and cost. It is front-loaded with the core action. Minor redundancy exists (e.g., 'Pipeworx tool names are the ones this connection lists' could be tighter), but nothing is wasted.

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

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

For a tool with no output schema, the description covers key workflows: filing feedback, retrieving status via claim_token, and rate limits. It does not describe the exact response structure beyond the token, but the provided information is sufficient for a typical agent to use the tool correctly. A 4 reflects the absence of an explicit output schema description while acknowledging the token explanation.

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 all four parameters well. The description adds value by explaining the claim_token lifecycle ('Filing without an account returns a `claim_token`; pass it back later... to read whether it was fixed'), which gives extra semantic context not fully captured in the schema. The example invocation also clarifies usage, so a 4 is warranted.

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 action and target: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this from sibling tools like ask_pipeworx, focusing on feedback rather than inquiry. The enumerated feedback types (bug, feature/data_gap, praise) further clarify scope.

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

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

Provides explicit when-to-use scenarios: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a clear exclusion: 'if the tool came from a different MCP server... file it with that server instead,' and a disambiguation note about Pipeworx tool names. This surpasses basic guidance by naming the alternative action.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds caching window (5min-1h), data source (CF analytics-engine), and no PII. 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?

Three sentences plus bullet points, front-loaded with output. 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?

Tool has one optional parameter, no output schema but return values are described (top tools, packs, volume). Caching and behavior fully explained. Complete for a simple trending 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 describes window enum with coverage 100%. Description adds context that shorter windows show 'hot right now' and longer show 'steady-state demand', adding 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?

Clearly states it returns top tools, top packs, and total call volume. Uses specific verbs and distinguishes from siblings like 'discover_tools' and 'ask_pipeworx'.

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

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

Lists three explicit use cases (discovering hot sources, confirming canonical tools, aligning use cases). Does not explicitly name alternatives or state when not to use, but the context is clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, which are consistent with a scanning tool. The description adds extensive behavioral context: monotonicity violation checks, partition-sum logic, semantic anchor with Jaccard similarity, partition filter for placeholder slugs, fill check against live CLOB depth, and what to do if realizable_edge_pp ≤ 0. This goes well beyond the annotations.

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

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

The description is well-structured with clear sections for modes, semantic anchor, partition filter, response, and fill check. It is front-loaded with the core purpose and usage modes. However, it is somewhat lengthy (approx. 250 words) and could be slightly more concise without losing key details.

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

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

Given the tool's complexity (two modes, internal checks, fill validation), the description covers most essential aspects. It describes the response fields (opportunities[], partition_check) and behavior for each mode. However, it lacks details on error handling (e.g., invalid event slug) and does not specify exact field types in the response. The absence of an output schema is partially compensated.

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 substantial meaning: it explains that 'event' triggers single-event mode walking child markets and performing axis ordering and partition checks, while 'topic' triggers cross-event scanning with Jaccard similarity filtering. It also describes the response structure for each mode and the fill check 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: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It specifies the verb (find), resource (arbitrage opportunities), and mechanism. It distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection through specific mathematical checks.

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 guidelines: 'Call with NO args for a trending_scan... pass event for... pass topic for...' It explains when to use each mode, recommends event mode for specific markets, and contrasts cross-event mode's ability to catch patterns missed by single-event mode. It also advises against trading when fill check shows zero realizable edge and points to 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 indicate safe read-only, idempotent behavior. The description adds extensive details: caching policy, segment computation, edge calculation, knobs, diagnostics, and exclusion of Fed bets. 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 comprehensive but verbose, with heavy technical detail that could be streamlined. It front-loads the purpose but includes model specifics that may be excessive for many agents.

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

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

Without an output schema, the description fully details the response structure (by_segment, fed_candidates, diagnostics) and explains key fields like edge_pp_net and kelly_fraction, making it complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by grouping knobs (e.g., 'TRADEABLE-EDGE KNOBS') and explaining their role in filtering, which goes beyond individual 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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, targeting 'what should I bet on today'. It distinguishes from siblings like polymarket_arbitrage by focusing on discrepancy detection rather than cross-platform arbitrage.

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

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

The description provides context for use (daily bet discovery) and explains the three segments and their applicability. However, it does not explicitly state when not to use or mention alternatives for other tasks.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds detailed behavioral context: response structure (tracked, expired, snapshot_dates), field meanings (trend, decay_pp_per_day), and data source caveats (daily closes, cache-miss triggers).

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: purpose first, then response fields with clear labels, then limitations. However, it is somewhat verbose; a few sentences could be tightened without losing meaning.

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 the response structure (tracked, expired, snapshot_dates) with field details. It also covers limitations and data source behavior, making it self-sufficient for an agent to understand what to expect.

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

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

Schema descriptions cover 100% of parameters. The description adds default values (14 days, '1wk'), clamp for days (max 30), and explicitly lists window families (24hr, 1wk, 1mo) which are not enumerated in the schema. This adds significant semantic value.

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

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

The description clearly states it provides edge persistence and decay telemetry from daily snapshots, answering a specific question about edge longevity. It contrasts fresh vs. old edges, distinguishing it from the sibling tool '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?

The description explicitly tells when to use the tool (to assess edge persistence and decay) and provides limitations (60-day TTL, daily closes). It implies not for intraday analysis, but doesn't explicitly state when not to use vs. 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?

In addition to annotations (readOnlyHint, etc.), the description details internal behavior: walks the order book, computes VWAP, slippage, verdict. For basket mode, explains theoretical vs realizable sums, capture ratio, and risks like forced directional position and partial fill threats.

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

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

Well-structured with clear sections (SINGLE-MARKET, BASKET) and bold labels, but slightly verbose. Every sentence adds value, but could be trimmed further 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?

No output schema, but the description enumerates all returned fields for both modes, including edge cases like thin_legs, forced_directional_risk, and max_clean_notional_usd. Covers what the tool does not do (capture overround on thin books).

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 context: e.g., for `size_usd` explains interpretation differs between single-market (spend/proceeds) and basket (settlement notional). Provides default and clamp values 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 checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes between single-market and basket modes. It explicitly differentiates from sibling tools like 'polymarket_arbitrage' by advising to use this before acting on arb signals.

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

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

Explicitly says 'REQUIRES one of `market` or `event`' and describes when each mode applies. Provides concrete advice: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'.

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

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

The description extensively details behavioral traits beyond annotations, including compatibility_warning conditions, temporal_alignment, skipped cross-type/subtype counters, and the limitation that pre-mapped topics are often untradeable. No contradiction with annotations (readOnly, openWorld, idempotent).

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 summary, mode breakdown, response details, and safety field explanations. While slightly verbose, each sentence serves a purpose. It is front-loaded with the core purpose.

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

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

Given the tool's complexity (two modes, multiple safety checks, no output schema), the description thoroughly covers input semantics, response structure, edge cases, and behavioral caveats. Users have enough information to understand when and why results may be valid or not.

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

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

The schema covers all three parameters with descriptions. The description adds significant value by explaining the interaction between topic and explicit parameters, providing example values, and describing the two operational modes. This goes beyond what the schema alone provides.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edges by focusing specifically on inter-venue spread 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 guidance on when to use each of the two modes (topic vs. explicit) and warns that most pre-mapped topics return compatibility warnings. However, it does not explicitly direct users to alternative tools (e.g., polymarket_edges for single-venue data) when this tool is inappropriate.

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 the behavioral trait of a cell-count limit and clarifies that the POST request is effectively a query, providing context beyond annotations.

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

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

The description is two sentences, front-loaded with purpose, and each sentence provides essential information without redundancy.

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

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

The description covers the body format and key constraint (cell-count limit). It lacks details about the response structure beyond format, but the output format is stated. For a tool with no output schema, this is adequate.

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

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

Schema coverage is 100% and the description does not add additional meaning to the parameters beyond what the schema already specifies. The description restates the body format but does not explain individual fields.

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

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

The description clearly states the action ('POST a PxWeb query'), the resource ('MakStat table'), and the output format ('json-stat2'). It distinguishes from sibling tools like table_meta, which likely provides metadata.

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 narrowing dimension values using codes from table_meta and warns about the cell-count limit. It implies a prerequisite but does not explicitly state when to use or avoid this tool.

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

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

Annotations already show readOnlyHint, idempotentHint, destructiveHint. Description adds scope (scoped to identifier) and listing behavior, enhancing transparency 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?

Concise 4-5 sentence description with front-loaded purpose, no fluff. Well-structured and 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?

Covers core behavior, usage, and scoping. Return format not specified but no output schema exists; overall complete for a simple retrieval tool.

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

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

Schema covers the key parameter with description 'omit to list all keys'. Description reinforces this and provides concrete usage examples, adding value beyond schema.

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

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

The description clearly states the tool retrieves a saved value or lists all keys. It gives concrete examples (ticker, address, notes) and distinguishes from sibling tools 'remember' and 'forget'.

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

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

Provides clear context for when to use (look up stored context) and mentions alternatives (remember, forget). Lacks explicit 'when not to use' but still strong 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 readOnly, openWorld, idempotent, and non-destructive. Description adds value by detailing return fields (source, citation_uri, raw payload), the effect of mark_read (only newer events on next call), and that polling is acceptable. Does not cover pagination or rate limits, but still informative.

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

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

Well-structured with clear hierarchy: purpose, return details, filter options, behavior note, and alternative access. Every sentence adds value; no fluff. Slightly longer than strictly necessary, but still concise.

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

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

Given no output schema, description adequately explains return fields (source, citation_uri, payload) and behaviors (mark_read, polling). All 5 parameters are addressed in schema and description. Missing edge cases like what happens with limit exceeded, but overall sufficient for an agent.

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

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

Schema provides descriptions for all 5 parameters (100% coverage). Description reinforces with examples ('sec_8k' for type, ISO format for since) and explains the mark_read behavior, adding substantial 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?

Clearly states 'Pull fired events from your subscription feed' with specific verb and resource. Mentions alternative access via GET endpoint, but doesn't explicitly differentiate from sibling tools like list_subscriptions, so not a perfect 5.

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 that polling works fine and mentions alternative script access, but lacks explicit when-to-use vs other tools (e.g., when to choose this over list_subscriptions). No exclusions or alternatives to sibling tools given.

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

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

Annotations already declare safety (readOnlyHint, idempotentHint, destructiveHint false). Description adds valuable behavioral context: fans out to multiple sources, fallback logic, soft-fail for USPTO, and output format (structured changes[] with citations). No contradiction.

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

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

Description is packed with information but end-to-end efficient. Front-loads examples. Every sentence adds value. Could be slightly more structured (e.g., bullet points), but remains concise overall.

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 moderately complex tool (multiple sources, fallback, date parsing), the description is complete. Covers behavior, input formats, fallback logic, output structure, and sibling differentiation. No output schema, but description adequately describes return 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 coverage is 100%, but description adds semantics: explains `since` accepts ISO or relative shorthand with examples, suggests '30d' or '1m' for typical monitoring, and clarifies `value` can be ticker or zero-padded CIK.

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

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

Description clearly states the tool retrieves a change feed (SEC filings, news, patents) for a company in a recent time window, using specific verbs like 'fans out'. It explicitly distinguishes from sibling tool entity_profile (static profile vs. dynamic changes).

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: when to use (e.g., 'What's new with X') and when not to ('Use entity_profile instead when you want the static profile...'). Also details fallback behavior (GDELT→GNews) and acceptable date formats.

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 behavioral traits beyond annotations: scoping by identifier, persistence differences for authenticated vs. anonymous users (24-hour retention). Annotations provide idempotentHint=true and destructiveHint=false, which are consistent and complemented by this context.

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

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

Well-structured and concise: front-loaded with purpose, then usage, behavior, and pairing. 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 simple two-parameter tool with full schema and no output schema, the description covers purpose, usage, behavior (persistence, scoping), and pairing with siblings, making it fully complete for agent understanding.

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

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

Schema coverage is 100% with adequate descriptions for key and value. Description adds context about storing key-value pairs and gives examples in usage guidelines, elevating semantics beyond mere schema definitions. Not a 5 because no additional parameter-specific details beyond examples.

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

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

The description clearly states the tool saves data for later reuse across conversations or sessions, specifying the verb 'save' and resource 'data'. It distinguishes from siblings 'recall' and 'forget' by explicitly mentioning them.

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

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

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

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral details: graceful degradation when GLEIF/OpenFIGI are unavailable, explicit listing of unresolved identifiers under `unresolved`, internal cascading through multiple endpoints, and source labelling. These details align with the read-only nature and enhance predictability.

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: it opens with query examples, gives a usage rule, then details each supported type. Every sentence adds meaningful information, though some phrasing (e.g., 'cross-source identity spine') could be simplified. The front-loaded examples help quick comprehension.

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

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

With no output schema, the description thoroughly covers what to expect: it lists returned identifiers (CIK, ticker, LEI, FIGI, RxCUI, ingredient, brand), explains edge cases like unresolved identifiers and provider unavailability, and describes the internal cascade. This is complete enough for an agent to invoke the tool and interpret results without guessing.

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 provides 100% coverage with descriptions for both parameters, so baseline is 3. The tool description enriches this by explaining accepted input formats (ticker, CIK, ISIN, brand/generic names), the meaning of the type enum, and special behavior such as ISIN-to-LEI mapping for non-US issuers. This goes beyond the schema's basic property descriptions.

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

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

The description explicitly states the tool's function: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It provides specific query examples ('What's the ticker for...', 'find the CIK for...') and differentiates from siblings like entity_profile by framing it as the initial ID-lookup step. The supported types are clearly enumerated.

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 a clear directive: 'Use FIRST whenever you have a name but need an ID.' It also explains when each type (company/drug) is appropriate and notes the tool replaces multiple manual lookups. However, it does not explicitly mention when not to use the tool or name alternative tools for non-ID-related queries.

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 that it probes each entity with ai_visibility_check, ranks results, and returns a ranked list with score, confidence, signal density per entity. 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?

Four sentences, each contributing unique information. Front-loaded with primary action. No fluff.

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

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

Given the 4 parameters and rich annotations, the description adequately explains functionality and output. Missing some detail on score interpretation but sufficient for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it merely restates the entities array purpose. No extra value.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using ai_visibility_check probes. It distinguishes from sibling tool ai_visibility_check which checks a single entity.

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

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

The description explicitly mentions competitive AI-marketing audits and implies usage when comparing multiple brands. It does not provide explicit when-not or alternative tools, but the context is clear given the sibling list.

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 behavior beyond annotations: fans out across deps.dev and bundlephobia, explains partial failures (bundlephobia first measurement can take 5-30s, sources_failed will list timeouts), and describes return fields in detail. 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 and front-loaded with the main purpose. While slightly long, every sentence adds value, covering usage, scope, output, and edge cases. No redundancy.

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

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

Despite no output schema, the description fully details the return structure: summary block fields, per-advisory detail, links, alternative versions, and error handling. Complete for a composite check tool.

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

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

Schema coverage is 100%, and the description adds context: scoped packages are accepted, version defaults to latest. This provides meaningful extra information without being verbose.

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

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

The description explicitly states it's a composite check for npm packages covering license, advisories, version history, and bundle size. It distinguishes from sibling tools by specifying the NPM ecosystem scope and noting that other ecosystems use deps.dev directly.

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?

Gives clear guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also advises that for PyPI/Maven/Cargo/Go, users should use deps.dev:version directly, providing explicit when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds behavioral details: uses BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation flag. No contradiction.

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

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

Concise, front-loaded with purpose, every sentence adds value. No wasted words. Structure is clear and easy to parse.

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

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

Despite no output schema, description explains what is returned (top-N passages with offsets and scores). Also covers embedding model, windowing, character limit. Complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds example queries for the 'query' parameter and explains truncation for 'text', but most parameter semantics are already 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?

Description clearly states it performs semantic search inside a fetched record, with concrete examples (SEC 10-K, article). Distinguishes from sibling ask_pipeworx_grounded by noting it is used when the record is too large and pairs with that tool.

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: use when record is too big to fit in prompt, saves context. Mentions pairing with ask_pipeworx_grounded as alternative, but does not explicitly state when not to use. Still, usage context is clear.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by explaining the response structure (folder/table list) and path behavior, which are not evident from annotations alone. No contradiction.

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

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

The description is concise with two sentences, each serving a purpose: explaining the tool's scope and providing usage instructions. 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?

Given that there is no output schema, the description adequately explains the return format (folder/table list with types). The tool is simple, and the description covers navigation and expected output for a browsing 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 has 100% description coverage for the single 'path' parameter, and the description repeats the same information. While examples are helpful, the parameter semantics are fully defined by the schema, so the description adds minimal new meaning.

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

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

The description clearly states the tool's purpose: to browse the MakStat subject tree. It specifies the verb 'browse' and the resource 'subject tree' and distinguishes this tool from others by detailing the hierarchical structure (folders vs tables) and navigation.

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: empty path for root, sub-paths to drill down. It explains the returned data types ('l' for folders, 't' for tables) and how to reach tables. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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

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

The description adds significant behavioral context beyond annotations, including OAuth requirement, supported types with parameter examples, delivery channel specifics (SMS cap, webhook signing secret, auto-disable), and the fact that it returns a subscription ID.

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 purpose first, then requirements, types, and delivery, but it is somewhat verbose. However, every sentence adds value, and the structure aids readability.

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

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

The description covers prerequisites, all supported types with parameters, delivery options with constraints, return value, and edge cases (webhook auto-disable). It is highly complete given the absence of an output schema.

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

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

Despite 100% schema coverage, the description provides detailed explanations and examples for each parameter, such as type-specific formats and delivery constraints, adding substantial 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 creates a proactive monitoring subscription and returns a subscription ID, distinguishing itself from sibling tools like 'unsubscribe' and 'list_subscriptions'.

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

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

The description explicitly mentions the requirement for a Pipeworx OAuth account and provides examples of when to use the tool for different subscription types and delivery channels. It does not explicitly state when not to use it, but the context with sibling tools offers implicit 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, openWorldHint, idempotentHint, and destructiveHint (false). The description adds useful behavioral context: it returns example questions drawn from a live catalog, and it's an onboarding tool. 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 relatively long but well-structured. It starts with natural language triggers, then explains output and usage in separate sentences. Every sentence adds value, though it could be slightly more concise.

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

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

For a simple tool with no output schema and one optional parameter, the description is complete. It explains the output format, usage scenarios, and source of examples. It covers all necessary context for an AI 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?

Schema description coverage is 100% for the single optional parameter. The description adds value by listing possible topic values (finance, pharma, etc.) and explaining that omitting topic gives a cross-category spread. This goes beyond the schema's description.

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

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

The description clearly states this is the onboarding entry point for an agent to ask about Pipeworx's capabilities. It lists multiple natural language triggers and explains it returns category-bucketed example questions with tool call shapes. It distinguishes from sibling tools like ask_pipeworx and entity_profile by positioning it as the first tool to use when the agent doesn't know what Pipeworx can do.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Provides guidance on when to pass a topic vs. omit it. Does not explicitly list alternatives, but the context makes it clear that this is for exploration before using specific tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds specific output details (dimensions with codes and value lists) and path constraints, enhancing transparency 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?

Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.

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

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

Given single parameter, full schema coverage, strong annotations, and no output schema, description fully covers what the agent needs: input format, output content, and how to use it with sibling tool.

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

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

Schema coverage is 100%, but description adds crucial meaning: clarifies path format (must end in '.px') and provides an example, which schema's brief description lacks.

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

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

Clearly states verb ('Fetch') and resource ('dimension definitions and valid coded values for a MakStat PxWeb table'). Specifies path requirement and relationship to sibling 'query_table', distinguishing it effectively.

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 mentions that output is used to build selection body for 'query_table', providing clear context. Lacks explicit 'when-not-to-use' but implied by purpose.

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

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

Beyond annotations (which are minimal), the description discloses key behavioral traits: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts.' This adds value and 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?

Two concise sentences, front-loaded with the core purpose, no extraneous information. 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?

Given one required parameter and no output schema, the description adequately covers purpose, ownership enforcement, side effects, and reference to historical data. It is complete for this tool.

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

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

Schema coverage is 100% and parameter 'id' is described. The description adds ownership context but does not enhance parameter semantics beyond what the schema provides.

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

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

The description clearly states 'Cancel a subscription by id,' specifying the action and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by using the verb 'cancel' and referencing subscription 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?

It explicitly says 'Ownership is enforced — you can only cancel your own subscriptions,' providing clear when-to-use guidance. It does not explicitly name alternatives, but the context of siblings implies when not to use it (e.g., for others' subscriptions).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description enriches these by detailing the two pipeline paths (SEC structured vs grounded), enumerating the exact verdict categories, and clearly distinguishing 'could_not_verify' (which does not count as evidence) from 'unsupported'. It also explains the inclusion of citations and reasoning, going far beyond annotations.

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

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

The description is relatively long, but every section serves a purpose—invocation examples, scope, routing, output, and error semantics. It's front-loaded with natural-language patterns and well-structured, but the density of information makes it slightly less concise than ideal.

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

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

With no output schema, the description appropriately explains return values (verdict, actual value, citation, reasoning) and edge cases like could_not_verify and unsupported. It covers the main use cases and the distinction between financial and generic claims. Minor gaps exist (e.g., exact response format, how to present the result to users), but overall it's quite complete for a complex tool.

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

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

The input schema already fully describes both parameters (100% coverage). The description adds meaningful context for tolerance_pct with specific guidance (e.g., 'set 1–2 for hallucination detection') and explains how the default is derived from claim wording. This goes beyond the schema, though not extensively for the claim parameter itself.

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

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

The description clearly defines the tool as a natural-language claim verification service against authoritative sources, with explicit verb ('verify', 'fact check') and specific resource ('claims'). It distinguishes itself from sibling tools by focusing on claim verification and noting it replaces multi-step sequential calls, making its purpose unmistakable.

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

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

The description explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It further differentiates between company-financial claims and other facts, routing accordingly. It also mentions it replaces 4-6 sequential calls, implying efficiency, but does not explicitly name alternative tools to avoid, making it slightly less than a 5.

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