Worldbank Procurement

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds transparency about model defaults (Workers AI), optional Anthropic (BYO key), and the return format (per-model score, confidence, signals, raw_response). No contradictions with annotations.

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

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

The description is three sentences, front-loaded with the core purpose, followed by model details and use cases. Every sentence serves a purpose with no redundancy or fluff. It is efficiently structured for quick reading.

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 is provided, but the description adequately explains the return structure (per-model object with score, confidence, signals, raw_response plus combined view). It covers primary use cases and model selection. It does not detail error handling or rate limits, but for a probing tool this is sufficient.

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

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

The input schema has 100% description coverage for all four parameters. The description adds context beyond the schema: it clarifies the default model, explains the _apiKey parameter purpose (BYO key for Anthropic), and suggests how to use the 'context' parameter for disambiguation. This adds meaningful value for an agent.

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

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

The description clearly states the tool probes LLMs for visibility of entities and returns scores. It is distinct from sibling tools like 'ask_pipeworx' (which answers questions) and 'deep_research' (which does comprehensive research). The verb 'probe' and specific outcome 'score visibility (0-100)' make the purpose unambiguous.

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

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

The description lists explicit use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It also explains when to use the optional Anthropic model and the need for an API key. However, it does not directly compare to sibling tools or state when not to use this tool, leaving some inference to 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavior context: routes across 5,462 tools, fills arguments automatically, returns citation URIs, works on all tiers, and requires only one fast call. It does not contradict annotations and enhances the safety profile with additional operational details.

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

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

The description is longer than average but well-structured: it opens with the most critical instruction ('PREFER OVER WEB SEARCH'), then explains mechanism, lists trigger phrases, provides examples, and gives escalation guidance. Each sentence adds useful information, though there is minor redundancy around when web search could also be used.

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 complex meta-tool with no output schema, the description is remarkably complete. It covers the tool's scope, internal routing behavior, output format with citations, typical user intents, examples, performance characteristics, tier availability, and explicit alternatives. The agent has enough context to select and invoke the tool correctly without needing external documentation.

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

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

Input schema coverage is 100% and describes the 'question' parameter with aliases (query, q, prompt, text, input) and examples. The description itself does not add much parameter-level detail beyond usage context, so a baseline 3 is appropriate since the schema carries the parameter semantics.

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

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

The description clearly states the tool's purpose: answering factual questions by routing them to the appropriate tool from 5,462 sources and returning structured answers with stable pipeworx:// citation URIs. It also distinguishes itself from sibling tools by explicitly naming ask_pipeworx_grounded and deep_research as alternatives for different scenarios.

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?

Usage guidance is explicit and comprehensive: 'PREFER OVER WEB SEARCH' for authoritative data, 'START HERE for most questions', and 'Step up only when needed' with specific alternatives. It also covers edge cases like breaking news and multi-part questions, 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 already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context about the experimental nature, current equivalence to ask_pipeworx, and that it is a full working router. This goes beyond the annotation-provided safety profile.

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 detailed but front-loaded with the core purpose, then explains the experimental state and usage. Every sentence contributes meaningful context, though it could be slightly more concise without losing substance.

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 one required parameter and no output schema, the description effectively communicates its behavior by referencing ask_pipeworx for response shape and explaining the current experimental state. It is sufficiently complete for an agent to select and invoke the 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?

With 100% schema description coverage, the schema fully documents the 'question' parameter and aliases. The description adds no extra parameter information, matching the baseline of 3 for high schema coverage.

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

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

The description clearly states it is a beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape, but with candidate routing improvements. This explicitly distinguishes it from the stable ask_pipeworx and other 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?

It explicitly instructs to use it exactly like ask_pipeworx when wanting the newest routing, and notes that results are compared against the stable router. This gives clear context on when to choose this tool, though it doesn't explicitly mention when not to use it (e.g., when stability is preferred).

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 readOnly/idempotent annotations, the description details refusal behavior with specific refusal_reason enums, the exact return shape including evidence, and the extra LLM call cost. This is rich behavioral disclosure with 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?

Four dense sentences, each carrying essential information: purpose, routing mechanism, return/refusal contract, and usage guidance. The description is front-loaded and contains no filler.

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

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

Despite lacking an output schema, the description fully specifies return values, refusal reasons, when to use, and cost tradeoffs. It provides all necessary context for safe invocation of this complex tool.

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

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

The schema already provides 100% coverage with all parameters described as aliases for 'question'. The description adds context about how the question is used for routing and extraction but doesn't alter parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states this is a hallucination-resistant answer mode for high-stakes reads, and distinguishes itself from ask_pipeworx by extracting answers solely from tool results. The verb 'EXTRACTS' and the explicit mention of evidence and refusals make the purpose precise and distinct.

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 use when an answer will be quoted, cited, or acted on and facts must not be invented, and recommends ask_pipeworx for casual lookups. This provides a clear decision rule and names the alternative 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 declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds extensive behavioral details: market resolution, classification, parallel fan-out, response shapes, resolver contract, parent event extraction, news fallback, safety short-circuits, closed market handling, wide-spread liquidity, and cancellation rule parsing. 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 well-structured with section headers but is very long (multiple paragraphs). While informative, it could be more concise. The first sentence states the purpose clearly, but the length may increase prompt size.

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 (3 parameters, no output schema, many edge cases), the description covers all important aspects: input format, response shapes, resolver contract, parent event, news fields, safety behaviors, cancellation risk, and liquidity 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 coverage is 100%, so baseline 3. The description adds meaning by explaining the market parameter formats (slug, URL, question), depth options with default, and include_raw usage. Examples in schema also help.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, specifies input types (slug, URL, question text), and lists classifiers and fan-out examples. It effectively distinguishes from sibling tools like polymarket_arbitrage by focusing on comprehensive research.

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

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

Explicit usage scenarios are given ('Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"') along with examples. It also covers when to avoid (low-confidence and closed markets).

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, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral details: data sources (SEC EDGAR/XBRL, FAERS), off-calendar fiscal year handling, results sorted by primary metric, and citation URIs. No contradiction with annotations.

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

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

Description is somewhat long but each part adds value: trigger phrases, usage guidance, data specifics for each type, result sorting, replacement claim. Front-loaded with key intent. Could be trimmed slightly but efficient for the information density.

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 exists, but description explains return format (paired data + citation URIs) and sorting. Covers key data sources and entity count limits (2-5). Lacks details on pagination or error states, but given the complexity, it is sufficiently 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 both parameters described. Description adds valuable context: explains type values (company/drug) with specific data retrieved, and values with examples and format (tickers/CIKs for company, names for drug). Enhances schema meaning.

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

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

Description opens with multiple trigger phrases ("Compare X and Y", "X vs Y") and clearly states it performs side-by-side comparison of 2-5 companies or drugs in one parallel call. It distinguishes from siblings like entity_profile by emphasizing multi-entity comparison and efficiency.

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

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

Explicitly advises to 'ALWAYS PREFER over sequential single-pack lookups' and provides example queries. It states it replaces 8-15 sequential lookups, giving clear usage context. Lacks explicit when-not-to-use but context is sufficient.

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

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

The description goes far beyond the readOnlyHint/idempotentHint annotations, disclosing account requirements, free vs paid depth levels, the full return packet format (verbatim evidence, confidence, source, fetched_at, pipeworx:// citations, gaps[], contradictions[]), the 'never invented' guarantee, semantic excerpting, and expected latency. No contradiction with annotations 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 front-loaded with critical account constraints, then purpose, then usage rules, then detailed depth behavior. Every sentence adds information—there is no filler. It is dense but structured logically, earning a slight deduction for being more verbose than necessary.

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

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

With no output schema, the description fully explains what the tool returns: findings packet, gaps[], contradictions[], hop field, and fetchable citation_uri. It also covers timing, account prerequisites, and alternative tools. For a complex research tool, this leaves no major contextual gap.

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

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

Although schema coverage is 100% (baseline 3), the description adds depth-specific meaning: 'depth:"standard" re-angles unanswered gaps (gap recovery)' and 'depth:"thorough" additionally chases the best leads... plus the contradictions[] scan,' and notes thorough is paid. It also clarifies the question parameter accepts broad natural language. This is meaningful enhancement over 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 a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources... in ONE call — this is NOT open-web search.' It distinguishes itself from siblings like ask_pipeworx and explicitly contrasts with open-web search, making its scope 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?

It gives explicit when-to-use and when-not-to-use guidance: 'Best for broad/multi-part questions over structured data,' 'For a single lookup use ask_pipeworx,' 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx,' and 'If you are not signed in, use ask_pipeworx instead.' This is exemplary alternative naming and exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns top-N tools with full schemas ready to call, which is valuable behavioral context beyond annotations.

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

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

Description is somewhat lengthy but front-loaded with purpose and usage guidance. Every sentence adds value, though could be slightly more compact.

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 explains what is returned (names, descriptions, schemas) and that results are ready to call. Parameter descriptions are comprehensive. Complete for a discovery tool.

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

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

Schema coverage is 100%, so baseline is 3. Description mentions aliases (task, q) and limit, but mostly duplicates schema info. Still adds some clarity about parameter naming flexibility.

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

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

Description clearly states the tool finds tools by describing data/task, listing many domains. It distinguishes itself from siblings (specific data tools) by being a discovery layer.

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 'Call this FIRST when you have many tools available and want to see the option set', providing clear when-to-use. Also subtly indicates when not to use (if you already know the tool).

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds rich behavioral details: fans out across multiple sources (SEC EDGAR, XBRL, USPTO, news, GLEIF), specifies return fields (cik, recent_filings with URIs, fundamentals, patents with sunset notice, news fallback), and mentions soft-fail for patents.

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 slightly verbose. It is well-structured: starts with example prompts, explains the aggregative nature, then lists return components and limitations. Every sentence contributes, but could be tightened without losing crucial 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?

Given the complexity (multi-source aggregation, no output schema), the description is comprehensive. It covers input requirements, return data, source dependencies, known limitations (patent sunset), and fallback behavior (GDELT→GNews). No gaps are apparent.

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

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

Input schema describes both parameters (type, value) with 100% coverage. The description adds context: type only supports 'company', value must be ticker or zero-padded CIK (e.g., '0000320193'), and explicitly notes that names are not supported. This augments schema with examples and constraints.

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: 'full cross-source profile of a US public company in ONE parallel call.' It provides multiple query examples (e.g., 'Tell me about X', 'research Acme') and distinguishes itself from sibling tools like 'compare_entities' and 'resolve_entity' by focusing on holistic company 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?

Explicit guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also specifies that names are not supported and advises using 'resolve_entity' first if only a name is 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 indicate destructiveHint=true and idempotentHint=true. Description adds usage context but no additional behavioral traits like confirmation or error handling.

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, purpose first, usage second. No superfluous words.

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

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

Covers purpose and usage guidelines adequately for a simple one-parameter tool, but lacks mention of return value or success/failure 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%, and description repeats 'by key' but adds no new meaning beyond the schema's 'Memory key to delete.'

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

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

Clearly states verb 'Delete' and resource 'memory by key'. Distinguishes from sibling tools 'remember' and 'recall' by specifying deletion.

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 use when context is stale, task is done, or clearing sensitive data. Recommends pairing with siblings. No explicit when-not but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool fetches the page, extracts title/description/key links, and emits standard llms.txt markdown, which provides behavioral clarity 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 four sentences with no wasted words, front-loading the core purpose, then details, and ends with explicit use cases.

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

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

Given the tool's simplicity (2 params, no output schema, clear annotations), the description fully covers what the tool does, how it works (fetches, extracts, emits), and the output format (markdown blob). An agent can confidently 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?

Schema description coverage is 100% for both parameters (url and max_links). The description adds no new parameter-level details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Generate') and resource ('production-ready llms.txt file'), lists target AI crawlers, and explicitly distinguishes from sibling tools by stating use cases like getting a client's site indexed, drafting for own project, or auditing a competitor.

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

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

The description provides clear use cases (client indexing, own project drafting, competitor auditing) but does not explicitly state when not to use this tool or mention alternatives like scan_competitor_ai_presence.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the exact fields returned (id, type, params, created_at, etc.), providing concrete behavioral context 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?

Two sentences: the first defines purpose and output, the second provides usage guidance. Every word serves a purpose, and the most critical information (what it does) is front-loaded.

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

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

For a simple tool with one optional boolean parameter and no output schema, the description covers purpose, return fields, and usage context. No additional information is necessary.

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

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

Schema coverage is 100% with a clear description for the only parameter (include_inactive). The description does not add additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description explicitly states 'List the caller's active subscriptions' and lists the return fields. It clearly identifies the resource (subscriptions) and action (list), distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

Provides specific guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' It implies when to use the tool but does not explicitly state when not to use it or name 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?

All annotations are false, so the description carries full burden. It discloses rate limiting ('Rate-limited to 5 per identifier per day'), quota impact ('doesn't count against your tool-call quota'), ingestion cadence ('team reads digests daily'), and content expectations ('don't paste the end-user's prompt'). These are valuable behavioral details beyond any structured fields.

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

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

The description is longer than strictly needed, but it is front-loaded with purpose and usage, and every sentence adds useful context (exclusions, rate limits, content rules). It is logically organized and not redundant with the schema, though it could be trimmed 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?

Given the tool's moderate complexity (3 params, nested context object, no output schema) and no annotations, the description fully compensates: it covers when to use, what to include, exclusions, rate limits, and roadmap impact. The agent has everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by mapping the enum values to real scenarios ('bug = wrong/stale data', 'feature/data_gap = tool you wish existed'), and explains how to use context ('Describe the issue in terms of Pipeworx tools/packs'). This goes beyond the schema's descriptions, justifying a 4.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly defines the tool's action (submitting feedback) and its scope (Pipeworx tools/packs), and differentiates it from sibling tools by stating it is the only feedback tool for Pipeworx and explicitly excluding tools from other MCP servers.

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

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

The description provides explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug)...' or for feature/data_gap/praise. It also gives a clear exclusion: 'if the tool came from a different MCP server... file it with that server instead.' This is a textbook example of usage guidelines with alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds valuable behavioral details: self-aggregating from CF analytics-engine, no PII, caching behavior (5min-1h). This adds context beyond the structured fields.

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

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

Description is concise (two sentences plus bulleted use cases). Front-loaded with what it returns. 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?

For a simple tool with one parameter, no output schema, and rich annotations, the description is complete: covers purpose, use cases, behavior, caching, and privacy. 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 has 100% coverage with enum and description for 'window'. Description adds minimal extra value beyond repeating the window options and noting shorter vs longer windows. Baseline 3 is appropriate since schema already documents the parameter well.

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

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

Description clearly states the tool returns top tools, top packs, and call volume over windows. Verb 'returns' and resource 'trending' are specific. Distinguishes from sibling tools like 'discover_tools' by focusing on real-time call volume from other AI agents.

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

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

Explicitly lists three use cases: discovering hot data sources, confirming canonical tools, and seeing alignment. Provides context for when to use shorter vs longer windows. No explicit when-not or alternatives, but the guidance is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description goes well beyond by detailing the monotonicity and partition-sum checks, semantic anchor with Jaccard threshold, partition filter for placeholders, fill check with realizable_edge_pp, and response structure. No contradiction with annotations.

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

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

The description is front-loaded with the summary and modes, then provides detailed technical context. It is longer than average but every sentence adds value for understanding this complex tool. Could be slightly more streamlined, but overall 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?

Despite no output schema, the description details the response structure (opportunities array with fields, partition_check, fill check) and refers to polymarket_fill_risk for custom sizing. It covers edge cases (placeholders, low similarity) and explains what returns null. For a complex tool with 2 parameters and no output schema, the description is fully complete.

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

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

Schema description coverage is 100% with both parameters described. The description adds significant value by explaining the behavior of each parameter: event accepts slug or URL, topic is a seed question for cross-event scan, and the no-arg case triggers trending scan. It also clarifies the underlying algorithms and edge cases.

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 arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes: no args for trending scan, event for single-event, topic for cross-event. The verb 'find' and resource 'arbitrage opportunities' are specific and differentiate 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 provides explicit guidance on when to use each parameter: no args for trending, event for a specific market, topic for cross-event scanning. It explains that cross-event mode catches patterns single-event misses. However, it does not explicitly compare to sibling tools like polymarket_edges or polymarket_fill_risk, which could clarify when to use this tool instead.

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

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

The description fully discloses behavioral traits: caching (1h KV-level keyed on knobs), model details (three segments with formulas), response structure (by_segment, diagnostics), and edge calculation (net of slippage, with 24h move warning). No contradictions with annotations (readOnlyHint, idempotentHint are supported).

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 detailed (approx. 600 words) and structured with numbered segments, but it is verbose. While every sentence adds information, the length may hinder quick parsing by an AI agent. Front-loading is good, but overall conciseness suffers.

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

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

Given the tool's complexity (9 parameters, no output schema, no nested objects), the description is exceptionally complete. It explains the response structure (by_segment, diagnostics), caching, excluded scenarios (Fed bets), and provides debugging help (diagnostics for empty segments).

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

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

All 9 parameters have schema descriptions, and the description adds extensive context beyond the schema (e.g., tradeable-edge knobs, min_partition_leg_kelly explanation, default values, and usage tips like slippage adjustment). Schema coverage is 100%, but the description still adds substantial value.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It specifies the intended use case ('what should I bet on today') and distinguishes itself from sibling tools by detailing its unique model families and output segments.

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

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

The description provides clear context on when to use the tool (to discover betting opportunities) and explains some limitations (Fed bets are excluded due to unreliable data). However, it does not explicitly compare to sibling tools or provide when-not-to-use scenarios.

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

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

The description adds extensive behavioral context beyond the annotations: detailed response structure (tracked, expired, snapshot_dates), trend computation, decay calculation, and limits (60-day TTL, not intraday). Annotations already indicate safe read-only operation, so the description enriches understanding without contradiction.

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

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

The description is relatively long but well-structured, starting with the core purpose, then detailing the response format, and ending with limitations. Every sentence adds value, though the response fields could be formatted as a list for easier parsing.

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

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

Despite having no output schema, the description provides a complete mapping of the response (tracked, expired, snapshot_dates) with detailed explanations of each field. It covers edge cases (gaps, expiration) and limitations, making it fully informative for agent decision-making.

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%, providing a baseline of 3. The description adds meaning by explaining 'days' as lookback (default 14, max 30) and 'window' as snapshot family (default '1wk'), tying them to the underlying data lineage. This contextualizes parameters beyond their 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: providing edge persistence and decay telemetry from daily snapshots. It distinguishes itself from the sibling tool 'polymarket_edges' by focusing on time-series analysis and trend detection, answering 'how long has this edge existed and is it shrinking?'

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

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

The description implies when to use this tool (to assess edge aging and decay) versus alternatives (e.g., polymarket_edges for current snapshots). It provides context about the difference between fresh and old edges. However, it does not explicitly state when not to use it or list alternatives.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and no destructive effects. The description adds significant behavioral details: walks the ladder, returns specific fields like top_of_book, vwap_fill_price, slippage_pp, and explains basket risks like forced directional risk and thin legs. 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: overall purpose first, then detailed modes, then usage guidance. It front-loads the verb and resource. However, it is somewhat verbose (multiple sentences per mode). Could be slightly trimmed, but 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?

With 4 parameters and no output schema, the description thoroughly explains return fields (top_of_book, vwap_fill_price, capturability ratios, thin_legs, etc.) and risk concepts. It provides enough context 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%, but the description adds meaning beyond the schema: explains default behavior for size_usd, clarifies side auto-detection for baskets, and differentiates interpretation of size_usd between single-market and basket modes. This adds value 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 the tool checks realizable-vs-theoretical edge against live CLOB order-book depth. Distinguishes between single-market and basket modes with specific examples. The verb 'check' and resource 'edge against order-book depth' are specific and set it apart from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly recommends using this tool before acting on polymarket_arbitrage signals or trades above $500. Provides context for when it's critical ('theoretical overround on thin books is not capturable'). Could mention when not to use (e.g., very small trades), but the given guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context: two modes, response structure (leg-by-leg prices, spread, safety fields), meaning of compatibility_warning (two cases), temporal_alignment implications, and skipped counters. This fully discloses behavior 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 comprehensive and well-structured with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence adds value, but it is somewhat verbose. It could be slightly trimmed without losing essential information, but front-loads the core purpose effectively.

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 (3 params, 0 required, no output schema), the description thoroughly explains the response format, safety fields, warning conditions, and temporal alignment. It compensates for the lack of output schema by detailing return values and edge cases. All necessary context for correct usage is provided.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant meaning: explains the topic mode with enumerated list, clarifies that explicit tickers override topic-mapped sides, provides concrete examples, and explains how parameters interact (mode selection logic). This goes well beyond the schema descriptions.

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

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

The description clearly defines the tool's purpose: cross-venue spread between Kalshi and Polymarket for the same resolving question. It uses specific verbs (spread, compare) and identifies the resource (probabilities across two prediction markets). It distinguishes from sibling tools like 'polymarket_arbitrage' by focusing on cross-venue comparison and explicitly naming the two modes (topic shortcuts and explicit pairings).

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

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

The description explains when to use the tool (when bet shapes are equivalent, delta is a real signal) and when it's not meaningful (compatibility warnings, temporal misalignment). It details two modes and provides warnings about pre-mapped topics. However, it does not explicitly contrast with sibling tools or state when to prefer alternatives, missing some comparative guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds scope (by identifier) and dual behavior (retrieve vs. list). No contradictions. Adds value by describing what kind of data is stored (user's target ticker, etc.).

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?

Only three short, information-dense sentences. No fluff. Every sentence adds value: function, usage examples, scope, and pairing instructions. Well front-loaded.

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

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

Given the tool's simplicity (one optional param, read-only), description is thorough. Covers purpose, usage, scope, and related tools. Lacks explicit return format description, but the tool's behavior is intuitive enough for this not to be a significant gap.

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

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

Schema covers 100% of parameter description. Description rephrases 'omit to list all keys' and adds example values, but does not significantly extend beyond what schema already provides. Baseline of 3 is appropriate.

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

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

Clearly states the tool retrieves a value by key or lists all keys when omitted. Distinguishes from siblings by naming 'remember' and 'forget' as complementary tools, and provides concrete examples (ticker, address, research notes).

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

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

Provides clear context for use (retrieve stored context without re-deriving) and examples. Implicitly contrasts with saving via remember, but does not explicitly state when NOT to use this tool. The mention of omitting key for list is 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?

The description adds significant context beyond annotations: explains returned fields (source, citation_uri, raw payload), behavior of mark_read, and alternative access method. Annotations already indicate read-only, idempotent, non-destructive; description enriches without contradiction.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by concise details. Each sentence serves a purpose without redundancy—four sentences covering all key aspects.

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

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

Despite no output schema, the description specifies what the response contains (source, citation_uri, raw payload). Parameters are well-documented, and the behavior is fully disclosed. The complexity is low, and the description covers all necessary information.

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 value with examples like 'e.g. "sec_8k"' for type and 'ISO timestamp' for since, and explains the effect of mark_read. It doesn't cover all parameters (limit, unread_only) but compensates with meaningful context.

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

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

The description clearly states 'Pull fired events from your subscription feed' with a specific verb and resource, and distinguishes from siblings like list_subscriptions that manage subscriptions, not retrieve events.

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

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

The description explains when to use this tool (filtering by type/since, setting mark_read) and mentions that polling works and an alternative endpoint exists. It doesn't explicitly state when not to use, but the context is sufficient.

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

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

Annotations declare safe non-destructive, idempotent read operations. Description adds context: fans out to multiple sources, GDELT→GNews fallback on rate limits/5xx, USPTO soft-fails until reactivated, and details the return structure (changes[] grouped by source, total_changes count, citation URIs).

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

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

Description is slightly long but efficiently structured: opens with example queries, then details sources, parameters, and fallbacks, ending with return format and sibling pointer. Every sentence adds value, though a minor reduction could improve scanability.

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 exists, but description fully explains return format (changes[] grouped by source + total_changes + citation URIs). Covers edge cases (USPTO soft-fail, rate limiting fallback). Provides parameter defaults ('30d'). Guidance for sibling tool when static profile is needed.

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

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

Schema already documents all 3 parameters comprehensively. Description adds significant value: explains `since` accepts ISO dates or relative shorthand with examples, notes `value` can be ticker or CIK, and clarifies `type` is currently only 'company'.

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

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

Description clearly states it provides a change feed for a company covering SEC filings, GDELT/GNews news, and USPTO patents. It explicitly distinguishes from sibling 'entity_profile' by noting when to use that instead.

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

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

Provides explicit example queries (e.g., 'What's new with X', 'latest on Y') and directly states when to use the alternative 'entity_profile'. Also explains fallback behavior from GDELT to GNews.

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 idempotentHint=true and destructiveHint=false. Description adds scoping by identifier, persistence details (authenticated vs anonymous), which is useful context beyond annotations. No contradiction.

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

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

Three well-structured sentences, front-loaded with main action and purpose. 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?

For a simple 2-parameter tool with no output schema, the description is complete: covers purpose, usage, persistence, and pairing 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 coverage is 100% with descriptions for both parameters. Description adds example values but no additional meaning beyond what schema provides. Baseline 3 for high 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?

Clearly states the verb 'Save data' and resource 'data the agent will need to reuse later'. Distinguishes from siblings 'recall' and 'forget' by mentioning them as partners.

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

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

Explicitly tells when to use: 'when you discover something worth carrying forward'. Provides alternatives: 'Pair with recall to retrieve later, forget to delete.'

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context: it mentions the internal cascading through multiple lookup endpoints, auto-disambiguation, and the exact citation URIs returned. This exceeds what annotations convey, though it omits edge-case behavior such as failures.

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

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

The description is front-loaded with concrete user queries and usage guidance, making the purpose immediately clear. It is longer than average but each section (example, supported types, outputs, citations) earns its place, though it could be slightly tightened.

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

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

With no output schema, the description fully compensates by specifying return fields and citation URIs for each supported type. It also covers input formats and the tool's role relative to other tools, making it complete for a lookup 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?

Although the schema already covers parameter basics at 100%, the description adds substantial semantics: it explains the accepted input formats per type (ticker, CIK, or name; brand or generic drug name), the output fields, and the meaning of auto-disambiguation. This goes well beyond the schema's concise property descriptions.

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

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

The description clearly states the tool's purpose: resolving user-spoken names to canonical identifiers required by other tools. It provides specific examples and differentiates from siblings by declaring it should be used first whenever 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?

Explicit guidance is given: 'Use FIRST whenever you have a name but need an ID.' Supported entity types are detailed, but no explicit exclusions or named alternatives are provided, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it probes each entity with ai_visibility_check, returns a ranked list with score, confidence, signal density, and explains parameter usage (e.g., _apiKey, context). No contradiction.

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

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

The description is three sentences, front-loaded with the main action, and every sentence adds essential information. No redundant or unnecessary text.

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 details the return format (ranked list with score, confidence, signal density) and covers constraints (2-8 entities). Comprehensive for a comparison 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%, baseline 3. The description adds extra semantics: 'First entry treated as the subject for narrative; rest are competitors,' clarifies models default, and explains _apiKey usage, providing value beyond schema.

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

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

The description clearly states it compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and identifies most/least recognized. It gives a concrete use-case example, distinguishing it from siblings like ai_visibility_check (single entity) and compare_entities (generic).

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 says 'useful for competitive AI-marketing audits' and provides an example question, clearly implying when to use. While it doesn't explicitly state when not to use or list alternatives, the context is sufficient for 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?

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds critical behavioral details: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed will list timeouts. No contradictions with annotations.

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

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

The description is a single paragraph but packs all essential information without waste. It front-loads the purpose and usage, though a slightly more structured format (e.g., bullet points) could improve 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?

Despite no output schema, the description fully documents the return structure (summary block fields, per-advisory detail, links, alternatives). It also covers ecosystem scope, partial failures, and latency, making it complete for a complex tool.

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

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

Schema description coverage is 100% for both parameters (package and version). The description does not add additional meaning beyond the schema, so baseline of 3 applies.

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

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

The description clearly states the tool performs a composite check for adding an npm package by querying deps.dev and bundlephobia. It specifies the resource (npm dependency) and distinguishes from sibling tools, none of which handle dependency scanning.

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

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

Explicit usage scenarios are given: 'is X safe / popular / small' or 'what does adding lodash cost me'. It also specifies when not to use (non-npm ecosystems) and directs to deps.dev:version directly as alternative for PyPI, Maven, Cargo, Go.

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 nature. Description adds technical details: BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation/flagging, and offset for verification. 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 somewhat lengthy but each sentence adds unique value. It is front-loaded with core purpose and usage, then technical details. No wasted words, though could be slightly more concise.

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

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

Given the complexity (3 params, no output schema but good annotations), the description is thorough. It covers when to use, technical behavior, return format (passages with offsets and scores), and pairing with sibling. No gaps remain.

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

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

Schema description coverage is 100%, so baseline 3. Description adds value by providing examples for 'query', clarifying 'limit' defaults and range, and repeating the 200K char max for 'text'. This improves agent understanding beyond 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 it performs semantic search inside a fetched record, specifying the use case (when record is too large for prompt) and return type (top-N passages with offsets and similarity scores). It distinguishes from sibling ask_pipeworx_grounded by pairing 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?

Explicit guidelines: 'Use when the record is too big to cram into the prompt' and 'Pass the text you already pulled'. Also pairs with ask_pipeworx_grounded for grounding over relevant passages.

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 idempotentHint=true and destructiveHint=false. The description adds detailed behavioral context: OAuth requirement, delivery channel options, verification steps, rate limits (10/day sms), webhook signing secret (one-time), and auto-disable after 10 failures. No contradiction with annotations. Slightly lacking explicit idempotency mention but otherwise comprehensive.

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; the description is well-organized: purpose, prerequisites, types with examples, delivery channels. 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?

For a 3-parameter tool with no output schema, the description covers all necessary information: creation, return value (id), usage constraints, delivery setup, and failure behavior. 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 coverage is 100%, and the description significantly enriches each parameter with examples, type-specific parameter formats, and delivery channel details (e.g., phone verification, webhook HMAC). This goes well beyond the schema descriptions.

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

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

Clearly states it creates a subscription to a live-data event stream and returns an ID. The verb 'create' and resource 'subscription' are specific, and the tool is distinct from siblings like 'unsubscribe' and 'list_subscriptions'.

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

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

Provides prerequisites (OAuth account) and delivery channel constraints, but does not explicitly guide when to use this versus alternative tools like 'recent_alerts' or 'polymarket_edges'. Usage context is present but limited.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns example questions from a live catalog, includes tool+argument shapes, and acts as the onboarding entry point. No contradictions with annotations.

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

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

The description is a single well-structured paragraph that front-loads alternative phrasings, then states the purpose, output details, and usage. Each sentence adds value, though slight tightening possible.

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

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

Given the simple tool (one optional param), the description thoroughly covers when to use, what it returns (category-bucketed examples with tool shapes), and how to use the parameter. It is complete for an onboarding tool with no output schema.

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

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

Schema coverage is 100% for the single optional parameter, describing it as a focus area with permitted values. The description enhances this by explaining that omitting gives a full spread and including 'topic' focuses the results, listing example values.

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

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

The description clearly states it is an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It explicitly contrasts with sibling tools like ask_pipeworx, entity_profile, etc., and suggests using it first when the agent doesn't know what Pipeworx can do.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do' and 'or to learn how to call the meta-tools'. It also explains when to pass the topic parameter vs omit, providing clear context 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?

The description adds context beyond annotations: ownership enforcement and that the row is deactivated (not deleted). Annotations indicate idempotent and non-destructive, but description clarifies behavioral details.

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

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

Two sentences, no wasted words, front-loaded with the primary action. Efficient and clear.

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

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

For a simple mutation tool with one parameter and no output schema, the description adequately covers purpose, ownership constraint, and behavioral effect (deactivation). No gaps identified.

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

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

Schema coverage is 100%, and the description does not add additional meaning beyond what the schema provides for the 'id' parameter. Baseline score of 3 is appropriate.

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

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

The description clearly states the action 'cancel a subscription by id', specifying the verb (cancel) and resource (subscription). It distinguishes itself from siblings like 'subscribe' and 'list_subscriptions' by focusing on cancellation.

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

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

Explicitly states ownership enforcement and that only own subscriptions can be canceled, providing clear when-to-use and when-not-to-use guidance. Also explains the effect (deactivation, not deletion).

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

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

The description adds significant behavioral context beyond annotations: it explains the two processing paths (SEC EDGAR for financial claims, grounded pipeline for others), details the return verdicts, and notes it is composite. Annotations already indicate read-only, open-world, idempotent, and non-destructive, which the description does not contradict and 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?

The description is well-structured, front-loaded with usage cues and examples. It covers all necessary information without redundancy. Slightly longer than minimal but each 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, the description thoroughly explains return values (verdict, value with citation, reasoning) and the two processing pipelines. It also notes efficiency gains (replaces multiple calls). All essential aspects are covered.

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

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

The input schema has 100% coverage, so baseline is 3. The description adds value by explaining how 'tolerance_pct' overrides implied wording and providing usage context for 'claim' with examples. This goes beyond the schema's descriptions.

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

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

The description clearly defines the tool's purpose: verifying natural-language factual claims. It uses specific verbs like 'validate', 'verify', 'check' and distinguishes itself from siblings by stating it replaces 4-6 sequential calls, differentiating it from tools that only perform parts of the process (e.g., deep_research, ask_pipeworx).

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

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

The description explicitly states when to use the tool ('whenever the agent needs to check whether something a user said is factually correct') and provides example invocation phrases. However, it does not explicitly compare to sibling tools or specify when not to use it, lacking exclusion criteria.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds valuable behavioral details: results are sorted newest first, no authentication needed, and the result fields include a public notice URL. This goes beyond the annotations without contradicting 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?

The description is a single, front-loaded paragraph that efficiently conveys the core action, filtering options, result contents, ordering, and access requirements. Every sentence contributes meaningful information without redundancy.

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

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

For a read-only search tool with four optional parameters and no output schema, the description covers functionality, filtering, result fields, ordering, and authentication. It lacks explicit explanation of pagination response structure but includes enough for effective usage.

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 each parameter is already described in the input schema. The description restates that filtering is by keyword and country but does not add new semantic meaning beyond what the schema provides, achieving only the baseline score.

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

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

The description clearly states the tool searches World Bank contract awards, specifies the data scope (300k+ notices), and distinguishes it from sibling tools by focusing on award records rather than procurement details or country-specific searches.

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

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

The description provides context on when to use the tool (searching by keyword/country for awards) and mentions default ordering (newest first) and no API key requirement. However, it does not explicitly state 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.

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context: keyless access, 'newest first' ordering, and that it covers notices from World Bank projects. No contradictions with annotations.

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

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

Two concise sentences that front-load the purpose and key details. Every sentence adds value with no redundancy.

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

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

Without an output schema, the description explains the return format including bid reference, project name, submission deadline, etc. It covers the essential context for a list tool with three well-documented parameters.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds little beyond schema: mentions 'newest first' ordering and keyless access but doesn't elaborate on parameter semantics. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists latest World Bank procurement notices for a developing country, specifying types (open tenders, invitations, etc.) and output fields. It distinguishes itself from siblings like wb_procurement_awards and wb_procurement_search by focusing on listing all notices by country.

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

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

The description implies usage for finding bidding opportunities or contract activity, but lacks explicit guidance on when not to use it or comparisons with sibling tools. The phrase 'useful for' suggests context but no exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows it's safe and idempotent. The description adds value by detailing the full record returned (notice type, status, project, country, etc.), and confirms it returns the public notice URL, which goes beyond annotations.

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

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

The description is two sentences, concise and front-loaded with the main action. Every sentence provides essential information: what it does, how to use it, and what it returns.

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

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

For a tool with one parameter, no output schema, and no nested objects, the description is complete. It lists all major return fields (notice type, status, project, country, deadline, method, contact info, full notice text, URL). Without an output schema, the agent relies on the description for understanding the response, and this description covers it well.

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 meaningful context for the 'id' parameter: it specifies that the id is from wb_procurement_search results and provides an example ('OP00457469'). This helps the agent understand the parameter's source and format.

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

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

The description clearly states 'Fetch one World Bank procurement notice by its notice id', specifying the exact action and resource. It also distinguishes itself from sibling tools like wb_procurement_search and wb_procurement_awards by its singular focus on a single notice 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?

The description explicitly instructs to use the notice id from wb_procurement_search results, providing clear context for when to use this tool. While it doesn't explicitly state when not to use it, the context is sufficient for an agent to understand its role as a detail fetcher after search.

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

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

Annotations already indicate readOnlyHint, idempotentHint, openWorldHint. The description adds behavioral context: results sorted newest first, keyless access, and global multilateral source. 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 informative and front-loaded, but slightly verbose with extra details like '~412k notices'. Could be tighter without losing 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?

For a search tool with no output schema, the description fully covers purpose, filters, ordering, and return fields (bid reference, project, deadline, URL). It provides examples and notes keyless access, making it very 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%. The description adds meaning beyond the schema by explaining query as full-text, country as plain English, notice_type with shorthand. Examples further clarify usage.

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

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

The description clearly states it searches World Bank procurement notices with full-text and filters, listing notice types and regions. However, it does not explicitly differentiate from sibling tools like wb_procurement_awards or wb_procurement_by_country, though the search capability is implied as distinct.

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

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

The description explains how to use filters and search, but does not provide explicit when-to-use or when-not-to-use guidance versus sibling tools. Alternatives are not mentioned.

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