Treasury Fiscal

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

Annotations already declare it read-only, idempotent, and non-destructive. The description adds useful behavioral context: default model is free, Anthropic requires a user-provided API key, and returns per-model and combined results. 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?

Four sentences, no fluff. The main action is front-loaded, and every sentence provides distinct information (purpose, defaults, use cases, return structure). Efficient and well-structured.

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

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

Given no output schema, the description adequately covers return format (per-model and combined). It explains optional parameters and use cases. However, it lacks details on error handling or rate limits, which are minor gaps for a read-only tool.

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

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

Schema coverage is 100% with descriptive parameter text. The description adds value by explaining the default model, the role of _apiKey (passed directly), and how context disambiguates entities. Clearly enhances understanding beyond the schema.

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

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

The description clearly states the tool probes LLMs for brand visibility and scores it 0-100, specifying the default model. It does not explicitly differentiate from siblings like ask_pipeworx, but the purpose is distinct enough for an AI agent to infer its unique role.

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

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

The description lists concrete use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It does not include explicit when-not-to-use instructions or alternatives, but the provided contexts are sufficient for most agent decisions.

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 annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false) already cover the key behavioral traits. The description adds valuable transparency about what the tool does with the question: it routes to one of 5,798 tools, fills arguments, returns a structured answer with pipeworx:// citation URIs. This gives the agent a clear mental model of the answer format and provenance, which the annotations alone don't convey.

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

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

The description is long but earns its length: it leads with the strongest instruction ('PREFER OVER WEB SEARCH'), then enumerates domains, explains mechanism, gives trigger phrases and examples, and closes with routing to alternatives. Every sentence adds decision-relevant information. The structure is front-loaded with the most important guidance.

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

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

Given the tool's complexity — 5,798 tools, 1,517 sources, six parameter aliases — the description is remarkably complete. It covers domain scope, trigger phrases, examples, output format (structured answer with citation URIs), and alternative routing. The only minor omission is pagination/result-limit details, but this is a routing tool that returns an answer rather than a list, so that is not required. The schema covers all parameter semantics, and there is no output schema to conflict with.

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 adds context by explaining that the parameter is a natural-language question, and provides three realistic examples. It goes beyond the schema by indicating the question can be any factual query, not just a formal API parameter. A 4 is justified because the description makes it clear that the question is flexible and covers a broad domain.

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 is exceptionally specific: it names the verb (route/answer), the resource (5,798 tools across 1,517 verified sources), and the scope (current or historical structured data with citations). It clearly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research, and provides concrete examples that define its domain.

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

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

The description gives explicit when-to-use guidance ('PREFER OVER WEB SEARCH... Use whenever the user asks...'), provides trigger phrases and examples, and explicitly states when to use alternatives ('use ask_pipeworx_grounded' for hallucination-resistant answers, 'use deep_research' for broad multi-part questions). This is comprehensive routing 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?

Beyond the annotations, the description reveals the experimental nature, live candidate improvements, current no-active-candidate state, and the comparison process against the stable router. It also explicitly states there is no fallback — 'this IS a full working router' — which fully discloses behavioral expectations.

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

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

The description is longer than average but every part contributes: beta status, exact relationship to ask_pipeworx, current state, usage, and behavior. The date and internal comparison detail are slightly granular but help explain the current match to the stable version, so there is no notable waste.

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

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

For a tool with a single required string parameter and rich annotations, the description is largely complete: it explains what it is, how to use it, its current state, and its output relationship to ask_pipeworx. Since there is no output schema, the only minor gap is that the response shape is referenced relative to ask_pipeworx rather than described directly, but for an agent with sibling context that 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?

The input schema already documents all six parameters with 100% coverage, including the five aliases for 'question'. The description does not add parameter-specific detail beyond saying the tool accepts the same arguments as ask_pipeworx, so the 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 identifies this as a beta version of ask_pipeworx and a universal router handling the same 5,798 tools with the same arguments and response shape. It distinguishes itself from the stable ask_pipeworx via the phrase 'when you want the newest routing' and confirms it is a full working router, so an agent can tell when to invoke it.

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

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

It provides explicit usage guidance: 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router. It implies the alternative is ask_pipeworx for stable routing and notes that no candidate is active right now, so the current behavior matches the stable version — strong when/when-not information.

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 significantly expands on the annotations by disclosing the refusal mechanism, exact success and failure return shapes, refusal reasons, and the constraint that it uses ONLY the tool result. No contradiction with the readOnly, idempotent, openWorld, or non-destructive hints is present.

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

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

The description is dense but every sentence earns its place: core behavior, return contract, use cases, and cost tradeoff. It is front-loaded with the most decision-relevant information and does not waste words.

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

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

With no output schema, the description fully compensates by specifying both success and refusal return structures, refusal reason enum values, and the conditions under which refusals occur. It also provides cost and alternative guidance, making the tool fully actionable 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 coverage is 100% and the sole real parameter, question, is fully documented along with aliases. The description adds no parameter-specific guidance, but the schema carries the full burden, so the baseline of 3 is appropriate.

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

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

The description opens with a specific value proposition ('Hallucination-resistant answer mode for high-stakes reads') and clearly differentiates from sibling ask_pipeworx by explaining the same routing but stricter evidence-based extraction. It states exactly what the tool does: route, fetch, extract using only tool result, and return grounded answer or refusal.

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 whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with concrete domain examples. It also names the alternative: 'prefer ask_pipeworx for casual lookups,' including the tradeoff of one extra LLM call.

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

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

The description is extremely transparent, detailing fan-out logic, classifier categories, response structure, resolver contract (confidence levels, alternatives), parent event extraction, news fallbacks, safety short-circuits, spread warnings, and cancellation rule parsing. Annotations already indicate non-destructive read-only behavior, and the description adds rich behavioral context without contradiction.

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

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

While the description is quite long, it is well-organized with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.) and every sentence adds necessary detail for a complex tool. A slight reduction in verbosity could improve conciseness, but it remains structurally 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 the lack of an output schema, the description thoroughly explains the response shape (result.market, result.analysis, result.evidence, resolver contract, parent event, news fields). It covers edge cases (low confidence, closed markets, wide spreads, cancellation rules) making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with all three parameters described in detail. The description adds examples (slug, URL, question text) and functional explanations for `depth` and `include_raw`, making the parameter semantics clearer than the schema alone.

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

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

The description immediately states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It provides specific use cases and examples, and clearly differentiates from siblings by focusing on single-bet deep research rather than scanning edges or arbitrage.

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

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

Explicitly states when to use: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also provides extensive behavioral context (classifiers, fan-out examples, response shapes) that helps the agent decide when this tool is appropriate versus alternatives.

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

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

Annotations already mark it as read-only, non-destructive, idempotent, and open-world. The description adds specific behavioral details: for companies it pulls latest 10-K financials with correct fiscal-year handling (e.g., AAPL Sep, NVDA Jan), and for drugs it pulls FAERS, FDA, and trial counts. Results are sorted by primary metric. 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 front-loaded with trigger phrases and efficiently packs information. It's slightly dense but not verbose. Every sentence adds value, though it could be slightly more streamlined without losing clarity.

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

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

Given two parameters and no output schema, the description fully explains input, behavior, and output (paired data + pipeworx:// citation URIs). It also notes efficiency (replaces 8–15 sequential lookups) and sorting behavior, making it self-contained.

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

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

Schema coverage is 100% with clear descriptions. The description further enriches parameter meaning: explains how 'type' determines data source (SEC EDGAR vs. FAERS) and how 'values' accept tickers/CIKs or drug names. Examples like '["AAPL","MSFT"]' and '["ozempic","mounjaro"]' clarify usage.

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

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

The description starts with trigger phrases like 'Compare X and Y' and clearly states it performs 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' It distinguishes the tool from sequential single-entity lookups (e.g., entity_profile) by emphasizing parallel batch processing.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' giving clear when-to-use guidance. It also provides example queries and specifies entity types (company/drug) with concrete data sources.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds substantial runtime behavior: account/auth tiers, parallel facet routing, gap[] recovery, contradictions[] scanning, never-invented evidence, fetchable citations, semantic excerpting of large records, and latency expectations. No statement contradicts 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 long but densely packed and front-loaded with the most operationally critical constraint: account requirement and the alternative tool. The structural flow from auth to scope to output packet to timing makes it navigable, though the depth behavior is partially repeated between schema and prose, keeping it from a perfect score.

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 present, the description carries the full burden of explaining return values, and it does so thoroughly: findings packet contents, per-finding citation_uri and hop field, gaps[], contradictions[], and expected latency. The description gives an agent everything needed to select, invoke, and interpret this 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%, so the description does not need to document parameters from scratch, but it still adds meaning by explaining what each depth level implies in terms of hops, gap recovery, and contradiction scanning. It also reinforces that 'question' is meant for broad, multi-part natural-language queries, going beyond the schema's minimal 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?

States a specific action — grounded multi-source research over 1,517 structured data sources in one call — and clearly distinguishes itself from open-web search and single-lookup tools like ask_pipeworx. The description also explains the decomposition-and-parallel-routing mechanics and the findings packet, making the tool's function concrete and unambiguous.

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

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

Explicitly names ask_pipeworx as the fallback when not signed in, and identifies single-lookup questions as cases where deep_research is not the right tool. It also gives positive selection criteria: broad/multi-part questions over structured data, with concrete examples.

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

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

Annotations already declare safe read-only, idempotent, non-destructive behavior. The description adds valuable detail: returns top-N tools with full schemas and examples, ready to call directly. No contradictions; behavioral traits are well-covered.

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 purposeful: purpose, usage guidance, return format, and invocation strategy. No redundancy; information is front-loaded and scannable.

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 simple discovery function, the description fully explains what it does, when to use it, and what it returns (top tools with schemas). No missing gaps for effective use.

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

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

Schema coverage is 100% and the description adds minimal extra beyond acknowledging aliases, which are already in the schema. Baseline 3 is appropriate as 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 clearly states the verb 'Find' and resource 'tools', explicitly listing domains (SEC filings, financials, etc.) and distinguishing it from specific sibling tools. It is a discovery meta-tool, not a data-retrieval 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?

The description advises to 'Call this FIRST when you have many tools available and want to see the option set', providing clear context for when to use. It does not explicitly list when not to use or alternatives, but the directive is strong enough for proper 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 mark the tool read-only, idempotent, and non-destructive; the description goes well beyond this by disclosing parallel fan-out across sources, soft-failure for the USPTO API sunset, empty sections meaning real 'no data' rather than bugs, and resolved:false behavior for private companies. This is precisely the kind of behavioral context that an agent needs and that structured fields cannot convey.

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

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

The description is long, but it is densely informative and front-loaded with canonical user-phrase examples before diving into return fields and edge cases. Almost every sentence carries a distinct fact — source list, output-shape details, failure semantics, or input formats — so the length is justified despite minor redundancy with the schema's type/value descriptions.

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 high complexity, broad multi-source behavior, and lack of an output schema, the description thoroughly covers inputs, return sections, source failure semantics, expected empty results, and private-company handling. No critical calling information appears missing for an agent to correctly select and invoke 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%, so the baseline is 3, but the description adds meaningful semantics: examples for ticker vs CIK vs name, the note that names now resolve via SEC EDGAR's company-name match, and the explicit statement that 'type' accepts both values interchangeably. These details go beyond the schema's terse 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 identifies a specific verb and resource: building a 'full cross-source profile of a US public company in ONE parallel call' from natural-language prompts like 'tell me about X' or 'research Acme.' It distinguishes itself from chaining single-pack lookups and from nearby siblings such as resolve_entity or compare_entities by framing its unique holistic 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?

Explicit guidance is given: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also spells out what inputs are accepted (ticker, CIK, name), how names resolve, and what happens for private companies — turning the instructions into actionable selection criteria.

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

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

Description adds minimal context beyond annotations: states delete action (consistent with destructiveHint=true) and data sensitivity. Annotations already cover destructive nature and idempotency. 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?

Three sentences, no redundancy. First sentence gives action, second provides usage context, third relates to sibling tools. 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?

For a simple delete tool with one parameter, the description sufficiently covers purpose, usage, and relationships. Could mention behavior when key doesn't exist, but not necessary given simplicity. Adequately 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?

Only one parameter ('key') with full schema coverage (100%). Description in schema already says 'Memory key to delete'. Description adds no new semantic info beyond what schema provides. Baseline 3 is appropriate.

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

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

Description clearly states 'Delete a previously stored memory by key' – a specific verb + resource + method. Differentiates from sibling tools '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?

Provides clear use cases: 'when context is stale, the task is done, or you want to clear sensitive data'. Also suggests pairing with 'remember' and 'recall', implying alternative tools. Lacks explicit when-not-to-use.

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

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

Describes the process: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' Annotations already indicate read-only and non-destructive; description adds context about external fetching and output format without 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: first states purpose, second details process, third lists use cases. No redundant information; each 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?

For a 2-parameter tool without output schema, the description covers operation, output format, and use cases. Annotations provide safety profile; 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 has 100% description coverage. Description adds example URL format and default for max_links, slightly enhancing understanding beyond the schema.

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

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

Clearly states the tool generates an llms.txt file for any URL, specifying the verb (generate), resource (llms.txt), and scope (any URL). Distinguishes from siblings like scan_competitor_ai_presence by focusing on file generation rather than scanning.

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 explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor's AI visibility. Provides clear context but does not mention when not to use it or offer sibling 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 readOnly, idempotent, and non-destructive hints. The description adds value by specifying the return fields and the default behavior for the include_inactive parameter. No contradictions.

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

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

Two concise sentences: the first clearly states the action and return fields, the second provides usage guidance. No unnecessary words.

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

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

For a simple tool with one optional parameter and no output schema, the description fully covers the purpose, return fields, usage context, and parameter behavior.

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

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

Schema description coverage is 100% for the single parameter. The description mentions 'default false' which is already in the schema. No additional semantic value 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 starts with 'List the caller's active subscriptions,' which is a clear verb-resource pair. It also lists the return fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

The description explicitly states when to use: 'to review what you're monitoring before adding more or to find an id to cancel.' This provides clear context, though it does not mention specific alternatives.

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

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

Despite annotations being all false, the description richly discloses behavioral traits: filing without an account returns a claim_token, rate-limited to 5 per identifier per day, free and not counted against tool-call quota, and processed by a human team. It clearly explains the claim_token flow for later retrieval. No contradiction with annotations is present.

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

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

The description is long but every sentence carries unique information: usage cases, exclusions, token behavior, rate limits, and best practices. It is front-loaded with the core purpose and then expands logically. 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?

For a feedback tool with nested context, enums, and no output schema, the description covers all necessary operational details: what triggers the tool, how to construct feedback, what the claim_token is for, and what happens after filing. It fully compensates for the absence of an output schema by explaining the returned token.

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

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

Schema description coverage is 100%, so the schema already explains each parameter. The description adds cross-parameter semantics, such as how the claim_token should be passed back ('pipeworx_feedback({claim_token:"pwfb_…"})') and the instruction not to paste end-user prompts into message. This goes beyond schema but the schema still carries most of the load.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb ('Tell') and names the resource (Pipeworx team), and it clearly distinguishes itself from sibling tools by centering on feedback rather than research, queries, or actions.

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 for bugs, feature requests, data gaps, or praise. It also includes a clear exclusion: only for tools served by this Pipeworx connection, with a directive to file elsewhere for other MCP servers. This is far beyond typical usage 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?

Adds detail beyond annotations: self-aggregating from CF analytics-engine, no PII, caching behavior (5min-1h). Annotations already declare readOnlyHint, openWorldHint, etc., and description aligns.

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?

Efficient, front-loaded with core purpose, then enumerated use cases and technical notes. Every sentence adds value; no filler.

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

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

Fully describes inputs (window) and outputs (top tools, packs, volume). Missing output schema is fine given the description. Annotations cover safety. Tool is simple and well-documented.

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 already has full description for window enum. Description adds practical guidance on window interpretation (hot vs steady-state). Enhances without redundancy.

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

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

Clear verb and resource: 'Returns the top tools, top packs, and total call volume'. Distinguishes from siblings by focusing on trending usage data from other AI agents.

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 lists three use cases and explains window duration trade-offs. No explicit when-not-to-use but context is strong.

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 tool as read-only and idempotent. Description adds rich behavioral context: monotonicity checks, partition sums, semantic anchor for cross-event, partition filter for placeholders, fill check against live CLOB depth. No contradiction with annotations.

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

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

Description is longer than ideal but well-organized: front-loaded with purpose, then mode-by-mode explanation. Every sentence adds value, though some details (e.g., semantic anchor specifics) could be slightly condensed 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?

Despite no output schema, description fully documents response structure including opportunities array and partition_check object. Covers edge cases like fill check, placeholders, low similarity. For a complex tool, it is complete and leaves no major 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% with descriptions, baseline is 3. Description adds substantial meaning: for event parameter, explains it walks child markets and runs specific checks; for topic, explains cross-event scanning and similarity threshold. Goes far 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?

Description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by focusing specifically on arbitrage. The two modes (event and topic) are clearly explained, making the purpose highly specific and actionable.

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

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

Provides explicit guidance on when to use each mode: no args for trending scan, event for specific market, topic for cross-event scanning. Also tells when not to use (e.g., when fill check shows realizable edge ≤ 0, do not trade). Points to sibling tool polymarket_fill_risk for custom sizing, offering clear alternatives.

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

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

The description goes beyond the readOnlyHint and idempotentHint annotations by disclosing caching behavior (1h KV-level), response structure with _diagnostics, and detailed segment logic. 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 excessively long and dense with implementation details that could be moved to documentation. While it is front-loaded with the main purpose, it lacks conciseness for quick agent scanning.

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

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

Given the tool's complexity (9 parameters, no output schema, nested _diagnostics), the description thoroughly covers response structure, segment definitions, caching, and parameter effects. It compensates for the missing output schema by explicitly describing the return fields and diagnostics.

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

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

The input schema already provides comprehensive descriptions for all 9 parameters (100% coverage). The tool description adds some context (e.g., 'Tradeable-edge filter' for min_liquidity and max_spread_pp) but does not significantly improve semantic understanding beyond the schema's own descriptions.

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

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

The description clearly states the tool scans Polymarket markets to return opportunities where Pipeworx data disagrees with market price, targeting the 'what should I bet on today' use case. It also distinguishes itself from sibling tools by focusing on edge detection with specific segments.

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

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

The description provides clear context for when to use the tool (for discovering opportunities without paging hundreds of markets) and explains the response segments and knobs. However, it does not explicitly state when not to use it or compare to alternatives like polymarket_arbitrage or polymarket_edge_tracker.

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

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

Annotations already indicate read-only, non-destructive behavior. The description adds important behavioral details: 60-day snapshot TTL, decay computed from daily closes (not intraday), snapshot gaps meaning no scan that day. It also outlines the response structure (tracked, expired, snapshot_dates) 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 somewhat lengthy but well-structured: purpose, response detail, limits. Each sentence adds value, though minor redundancy exists (e.g., explaining decay computation twice). Front-loading works well with the core question answered early.

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 the response (tracked, expired, snapshot_dates) and their fields. Parameters are fully covered. Annotations provide safety guarantees. The description also addresses limits (TTL, decay computation) and provides practical context (competition clock via median lifespan).

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

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

Schema coverage is 100% for both parameters, but description adds context: days has default 14 and clamp 2-30 (aligned with schema), window explains it's a snapshot family with examples ('24hr | 1wk | 1mo'). The description also clarifies how these parameters affect the response (e.g., lookback determines history depth).

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes its value from sibling tools like polymarket_edges by focusing on time-series analysis.

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

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

The description explains when to use this tool: to differentiate between fresh and old edges, noting that a 3-week-old wide edge is fundamentally different. While it does not explicitly list alternatives or when not to use, the context is clear enough for an agent to decide.

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

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

Annotations already indicate idempotent, read-only, non-destructive behavior. The description adds detailed behavioral context: it walks the order book ladder, returns specific metrics (top_of_book, vwap_fill_price, slippage_pp, etc.), and warns that partial basket fills convert arbitrage into unhedged directional positions. No contradiction with annotations.

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

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

The description is well-structured with clear sections (REQUIRES, SINGLE-MARKET, BASKET) and front-loaded key information. However, it is somewhat dense and could be slightly more concise without losing critical details. Still, given the tool's complexity, it earns a 4.

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

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

The tool has no output schema, so the description must explain return values. It lists all returned fields for both modes (top_of_book, vwap, slippage, verdict, etc. for single-market; theoretical_sum, capture_ratio, thin_legs, forced_directional_risk for basket). It covers edge cases (thin_legs, maximum clean notional) and explains the dominant loss mode. 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 description coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the difference between market and event mode, how size_usd is interpreted in each mode (spend vs target proceeds vs settlement notional), and defaults. It also notes clamping behavior. This adds value beyond the schema, hence 4.

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

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

The description clearly states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes, and explicitly positions itself as a pre-check for polymarket_arbitrage and polymarket_edges tools.

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

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

The description gives explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains the risks of partial fills and unhedged positions, helping the agent decide when to invoke the tool.

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

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

Annotations already establish a safe read-only/idempotent profile, and the description adds substantial behavioral disclosure beyond that: compatibility_warning and compatibility_codes can be non-empty even on returned pairs, the gross-vs-net fees_note caveat, skipped_unclassified handling, and the explicit statement that legs with unknown metric_type are never paired. This gives the agent an accurate mental model of the matcher's limitations.

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

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

The description is long, but it is densely packed with necessary caveats and safety disclosures, and it is structurally organized (modes → response → safety fields → codes → fees → caveats). A few phrases are repeated for emphasis (e.g., 'in EITHER mode'), but every paragraph earns its place given the tool's complexity.

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

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

With no output schema, the description carries the full burden of explaining the return value, and it does so thoroughly: leg-by-leg prices, top_spreads_pp, flags, temporal_alignment, skipped_unclassified, and the standing fee disclosure. Given three optional parameters and the tool's data-quality caveats, nothing an agent needs to correctly invoke and interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description enriches meaning by framing the parameters as two complementary modes, explaining that both modes run the identical token-overlap matcher, and clarifying that explicit ticker/slug override the topic-mapped side. This adds relational nuance beyond the schema's individual 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 opens by stating exactly what the tool does: cross-venue spread between Kalshi and Polymarket for the same resolving question. It adds concrete substance with the 2-25pp range and the equivalence caveat, clearly distinguishing this from a simple price fetch.

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 two-mode breakdown (topic shortcuts vs explicit pairings) gives clear usage context, and the closing warning that pre-mapped topics are not automatically tradeable acts as a helpful caution. However, it never explicitly contrasts this tool with sibling alternatives like polymarket_arbitrage or polymarket_edges, so it falls short of full when-to-use-vs-alternatives 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, idempotentHint, and destructiveHint. The description adds scoping details (anonymous IP, BYO key hash, or account ID) and the behavior of omitting the key argument. 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 sentences) and front-loaded with the main purpose. Every sentence adds value with no unnecessary 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 tool's simplicity, annotations cover safety, and the description provides clear instruction on usage. Even without an output schema, the return behavior (value or list) is implied sufficiently 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 coverage is 100%, and the description adds meaning by explaining that omitting the key lists all keys. This provides usage context beyond the schema's parameter description.

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

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

The description clearly states the tool retrieves a value saved via remember or lists all keys. It uses specific verbs and resources, and distinguishes from sibling tools like 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?

The description explains when to use the tool (to look up stored context without re-deriving) and implies alternatives (remember to save, forget to delete). It lacks explicit when-not-to-use but provides clear context.

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

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

The description adds behavioral context such as the mark_read parameter mutating read state and suitability for polling. However, it contradicts the annotations: readOnlyHint=true implies no side effects, but mark_read:true modifies persisted read status. This is a direct contradiction, warranting a score of 1 per the rules.

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 and well-structured. It starts with the core purpose, then describes return fields, filter options, a behavioral option (mark_read), and provides an alternative access method. Every sentence adds value without redundancy. The length is appropriate 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 that there is no output schema, the description adequately explains the return values (source, citation_uri, raw payload). It covers all parameters and their effects, and even mentions the alternative HTTP endpoint. For a read-oriented tool with optional mutation, this is complete and leaves no major 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?

Although the input schema covers all parameters with descriptions (100% coverage), the description adds valuable context beyond the schema. It explains the effect of mark_read, gives examples for type (e.g., 'sec_8k') and since (ISO timestamp), and describes the returned fields (source, citation_uri, raw payload). This enhances understanding beyond the raw schema.

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

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

The description clearly states the verb 'Pull' and the resource 'fired events from your subscription feed'. It distinguishes this tool from siblings like list_subscriptions (which lists subscriptions themselves) by focusing on alerts from the feed. The description also mentions specific returned fields and filter options, making the purpose unmistakable.

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

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

The description implies use when needing recent alerts from the subscription feed, and even notes that polling works fine and provides an alternative HTTP endpoint for scripts/dashboards. However, it does not explicitly state when not to use this tool or compare it to sibling tools like recall or search_within. The guidance is adequate but not comprehensive.

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 indicating safe read-only operation, description details multiple data sources (SEC, GDELT/GNews, USPTO), fallback behavior, date format acceptance, and return structure including citation URIs. 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?

Single paragraph front-loads purpose with user example queries, then efficiently covers sources, fallback, date formats, and return structure. Every sentence adds value with minimal redundancy.

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

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

Despite no output schema, description explains return format (changes[] grouped by source, total_changes, citation URIs) and covers edge cases like USPTO soft-fail and fallback behavior, making it fully self-contained.

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

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

Schema already describes all 3 parameters well (100% coverage). Description adds practical examples for 'since' (e.g., '7d', '30d') and clarifies that 'value' accepts ticker or CIK, providing extra utility beyond schema.

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

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

Description clearly states it provides a change feed for companies within a time window, using examples like 'what's new with X' and explicitly distinguishes from sibling tool entity_profile for static profiles.

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

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

Explicitly tells when to use (for recent changes queries) and when not (use entity_profile for static profiles), and suggests typical monitoring window '30d'.

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 provide idempotentHint=true but no persistence info; description adds scoping by identifier, persistence per authentication status, and 24-hour retention for anonymous sessions, going 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?

Concise and front-loaded with purpose, but could be slightly more structured (e.g., bullet points for examples) without losing information.

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

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

No output schema needed; description explains storage behavior, scope, and related tools, making it complete for a simple key-value store tool.

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

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

Schema covers both parameters; description adds example keys and value type context, but does not list specific valid key naming conventions 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 uses a specific verb 'Save' and resource 'data the agent will need to reuse later', clearly distinguishing it from sibling tools like recall and forget.

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

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

Explicitly states when to use ('when you discover something worth carrying forward'), provides examples, and directs pairing with recall/forget.

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, the description discloses important behavior: it cascades through multiple lookup endpoints, degrades gracefully if GLEIF or OpenFIGI is unavailable, returns figi_candidates rather than asserting an ambiguous match, and explicitly reports unresolved identifiers. It also states it replaces 2-3 manual lookups. 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 every sentence adds operational value, but it is presented as one long narrative paragraph without headings or bullets, which makes it harder to scan. It would benefit from structuring the supported types and edge cases as a list.

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?

There is no output schema, but the description compensates thoroughly: it explains what a successful company lookup returns, what an ambiguous FIGI match returns, and what unresolved identifiers look like. It also covers both types, all accepted inputs, and failure/degradation behavior, making the definition effectively self-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?

Even though the schema already documents both parameters at 100% coverage, the description adds crucial operational semantics: pass only the entity name, never the full noun phrase; bond lookups should use the issuer exactly as printed; and accepted company inputs include ticker, CIK, ISIN, or name. This goes well beyond the schema's 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 resolves user-spoken names to canonical/official identifiers, with concrete examples (ticker, CIK, LEI, RxCUI) and an explicit SUPPORTED TYPES section. This distinguishes it from sibling tools that operate on already-resolved entities or profiles.

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

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

It explicitly says 'Use FIRST whenever you have a name but need an ID' and enumerates several query phrasings that trigger this tool. However, it does not explicitly name sibling tools as alternatives or state when not to use it, so it stops short of full when/when-not 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=true, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds valuable context: each entity is probed via ai_visibility_check, results are ranked by score, and output includes score, confidence, signal density. No contradictions with annotations.

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

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

Four sentences with clear front-loading of purpose, followed by method and usage. No wasted words; 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?

The tool has 4 parameters, calls another tool internally, and has no output schema. The description adequately covers functionality, input interpretation, and output format. Missing details on error handling or rate limits, but annotations partially cover safety.

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 extra meaning: first entity is the subject, rest are competitors; context parameter disambiguates names. This goes beyond schema field 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 compares AI visibility across multiple entities side-by-side, with a specific verb (compare), resource (AI visibility), and scope (multiple entities). It distinguishes from sibling ai_visibility_check which does single probes.

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

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

Explicit usage context is given: 'Useful for competitive AI-marketing audits' with an example. It mentions the underlying probe tool (ai_visibility_check) but does not explicitly state when not to use or provide alternative tool names for single-entity checks.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds significant context beyond annotations: it fans out to two external services, mentions that Bundlephobia's first measurement can take 5-30 seconds, and explains how partial failures are reflected (sources_failed list). 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 long sentence with multiple clauses, making it somewhat dense and harder to parse quickly. While it front-loads the core purpose, breaking it into shorter sentences or bullet points would improve readability. Information is all present but not optimally structured.

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

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

Despite lacking an output schema, the description covers the essential return fields (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable, per-advisory detail, links, recent alternative versions). It also addresses failure modes (sources_failed) and ecosystem limitations, making the tool's behavior fully understandable for an AI agent.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds value by clarifying that 'package' accepts scoped names (e.g., @types/node) and that 'version' defaults to the latest published version. It also summarizes the return shape (summary block, per-advisory detail, links, alternative versions), which goes beyond the schema.

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

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

The description clearly states it performs a composite check for npm packages, covering license, advisories, version history, and bundle size. It distinguishes itself from sibling tools by explicitly naming the use case and the specific data sources (deps.dev and bundlephobia), leaving no ambiguity about its purpose.

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

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

The description explicitly tells when to use it: whenever an agent asks about safety, popularity, size, or cost of an npm package. It also specifies limitations (NPM ecosystem only in v1, other ecosystems to be handled via deps.dev:version directly) and mentions graceful degradation for partial failures. This provides clear usage boundaries and alternatives.

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

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

Discloses embedding model (BGE-base-en), chunking (500-char overlapping windows), character cap (200K chars), truncation behavior, and return fields (passages with offsets and similarity scores)—all beyond annotation hints.

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 dense sentences, front-loaded with purpose, every sentence adds value—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?

Lacks output schema but describes return type adequately; usage guidelines and parameter details make it sufficient for agent invocation.

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

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

Schema has 100% coverage, but description adds examples for 'query', defaults for 'limit', and clarifies 'text' max length and truncation, exceeding baseline.

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

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

The description clearly states 'Semantic search INSIDE a fetched record' with concrete examples (SEC 10-K body, article) and distinguishes from sibling tools like ask_pipeworx_grounded.

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

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

Provides explicit when-to-use ('record too big to cram into the prompt'), explains benefits (saves context, returns only relevant passages with offsets for verification), and pairs with a sibling for grounding.

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 idempotent and non-destructive. The description adds behavioral context: account requirement, returns subscription ID, delivery constraints (phone verification, rate limits, webhook auto-disable). No contradictions with annotations.

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

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

The description is dense with information yet well-structured: purpose, requirements, types with examples, delivery channels. Every sentence adds value with no redundancy.

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

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

For a tool with no output schema and complex parameters, the description covers account prerequisites, all supported types with parameter examples, delivery options with limitations, and return value. It is comprehensive.

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 significant value by providing type-specific examples (e.g., 'items:["5.02"]') and delivery channel constraints (e.g., webhook HMAC signing).

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 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This is a specific verb-resource pair and differentiates from sibling tools like list_subscriptions and unsubscribe.

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

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

It specifies account requirements ('Requires a Pipeworx OAuth account') and which authentication methods are incompatible. Supported types and delivery channels are detailed, but no explicit when-not-to-use or alternatives are 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 readOnlyHint, idempotentHint, etc. The description adds details: call with no arguments for full spread, or pass topic to focus. It also reveals that returns include tool+argument shape from the live catalog. Adds useful behavioral 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 a single paragraph but well-front-loaded with trigger phrases and concise. It covers all necessary information without redundancy, though it could be slightly more structured (e.g., bullet points) for clarity.

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

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

Despite no output schema, the description thoroughly explains what is returned: category-bucketed example questions with exact tool+argument shape. Mentions that it draws from a live catalog of thousands of tools. No gaps for this 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 covers the single optional parameter with a description listing topic options. The description clarifies that omitting the topic returns the full spread and passing a topic focuses the results. Adds examples and usage context beyond the schema.

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

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

The description clearly states the tool's purpose: it is the onboarding entry point that returns category-bucketed example questions with exact tool calls. It distinguishes itself from siblings by being a meta-tool for discovering what to ask.

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

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

Explicitly advises to 'Use this FIRST' when unsure about capabilities, and mentions learning how to call meta-tools. Provides example trigger phrases and guidance on optionally focusing by topic.

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, providing strong safety and idempotency guarantees. The description adds that it returns 'recent monthly records,' which aligns with annotations but doesn't add substantial new behavioral info beyond the structured fields.

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

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

Two sentences efficiently convey the tool's purpose, data source, and output characteristics. No unnecessary words, and key information is front-loaded.

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

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

For a simple tool with one optional parameter and strong annotations, the description is largely complete. It specifies the dataset and periodicity. While it lacks output field details, the tool's simplicity and self-explanatory nature mitigate this gap.

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 has 100% coverage for the single parameter 'limit' with a clear description. The description adds value by indicating records are monthly, so the limit parameter logically refers to number of months, enhancing understanding beyond the schema.

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

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

Description clearly states the tool provides average interest rates on US Treasury securities by specific types (bills, notes, bonds, TIPS, total marketable/non-marketable) from a named dataset. It distinguishes itself from other treasury tools (e.g., treasury_debt, treasury_receipts) by focusing on interest rates and specifying the source.

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

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

The description implies usage when average interest rates are needed and mentions 'recent monthly records,' giving context. However, it does not explicitly state when not to use it or mention alternative tools for related data, but the purpose is clear enough for basic 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. The description adds minimal behavioral context (monthly data, tariff trends) but 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 sentences with no wasted words; front-loaded with the core purpose and return value.

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

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

Given the simple tool with one parameter, comprehensive annotations, and an output schema, the description sufficiently covers the tool's behavior and return value.

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

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

Schema coverage is 100% and already defines the 'limit' parameter with its description and default. The main description does not add further parameter details, so 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 the tool tracks monthly US customs duty revenue and returns collection amounts, which distinguishes it from sibling treasury tools like treasury_debt or treasury_exchange_rates.

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

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

The description implies usage for analyzing tariff impact trends but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools.

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

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

Annotations already declare readOperation, idempotent, non-destructive. Description adds context about returning historical data points, which is mildly helpful but adds little beyond what annotations and schema imply.

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

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

Single sentence that front-loads the purpose. Every word is functional; no unnecessary detail.

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

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

Given the tool's simplicity, annotations, and presence of an output schema, the description is sufficiently complete. It explains the return value and historical nature, though no mention of date ranges or edge cases.

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

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

Schema coverage is 100% with clear description for the 'limit' parameter. Description does not add any additional meaning or constraints beyond the schema, meeting the baseline for full coverage.

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

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

Description clearly states verb 'check' and resource 'US national debt' with historical data points. The tool name and context distinguish it from sibling treasury tools, but no explicit differentiation is provided.

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

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

No guidance on when to use this tool versus alternatives such as treasury_avg_interest_rates or treasury_receipts. Lacks any when-to-use or when-not-to-use information.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'government currency conversions' context and the dual-mode behavior, but does not disclose any additional behavioral details (e.g., rate limits, response format, or errors). Given the annotations, the description's value is moderate, so a 3 is fair.

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

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

Two sentences with no filler. The purpose is front-loaded, followed by the two usage modes. Every word contributes to clarity, making this an exemplary concise definition.

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

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

The tool is simple (2 optional params, 0 required), and the schema covers both parameters thoroughly. The output schema exists, so return values need no description. The description covers the primary use cases and is complete given the annotations and schema, leaving no gaps for correct invocation.

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

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

Schema description coverage is 100%, with detailed explanations for both parameters. The country field is especially well-documented with aliases and the no-US-row note. The description repeats the 'omit for all countries' guidance already in the schema, adding minimal extra value. With high schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('official US Treasury exchange rates') with the purpose ('used for government currency conversions'). It clearly distinguishes this from other treasury tools (interest rates, debt, etc.) by focusing on exchange rates, and the two invocation modes (with/without country) are explicitly described.

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

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

The description clearly explains when to pass a country name versus omit it for all countries, which is the core usage guidance. However, it does not explicitly compare against sibling tools (e.g., treasury_avg_interest_rates), leaving the agent to infer which tool to choose. Still, the purpose is so specific that usage is largely self-evident, so a 4 is appropriate.

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, destructiveHint=false, idempotentHint=true, so safety and idempotency are clear. The description adds context about returning 'recent records' and the dataset name, but does not disclose any behavioral traits beyond what annotations provide.

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

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

The description is a single, well-structured sentence that conveys the tool's purpose immediately. Every word is meaningful and front-loaded.

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

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

Despite no output schema, the description explains the key fields returned (gross cost, earned revenue, net cost) and the dataset. For a simple read tool with two optional parameters, this provides sufficient context.

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

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

Schema coverage is 100%, so the schema already describes both parameters (limit and fiscal_year). The description mentions optional fiscal_year filtering, but adds no additional 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?

Description clearly states the tool returns US federal government net cost by agency, listing the data fields (gross cost, earned revenue, net cost) and the dataset source. This distinguishes it from sibling treasury tools focused on other metrics like interest rates or receipts.

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

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

The description implicitly suggests using this tool for net cost data by agency, but does not explicitly state when to use it versus alternatives like treasury_debt or treasury_receipts. No exclusions or prerequisites are provided.

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 true, so the agent knows it's safe and repeatable. The description adds that it returns receipts by source, but does not disclose any additional behavioral traits like pagination, data recency, or whether the 'limit' parameter caps results.

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

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

Single sentence, 17 words, front-loaded with the core action. Every word is necessary.

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

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

Given the tool's simplicity (one optional parameter, output schema exists), the description sufficiently explains what the tool does. It could mention the default limit or how data is ordered, but the output schema covers return values.

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

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

Schema coverage is 100% with the 'limit' parameter described. The description adds no parameter-specific meaning beyond what the schema already provides (default 12, records to return).

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

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

The description clearly states it retrieves US government receipts by source, listing specific examples (individual income tax, corporate tax, etc.). This differentiates it from sibling tools like treasury_customs_revenue or treasury_avg_interest_rates.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it covers overall receipts, but does not mention when to prefer it over sibling tools like treasury_debt or treasury_exchange_rates.

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 ownership enforcement and deactivation behavior ('row is deactivated, not deleted'), adding context beyond annotations. 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?

Three sentences, front-loaded with action ('Cancel a subscription by id'). No wasted words; all sentences add 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?

Complete for a simple tool with one parameter: action, ownership, and side effects covered. No output schema needed.

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

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

Schema has 100% coverage with 'id' description. Description adds value by specifying 'returned by subscribe', linking to sibling tool. Baseline 3 met and exceeded slightly.

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 'Cancel a subscription by id' with a specific verb and resource. It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by focusing on cancellation.

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 guidelines: ownership enforcement ('you can only cancel your own'). Implies when to use (when you want to cancel) and not to use (if you want deletion). Lacks explicit alternatives but sufficient 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 readOnly, openWorld, and idempotent hints. The description adds substantial behavioral context: the SEC/XBRL fast path vs grounded pipeline, exact percent-delta math, verdict meanings, and the critical distinction between could_not_verify and unsupported. This goes well beyond what annotations provide.

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

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

The description is dense and information-rich, with no redundancy. The opening quoted examples take space but clarify usage. It is occasionally verbose, but for a tool with no output schema, the length is justified and well-structured with clear sections.

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

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

With no output schema, the description fully explains return values: verdict types, actual value with citation, reasoning, and error states. It also covers edge cases (could_not_verify vs unsupported) and notes the efficiency gain over sequential calls, making the tool fully understandable in context.

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

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

The input schema already provides 100% coverage with detailed descriptions for both parameters, including tolerance_pct semantics and default behavior. The tool description itself adds no additional parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states that the tool verifies natural-language claims against authoritative sources, with explicit example phrasings like 'fact check' and 'verify the claim that...'. It distinguishes itself from sibling tools by focusing on claim verification with verdict output.

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

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

It provides explicit trigger phrases and states 'Use whenever the agent needs to check whether something a user said is factually correct.' It also distinguishes between company-financial and other factual claims with routing details. However, it does not name alternative tools or give explicit when-not-to-use guidance, so it falls short of a 5.

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