Nbu Ua

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

Annotations already cover safety (readOnlyHint, destructiveHint false). The description adds behavioral details: default model, optional Anthropic probing with BYO key, and return format (per-model score, confidence, signals, raw_response + combined view). 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 extremely concise: two sentences plus a brief note. It front-loads the purpose and efficiently covers all necessary information without redundancy.

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

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

Despite no output schema, the description fully explains the return format (per-model and combined view). It covers all essential aspects: what it does, how to use, parameter semantics, and output. No gaps for a tool of this complexity.

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

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

Schema coverage is 100%, so parameters are documented well. The description enriches this by explaining the default model, the need for _apiKey only for Anthropic, and the return structure. This adds significant value beyond the schema definitions.

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 'probe' and resource 'LLMs', and clarifies the output: 'score visibility (0-100) per model'. It also distinguishes from siblings by focusing on LLM knowledge about entities, contrasting with other research 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 provides explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring'. It does not explicitly state when not to use, but the context is clear. The default model and optional API key for Anthropic are explained, aiding selection.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond these hints: it routes to a specific tool, fills arguments, returns a structured answer with stable pipeworx:// citation URIs, works on every tier, and is a single fast call. 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 about 180 words but contains substantial actionable content: usage directive, mechanism, trigger phrases, examples, and alternative tool guidance. It is well-structured and front-loaded with the most critical recommendation ('PREFER OVER WEB SEARCH'). Minor redundancy exists (e.g., 'Use whenever' and 'START HERE' both convey default status), but not enough to detract significantly.

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 and lack of an output schema, the description covers essential context: the return format (structured answer with stable citation URIs), routing behavior, argument-filling, performance ('one fast call'), tier availability, and clear escalation paths to other tools. This makes the tool self-contained for an agent deciding whether to invoke it.

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

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

The input schema fully documents all 6 parameters, all as aliases for the 'question' string parameter, resulting in 100% schema coverage. The description provides example questions but does not add technical parameter semantics beyond what the schema already states. The baseline score of 3 applies when schema coverage is high and the description adds no additional parameter details.

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

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

The description clearly states the tool's function: it routes questions to one of 5,439 tools across 1,412 verified sources and returns structured answers with citation URIs. It also distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research by explicitly explaining when to use each, giving it a specific and unique 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 provides explicit guidance: 'PREFER OVER WEB SEARCH', lists trigger phrases ('what is', 'look up', 'find'), gives concrete examples, and outlines when to step up to alternatives ('for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'). It also clarifies that breaking news is already covered by this tool.

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

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

Beyond the annotations (read-only, idempotent), the description discloses that this is a fully working router ('Falls back to nothing — this IS a full working router') and that candidate routing improvements are enabled live when under test. It also reveals the current inactive state (no candidate active) and the exact date of retirement, adding meaningful behavioral context.

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

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

The description is five sentences and packs essential information about beta status, equivalence, current activity, usage guidance, and a caveat. It is front-loaded with the core purpose and uses every sentence meaningfully, though it could be trimmed slightly.

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

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

Given the tool is a router with no output schema, the description adequately explains its behavior, current status, and relationship to the stable router. It notes 'same response shape' as ask_pipeworx, which compensates for the missing output schema, and covers the experimental nature thoroughly.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter-level detail beyond stating the router accepts the same arguments as ask_pipeworx, which aligns with schema coverage. Thus, no extra value is provided.

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, a universal router for natural language queries with the same 5,439 tools. It distinguishes itself from sibling tools like ask_pipeworx (stable) and ask_pipeworx_grounded, making its specific role unambiguous.

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

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

The description gives explicit guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains that results are compared against the stable router, providing context for when this variant is preferred. However, it doesn't explicitly state when NOT to use it (e.g., when stability is critical), leaving some ambiguity.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive, but the description adds substantial behavioral context: exact return shape ({answer, evidence, confidence, source, fetched_at, refusal_reason}), explicit refusal reasons, the routing behavior ('Same routing as ask_pipeworx'), and the extra LLM call cost. No contradiction with annotations; it enhances them.

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, each with a distinct job: purpose, return contract, and usage/cost guidance. Front-loaded with the most important information, no filler or redundant restatement of name/schema. Efficient and 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 explicitly documents the full return contract including refusal reasons, which is critical for an agent to handle failures. It also covers routing, cost, and usage boundaries. Combined with rich annotations, the description is complete enough for safe and 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 coverage is 100% with all six parameters documented as aliases for the natural-language question. The description mentions 'fills arguments' but does not add new meaning beyond the schema's own description ('Your question in natural language. Accepts query, q, prompt, text, input as aliases'). Baseline 3 is appropriate.

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

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

The description opens with a specific, differentiated statement: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly states the action (EXTRACTS the answer using ONLY what the tool result contains) and distinguishes from ask_pipeworx by emphasizing grounding and refusal behavior, making sibling differentiation explicit.

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

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

Provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and when-not-to: 'prefer ask_pipeworx for casual lookups.' It also names the alternative (ask_pipeworx) and explains cost trade-off, making the selection criteria unambiguous.

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 safe, read-only, idempotent behavior. Description massively expands on this with details on fan-out parallelism, response structure, resolver contract (confidence, alternatives, suggestions), parent event extraction, news field fallbacks, safety short-circuits, closed market handling, illiquidity warnings, and resolution-rule risk. 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 very long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). Every sentence provides necessary detail for correct use. However, it could be condensed slightly without losing clarity.

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

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

Despite no output schema, the description thoroughly details the response shape (result.market, analysis, evidence, resolver contract, parent event, news fields). Covers edge cases like low-confidence matches, closed markets, wide spreads, and cancellation rules. For a complex tool with many internal operations, this is highly complete.

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

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

Schema coverage is 100% with good descriptions for each parameter. Description adds practical examples for 'market', clarifies defaults and behavior for 'depth' (quick vs thorough), and explains the 'include_raw' toggle's impact on response size and use cases. This adds significant value beyond the schema.

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

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

Description clearly states it researches a Polymarket bet using Pipeworx data, accepting various inputs. It distinguishes from sibling tools by specifying its unique function of resolving, classifying, fanning out, and returning evidence with comparison. Examples and use cases make 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?

Explicitly states when to use: for 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. Provides extensive examples of fan-out by category. Does not explicitly mention when not to use or alternatives, but the purpose and context are 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 the tool is read-only, open-world, idempotent, and not destructive. The description adds significant behavioral context: for companies, it pulls the latest 10-K data with correct handling of off-calendar fiscal years; for drugs, it pulls specific data types; results are sorted by primary metric so 'largest' reads off the top; returns paired data with citation URIs. These details go 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 concise (about 6 sentences) and front-loaded with common query patterns. Every sentence provides value: usage context, type-specific details, sorting behavior, and efficiency gain. No waste or redundancy.

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

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

Given the tool's complexity (two entity types with different data sources, multiple entities), the description is remarkably complete. It covers what each type retrieves, sorting, return format (paired data + citation URIs), and the efficiency benefit over sequential lookups. Even without an output schema, the description adequately explains what to expect.

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

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

The input schema already has 100% coverage with descriptions for both parameters. The description adds substantial meaning: it explains what 'type' does (company vs. drug), what 'values' should contain (tickers/CIKs for company, names for drug), and provides concrete examples (e.g., ['AAPL','MSFT']). This helps the agent understand parameter usage beyond the schema.

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

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

The description explicitly states that the tool performs side-by-side comparisons of 2-5 companies or drugs in a single parallel call. It provides specific verbs like 'compare', 'side-by-side comparison', and lists typical queries, clearly distinguishing it from sibling tools like entity_profile by stating it should be preferred over sequential single-pack lookups.

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

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

The description gives explicit guidance on when to use the tool: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also explains how to use it with example queries and what data each type retrieves (company: financials from SEC EDGAR/XBRL; drug: FAERS adverse-event counts, FDA approvals, trial counts). This makes it very clear when and how 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?

Given readOnlyHint=true, openWorldHint=true, and idempotentHint=true already disclosed, the description adds substantial context: parallel decomposition, evidence packet structure with gaps[], contradictions[], hop fields, citation URIs, semantic excerpting, timing expectations, and account-tier restrictions. No contradiction exists.

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

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

The description is long but every clause contributes unique operational or caveat information (e.g., account requirement, not for news, gap recovery, timing). It is front-loaded with the most critical constraint (account) and organized by function, distinctions, and behavior, though a slight trim could improve scannability.

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

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

With no output schema, the description thoroughly explains return artifacts (findings packet with verbatim evidence, source, fetched_at, citation, gaps[], contradictions[], hop field), performance expectations, and limitations (not open-web, empty gaps for uncatalogued topics). This is highly complete for a complex research tool.

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

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

Both parameters (question, depth) are fully documented in the schema (100% coverage), leaving little for the prose to add. The description does reiterate depth behavior and fee requirements, but it mostly mirrors the schema text rather than extending it—so baseline 3 is appropriate.

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

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

The description clearly states the tool performs 'grounded multi-source research' across Pipeworx's structured data sources, and it repeatedly differentiates itself from ask_pipeworx and open-web search. Specific examples ('compare X and Y's regulatory + financial exposure') and scope ('NOT open-web search') strongly establish 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?

Explicit when-to-use guidance is provided: 'Best for broad/multi-part questions over structured data', with direct exclusions for single lookups and breaking/current-news topics naming ask_pipeworx as the preferred alternative. It also covers account requirements and signals when to use a different tool if not signed in.

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=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail: returns top-N most relevant tools with full input schemas (with curated examples), ready to call directly without second lookup. No contradictions with annotations.

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

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

Description is reasonably concise with front-loaded purpose, domain list, return format, and usage recommendation. Every sentence contributes value, though slightly verbose in listing domains.

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

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

Despite no output schema, the description fully explains return type (top-N tools with names, descriptions, schemas, examples). It covers inputs (query and limit), behavior, and usage guidance, making the tool self-contained for an agent.

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

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

Schema description coverage is 100% (all 6 parameters documented). Description adds minimal extra value—it mentions alias acceptance but that is already in schema. Baseline 3 is appropriate as description does not significantly augment parameter understanding.

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

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

The description clearly states the tool finds tools by describing data or task, lists verb synonyms (browse, search, look up, discover), and enumerates specific domains (SEC filings, financials, etc.). It distinguishes from sibling tools by focusing on discovery rather than direct data retrieval.

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

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

Explicitly says 'use when you need to browse, search, look up, or discover what tools exist' and 'call this FIRST when you have many tools available and want to see the option set'. This provides clear usage context, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it fans out across multiple data sources, returns specific fields with details (e.g., patent API sunset May 2025, soft-fails), and explains the return structure. 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?

Description is moderately long but well-structured, front-loaded with example queries and key guidance. Every sentence adds value, though slightly verbose in listing all return fields individually.

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 (multisource, multiple return categories) and lack of output schema, the description thoroughly explains what the tool returns (CIK, filings with URIs, fundamentals, patents, news, LEI) and important nuances (patent sunset, name restriction, parallel call). Complete enough for an AI agent to use 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 descriptions for both parameters. The description goes further by providing concrete examples (e.g., 'AAPL', '0000320193'), clarifying that type is only 'company' currently, and noting that names are unsupported. This adds 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's purpose: providing a full cross-source profile of US public companies in one parallel call. It uses specific verbs and resources ('profile of a US public company', 'fans out across SEC EDGAR, XBRL, USPTO...') and distinguishes from sibling tools like resolve_entity by explicitly stating that names are not supported and directing users to the sibling tool.

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

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

Explicit guidance to prefer this tool over chaining single-pack lookups for holistic views. Also specifies that names are not supported and advises using resolve_entity first, clearly indicating when not to use this tool.

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

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

Annotations already flag destructive and idempotent behavior; description adds context about sensitive data but doesn't significantly extend what annotations provide.

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

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

Two sentences that are front-loaded with the core purpose and usage, with no wasted words.

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

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

Sufficient for a simple tool with one parameter and no output schema; covers when to use and pairing hints.

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

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

Schema coverage is 100% and parameter description is clear; the tool description does not add 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?

The description clearly states the verb 'delete' and resource 'memory by key', distinguishing it from siblings remember and recall.

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

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

Explicitly states when to use (stale context, task done, clear sensitive data) and pairs with remember and recall, providing clear guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral detail: fetches page, extracts title/description/key links, emits standard markdown. No contradiction with annotations. Could mention rate limits or caching, but overall sufficient.

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

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

Single, well-structured paragraph. First sentence states main action and purpose, then explains process and outputs, finally lists use cases. No unnecessary words; 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?

Tool has 2 parameters, no output schema, and comprehensive annotations. Description covers purpose, process, output format, and use cases. No missing information; 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 covers both parameters with full descriptions (100% coverage). Description repeats the default and max for 'max_links' (already in schema). For 'url', description nearly matches schema. Little added value beyond schema, so baseline 3.

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 generates an llms.txt file for a given URL, with specific verb 'generate' and resource 'llms.txt file'. It provides use cases (client site, own project, competitor audit) that distinguish it from sibling tools like 'scan_competitor_ai_presence' and 'ai_visibility_check'.

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 useful scenarios (getting a client's site indexed, drafting for own project, auditing competitors). While it does not state when not to use or name alternatives, the context of siblings and the clear purpose make usage guidance clear.

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

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

Description adds value beyond annotations by listing exact return fields. Annotations already declare readOnly, idempotent, non-destructive. No contradictions.

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

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

Two sentences: first for purpose, second for usage. No redundant words. 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?

No output schema, but description lists return fields. Covers purpose, usage, and includes return metadata. For a simple list tool, this is adequate.

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

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

Schema coverage is 100% and describes the single optional parameter. Description does not explicitly explain the parameter's effect beyond the schema, but the baseline is 3.

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 'List the caller's active subscriptions', specifying the verb (List), resource (subscriptions), and scope (caller's active). Distinguishes 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?

Provides explicit usage context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Does not specify when to avoid, but gives clear scenarios for 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?

Annotations declare readOnly, openWorld, idempotent, and non-destructive. Description adds valuable behavioral details: returns one record per business day, field formats (e.g., exchangedate in DD.MM.YYYY), ordering (newest first). No contradictions with annotations.

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

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

Two sentences plus a list of fields. Every sentence is informative. Front-loaded with purpose. No verbosity or redundancy.

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

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

Given the input schema (3 params, 2 required) and no output schema, the description fully covers the return structure. The simplicity of the tool means this is complete for an agent to use 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 has 100% coverage with descriptions, but the description further clarifies with examples (e.g., YYYYMMDD format, ISO-4217 codes) and details the returned fields. Provides examples in the schema. Adds significant value beyond bare 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 daily time series for one currency (or all) over a date range, with specific verb and resource. It distinguishes from siblings like nbu_currency_rate by noting the time series aspect and the option to omit valcode for all currencies.

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

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

Explicitly says to pass valcode for a single currency or omit for all, with start/end in YYYYMMDD format. Provides examples in the schema. Does not explicitly state when not to use, but the context is clear enough for the agent.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds useful context (rate is UAH per 1 unit, omitting date gives today's rate) without repeating annotations. This adds value but annotations already cover safety aspects.

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, concise and front-loaded with purpose. No unnecessary words. Every sentence adds useful information.

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

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

Complete for a simple lookup tool. Covers usage, parameters, alternative, and return value semantics (UAH per unit). No output schema but enough context 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% (both parameters described). The description adds meaning: explains date can be omitted for today, valcode should be ISO-4217 code, and clarifies rate units. This adds value beyond the schema.

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

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

Description clearly states it provides the 'Official NBU rate for a SINGLE currency on one day', specifying the verb (query) and resource (currency rate). It distinguishes from the sibling tool nbu_currency_history.

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

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

Explicitly says when to use this tool (single currency, one day) and when to use the alternative (nbu_currency_history for time series). Provides parameter hints like omitting date for today and using ISO-4217 code for valcode.

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 value beyond annotations by describing the output structure (fields and examples). Annotations already indicate read-only, idempotent behavior. Could detail error handling for invalid dates, but still good.

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, zero filler. Front-loaded with purpose and output. Second sentence provides critical usage hint. Every word earns its place.

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

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

Given no output schema, the description fully specifies the return structure. Annotations cover safety, idempotency. Input behavior is clearly explained. Complete for a simple 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 covers 100% with format description. The description adds behavioral semantics: omitting date gives today's rates. This complements the schema 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?

Clearly states it fetches official NBU exchange rates for ALL currencies on a single day, distinguishing it from siblings like nbu_currency_rate (single currency) or nbu_currency_history (historical data). The verb 'fetch' is implied by context.

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: 'Omit date for today's rates.' This tells the agent when to use the default vs. specify a date. Does not explicitly exclude other tools, but the sibling list makes alternatives available.

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 no destruction. Description adds value by detailing the record fields (dt, txt, txten, id_api, value, freq) and date semantics, complementing annotations effectively.

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 plus a record format note. Every sentence is necessary and efficient. No redundancy or fluff.

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

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

Covers all core aspects: what data, how to filter by date, output structure. Lacks mention of error cases or monthly granularity, but adequate for a simple read tool with complete annotations.

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

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

Schema covers 100% of parameters. Description adds meaningful context: the date parameter selects a reference month and omitting gives the latest month. This clarifies behavior beyond the schema's description.

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

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

The description clearly states it retrieves NBU international reserves for a given month, broken down by component, with a record structure. It is distinct from sibling NBU tools (currency rates, history, etc.) but does not explicitly differentiate them.

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

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

Provides clear guidance on the date parameter (selects month, omit for latest). No explicit guidance on when to use vs. alternative tools, though resource name implies context. Minimal comparative usage advice.

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. The description adds useful behavioral context: the record format (dt, txt, txten, id_api, value, freq) and the fact that omitting date returns latest. No contradictions.

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

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

The description is a single, well-structured paragraph with all essential information. It is front-loaded with the main purpose and contains no fluff.

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

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

Given no output schema, the description adequately describes the return records. It covers the parameter and what to expect. No mention of errors or limits, but for a simple read-only tool it's sufficient.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that 'date' selects the reference month (any day in it) and omitting gives latest. This adds value.

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

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

The description clearly states it retrieves NBU monetary aggregates (M0, M1, M2, M3 money supply) for a given month, with a specific record structure. It distinguishes from sibling tools like nbu_currency_history and nbu_exchange_rates by focusing on monetary aggregates.

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 explains when to use the date parameter (reference month) and that omitting it gives the latest available month. While it doesn't explicitly list alternatives, the sibling tools have distinct purposes, so the usage is clear.

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

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

Annotations are all neutral (false), so the description carries the burden. It adds meaningful behavioral context: rate-limited to 5 per identifier per day, free (doesn't count against tool-call quota), and that the team reads digests daily. This goes beyond what annotations provide and helps the agent set 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 a typical tool description, but every sentence earns its place: use cases, exclusions, message guidance, rate limits, and quota impact. It's front-loaded with the core purpose and well organized, making it dense but not wasteful.

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

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

For a 3-param tool with an enum, nested object, and no output schema, the description covers all essential decision points: what types of feedback to submit, which tools are in scope, what to avoid pasting, rate limits, and quota effects. It is fully self-contained for an agent to decide whether and how to call 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 baseline is 3. The description adds semantic guidance beyond the schema, such as 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt.' This clarifies how to fill the message parameter and what context is meaningful, which is valuable.

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 'Tell the Pipeworx team something is broken, missing, or needs to exist' — a specific verb + resource with clear scope. It also distinguishes from siblings by framing the tool as a reporting channel for Pipeworx-specific tools, which is unique among the sibling list.

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

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

Explicit when-to-use scenarios are listed (bug, feature/data_gap, praise) with concrete examples like 'wrong/stale data' and 'tool you wish existed isn't in the catalog.' It also provides a clear when-not-to-use rule: if the tool comes from a different MCP server, file with that server instead. This fully orients the agent.

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

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

Annotations already indicate safe read-only behavior. The description adds valuable context: self-aggregating signal, source (CF analytics-engine), no PII, caching intervals. No contradiction with annotations.

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

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

The description is concise with three clear sentences, front-loaded with the key result. Every sentence adds value without redundancy.

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

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

Despite no output schema, the description explains what is returned (top tools, packs, volume). With one optional parameter, it fully covers the tool's 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 coverage is 100% with enum and description. The description adds meaningful guidance on window choice: short windows for hot trends, longer for steady-state demand, enhancing the schema.

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

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

The description clearly states the tool returns top tools, packs, and call volume over a recent window. It distinguishes itself from siblings like 'discover_tools' by focusing on what other AI agents are calling, making it unique.

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

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

Three specific use cases are listed (discovering hot data, confirming canonical choice, checking alignment). While no explicit 'when not to use' is given, the use cases are clear and helpful.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint true, destructiveHint false. The description adds significant behavioral context: scans top 200 markets, walks child markets, applies Jaccard threshold, partition placeholder filtering, and fill check against CLOB depth. No contradictions.

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

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

The description is thorough but somewhat lengthy. Information is front-loaded (purpose first) and logically structured. Minor redundancy in explaining modes, but every part earns its place given complexity.

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

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

Given the tool's complexity (three modes, filters, fill checks) and lack of output schema, the description covers all necessary information: response structure, error cases (skipped_low_similarity, placeholders_filtered), and when not to trade. No gaps.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains event slugs ('fed-decision-may-2026'), topic seed questions, and the detailed behavior of each mode, enabling correct parameter selection.

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 identifies arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes (no-args trending scan, event, topic) and explains what each does, differentiating it from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicit guidance on when to use each mode: no-args for trending scan, event for specific market, topic for cross-event scan. Includes when not to trade (realizable_edge_pp <= 0) and recommends polymarket_fill_risk for custom sizing, providing 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 far beyond the annotations by disclosing caching behavior (1h KV cache keyed on knobs), response structure (by_segment with diagnostics), model details (e.g., FRED log-returns, GDELT ratio, partition_overround with sport-specific α), and edge calculation details. It also warns about unreliable Fed signals and explains knobs like min_kelly, min_edge_pp, and slippage. This is highly transparent.

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

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

The description is long but well-structured, front-loading the core purpose, then detailing model families, response fields, knobs, and diagnostics. Every sentence carries essential information for such a complex tool. While could be slightly more concise, the density is justified given the tool's sophistication, and the structure aids readability.

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

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

Given the tool's complexity, lack of an output schema, and rich parameters, the description is highly complete. It explains the entire response structure (by_segment, fed_candidates, diagnostics), the models behind each segment, the caching policy, and the tradeable-edge knobs. An agent can fully understand what the tool returns and how to interpret it without additional context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by providing context and rationale for each parameter beyond the schema descriptions. For example, min_liquidity is explained as dropping opportunities where edge execution would walk the book, and min_partition_leg_kelly is clarified for partition arbs vs single-leg. This 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 starts with a specific verb+resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It clearly identifies the tool's purpose and distinguishes it from sibling tools by detailing the model families, response segments, and knobs. Sibling tools like polymarket_arbitrage or polymarket_fill_risk have different focuses, and this description makes the unique purpose evident.

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

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

The description states it is 'Built for "what should I bet on today"' and implies use for discovering opportunities without paging through markets. However, it does not explicitly mention when not to use it or compare directly with alternatives. While the context is clear, the lack of explicit exclusion criteria or alternative references keeps it from a perfect score.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about data limitations (60-day snapshot TTL, start from snapshot enablement) and computation method (daily closes, net of default slippage), which are beyond the annotations. It also details the response structure, enhancing transparency.

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

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

The description is fairly long but front-loaded with the core purpose. Every sentence adds value, covering response structure, examples, and limitations. It could be slightly more concise but is well-organized and avoids redundancy.

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

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

Given the tool's moderate complexity (2 parameters, no output schema), the description comprehensively explains the response fields (tracked, expired, snapshot_dates) and limitations (TTL, decay computation). It leaves no significant gaps for an agent to understand what the tool returns and how to interpret results.

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 parameter descriptions. The description repeats the parameter info ('days' lookback, 'window' snapshot family) without adding significant new meaning. It provides minor context ('snapshot family') but does not compensate for the high schema coverage.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It distinguishes from siblings like polymarket_edges by focusing on historical behavior ('how long has this edge existed and is it shrinking?') and specifically contrasts fresh vs. old wide edges, making its unique value evident.

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 when to use this tool (to assess edge longevity and decay) and contrasts with a fresh edge, but does not explicitly list alternatives or when not to use. Sibling tools are available, and the context is clear enough for an agent to infer appropriate usage.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. The description adds critical behavioral context: it walks the ladder, returns a verdict (clean|degraded|cannot_fill), and warns about forced directional risk and partial fills. This adds substantial value 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?

Every sentence earns its place, but the description is quite long and could benefit from breaking the two modes into separate sections or bullet points for easier parsing. However, critical information is front-loaded and the structure is logical.

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

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

Given the complexity (two modes, lack of output schema), the description is remarkably complete. It enumerates all return fields for both modes, explains default values and clamp ranges, and covers the dominant failure mode (stranded positions). No important behavioral or contextual detail is omitted.

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

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

Schema coverage is 100% and the description adds significant meaning beyond the schema. It explains the two operating modes (market vs event), how size_usd is interpreted differently (max spend on buys, target proceeds on sells for single-market; settlement notional for basket), and the default side detection for basket mode ('auto — sell if partition sum > 1, buy if < 1').

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 and resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes with explicit return fields for each. It also tells the agent why this tool exists (to prevent unhedged directional risk), differentiating it from siblings like polymarket_arbitrage.

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

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

The description explicitly instructs: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It further explains the consequence of not using it ('partial basket fills convert an arb into an unhedged directional position'), providing clear when-to and why-to 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 readOnly/openWorld/idempotent. Description adds behavioral details: response structure, safety fields (compatibility_warning, temporal_alignment), and counter fields explaining why comparisons are skipped. 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?

Long but front-loaded with purpose. Every sentence adds value; however, could be split into sections or condensed slightly 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, but description fully explains return values (leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). Covers all edge cases and meaning of warnings.

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 at 100% coverage with parameter descriptions. Description adds meaning by listing all topic values, explaining override logic, and giving example formats for explicit parameters. Provides context beyond schema.

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

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

Clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question. Specifically distinguishes from siblings like polymarket_arbitrage by focusing on multi-venue comparison.

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

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

Explicitly describes two usage modes (topic shortcuts and explicit tickers) and warns when to distrust results (compatibility_warning, temporal_alignment false). States that real spreads are rarer than shortcuts suggest.

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 convey read-only, idempotent, non-destructive nature. The description adds scoping and pairing context, 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?

Three concise, front-loaded sentences with no waste; each sentence adds meaningful context.

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

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

Complete for a simple tool with one optional param and rich annotations; explains return behavior, scoping, and relationships with siblings.

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

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

Schema provides full description (100% coverage) and description of the key param matches schema; the tool description adds no new semantics beyond the schema's param 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, using specific verbs and distinguishing from siblings (remember, 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 advises when to use the tool (to look up stored context) and mentions alternatives (remember for save, forget for delete), along with scoping details.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by explaining the effect of mark_read (flags events as read), the return fields, and that polling is safe. It 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?

Four sentences, each packed with useful information. The description is front-loaded with purpose and concise, avoiding fluff. Every sentence earns its place.

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

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

Given no output schema, the description adequately explains return fields and parameter behavior. It covers all parameters, polling suitability, and even provides an alternative access method, making the tool self-contained and easy to 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%, but the description goes beyond by explaining how to use parameters: e.g., 'Filter by type ... and/or since (ISO timestamp)' and 'Set mark_read:true to flag returned events read.' This adds practical context to the raw schema definitions.

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: 'Pull fired events from your subscription feed.' It specifies what is returned (source, citation_uri, raw payload) and differentiates from siblings like 'list_subscriptions' by focusing on subscription feed alerts.

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 filtering by type and ISO timestamp, setting mark_read to acknowledge events, and notes that polling works fine. It also mentions an alternative endpoint (GET alerts.json) for scripts/dashboards, giving clear context for when to use this tool over other methods.

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

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

Annotations already indicate safe read operations (readOnlyHint, idempotent, non-destructive). The description adds important behavioral details: fan-out to multiple sources, fallback from GDELT to GNews, soft-fail for USPTO, and response structure (changes grouped by source, total_changes count, 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?

The description is well-structured, starting with example queries and then detailing sources and parameters. It is slightly long but each sentence adds value. Could be tightened slightly.

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

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

The description covers what the tool returns (changes grouped by source, count, URIs), explains parameter syntax, and notes the static profile alternative. Given 3 required parameters and no output schema, this 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%, baseline 3. The description adds significant value: explains `since` accepts ISO dates and relative shorthand with examples, recommends '30d'/'1m', clarifies `type` only supports 'company', and `value` can be ticker or CIK. This goes well beyond schema descriptions.

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

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

The description clearly states it provides a change feed for a company, listing specific sources (SEC EDGAR, GDELT/GNews, USPTO). It uses concrete examples like 'What's new with X' and 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?

The description includes explicit example queries and recommends when to use entity_profile instead. It could benefit from stating when not to use this tool, but it is generally clear.

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

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

Discloses key behavioral traits beyond annotations: key-value pair scoped by identifier, persistence duration (24h for anonymous, permanent for authenticated). Annotations indicate idempotentHint=true and destructiveHint=false, which description does not contradict.

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

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

Every sentence adds value. Front-loaded with purpose, then usage, then technical details. No redundancy. Three sentences cover all necessary 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?

Completely describes what the tool does, when to use it, how data is stored (key-value, scoped, persistence), and how it relates to sibling tools. No output schema needed for a simple storage operation.

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

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

Schema covers both params with descriptions. Description adds concrete examples for key (e.g., 'subject_property') and clarifies value as 'any text'. With 100% schema coverage, baseline is 3; examples elevate to 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?

Clear verb 'Save' with specific resource 'data' and purpose 'to reuse later'. Distinguishes from siblings by mentioning pairing with recall and forget. Provides examples of what to save.

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'. Gives concrete examples. Implicitly excludes querying or deletion by naming recall and forget as separate tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by stating that each call cascades through several lookup endpoints internally, replacing 2-3 manual lookups. This adds value 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 moderately concise, front-loaded with example queries, and structured with a clear purpose, usage instruction, and detailed supported types. Every sentence adds value, though it could be slightly trimmed 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?

Without an output schema, the description fully explains return values per type (ticker, CIK, company name, citation URI for company; RxCUI, ingredient, brand, citation for drug). It also mentions auto-disambiguation for company inputs, making the tool's behavior completely transparent.

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 enriches both parameters with examples and accepted formats (e.g., ticker/CIK/name for company, brand/generic for drug), adding meaning beyond 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 clearly states the tool resolves a spoken name to a canonical identifier, with specific example queries and a clear verb-resource pairing. It distinguishes itself from siblings by emphasizing it should be used first when a name is known but an ID is needed.

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

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

The description explicitly says "Use FIRST whenever you have a name but need an ID," providing strong when-to-use guidance. It also lists supported types and return formats, but does not explicitly mention when not to use the tool or name alternative sibling tools.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that it internally calls ai_visibility_check, which is helpful but not essential. Does not add further behavioral context like rate limits or side effects.

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 plus an example. Front-loaded with main purpose, 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?

Despite no output schema, description fully covers inputs, process (calls ai_visibility_check for each), and output (ranked list with score, confidence, signal density). Complete for moderate complexity tool.

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

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

Schema coverage is 100% and description adds critical meaning: first entity is the 'subject', default model is workers-ai, Anthropic requires apiKey. Greatly enhances parameter 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 compares AI visibility across multiple entities, specific verb+resource, and distinguishes from sibling 'ai_visibility_check' by emphasizing side-by-side comparison and ranking.

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

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

Explicitly describes use case ('competitive AI-marketing audits') and provides an example query. Does not explicitly exclude single entity use or name alternatives, though sibling tools cover that.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds rich behavioral context: fans out across two services, returns summary block, per-advisory detail, links, alternative versions, partial failures, and timing (5-30s for first measurement). 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 fairly detailed but front-loaded with main purpose. Some redundancy in listing return fields both in prose and later. Could be slightly trimmed but still effective.

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

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

Given the tool has only 2 parameters (both described in schema), describes return values comprehensively, covers failure modes and ecosystem scope. No output schema needed due to descriptive return details.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds extra value by mentioning scoped packages and default version behavior, going 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 as a composite check for adding an npm package, covering deps.dev and bundlephobia. It is a specific verb-resource pair and distinguishes itself from sibling tools by being a one-call composite.

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: 'is X safe / popular / small' or 'what does adding lodash cost me'. Also provides exclusion guidance: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly'.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds rich detail: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation flag, and character offsets for verification. This goes well beyond the annotations.

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

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

Every sentence serves a purpose: core action, usage scenario, output details, pairing advice, and technical constraints. No redundant or vague language. Front-loaded with the essential purpose.

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

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

Despite no output schema, the description explains return value: 'top-N passages with character offsets and similarity scores.' It covers input limits, implementation details, and pairing with a sibling tool. Complete for a focused retrieval tool.

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

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

Schema description coverage is 100% with good descriptions. The tool description adds real-world context: 'Pass the text you already pulled (e.g. a SEC 10-K body...)' and gives query examples like 'supply-chain risk'. This adds value beyond the schema.

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

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

The description uses specific verb+resource: 'Semantic search INSIDE a fetched record.' It clearly distinguishes from siblings like ask_pipeworx_grounded by focusing on searching within retrieved text rather than over the whole document.

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?

Describes when to use: 'when the record is too big to cram into the prompt.' It also pairs the tool with ask_pipeworx_grounded, explaining workflow. No explicit when-not-to-use, but the guidance is clear and helpful.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. Description confirms mutation (creates subscription) and adds detail: returns subscription id, requires OAuth, supports multiple types, delivery nuances (webhook signing, auto-disable). 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?

Well-structured with bullet points and examples. Front-loaded with purpose, then details. Slightly lengthy but every sentence adds value.

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

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

Covers core creation, types, params, delivery channels, and constraints. No output schema, but return value ('subscription id') is mentioned. Adequate for complexity.

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

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

Schema coverage is 100%, and description adds significant meaning: explains each type with examples (e.g., items:['5.02'] = officer change), details delivery object including webhook signing and auto-disable. Exceeds 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 states the verb 'Create', the resource 'subscription', and clearly outlines functionality: 'Create a proactive monitoring subscription to a live-data event stream.' It distinguishes from siblings like list_subscriptions and unsubscribe by focusing on creation.

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

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

Provides explicit context: requires Pipeworx OAuth account, cannot be used anonymously/BYO. Lists supported types and delivery channels with constraints (SMS cap, webhook auto-disable). Does not contrast directly with alternatives like recent_alerts, but usage is clear enough.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds valuable context: returns category-bucketed example questions with exact tool+argument shapes from a live catalog. 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?

Description is packed with useful information but not overly verbose. Starts with trigger phrases, explains output, then parameter. Could be slightly more concise but well-structured for readability.

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

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

Given the low complexity (1 optional param, no output schema), the description fully covers what the tool does, what it returns, and when to use it. No gaps.

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

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

Schema coverage is 100% with one parameter. Description adds significant meaning: lists valid topic values (finance, pharma, etc.) and explains that omitting it returns a cross-category spread. Goes well beyond the schema's brief 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's purpose: it's the onboarding entry point that returns categorized example questions with tool+argument shapes. It lists trigger phrases ('What can I ask Pipeworx?', 'give me ideas', etc.) and distinguishes itself from sibling tools by specifying it should be used first to discover capabilities.

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 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' Provides guidance on when to use the optional topic parameter to focus. Lacks explicit when-not-to-use but clear from 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?

Adds important behavioral context beyond annotations: ownership enforcement and that the row is deactivated (not deleted) so historical events remain available. Annotations already cover idempotency and non-destructiveness, so description complements well.

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

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

Two sentences with no wasted words. Front-loaded with the primary action ('Cancel a subscription by id') followed by critical behavioral details. Perfectly concise for the tool's simplicity.

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

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

For a simple tool with one parameter, full schema coverage, and no output schema, the description is nearly complete. It covers purpose, ownership constraint, and side effects (deactivation). Could mention that the subscription id must come from 'subscribe', but schema already notes that.

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

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

The single parameter 'id' has full schema coverage with a description matching the tool's purpose. Description adds no new information about the parameter beyond what the schema provides, meeting the baseline expectation.

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

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

Clearly states 'Cancel a subscription by id', specifying the action and resource. It distinguishes from sibling tools like 'subscribe' (create) and 'list_subscriptions' (list), and the 'by id' phrasing clarifies the parameter usage.

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?

Implicitly indicates usage via ownership enforcement (cancel own subscriptions) but does not explicitly state when to use this tool over alternatives like 'subscribe' or 'recent_alerts'. No direct guidance on when not to use it.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds significant context: the two processing paths (structured SEC vs grounded), the verdict types, and the inclusion of verbatim evidence with citations. 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 dense but well-structured, starting with examples, then usage, then behavior, then return. Every sentence adds value, though it is somewhat lengthy for a tool with only two parameters.

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

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

Given the complexity of claim verification, the description covers purpose, parameters, behavior, return format, and fallback logic. Even without an output schema, it sufficiently describes the 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%. The description adds meaning beyond schema by providing concrete examples for 'claim' and explaining the purpose and default behavior of 'tolerance_pct', including its use for hallucination detection.

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 clear examples ('Is it true that…', 'fact check') and defines the tool as natural-language claim verification against authoritative sources. It differentiates between company-financial and other claims, and mentions it replaces 4-6 sequential calls, distinguishing it from siblings.

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

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

The description explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the two processing paths. However, it does not explicitly mention when not to use it or name alternative tools.

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