Taiwan Procurement

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

Annotations already declare the tool read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral detail beyond those flags: the free default model, the BYO-key cost implication ('you pay Anthropic directly'), and the per-model return shape. It does not mention rate limits or failure modes, but the safety profile is already covered by annotations.

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

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

Three sentences, no filler, front-loaded with the primary action and scoring output. Every sentence contributes: what it does, how to get the optional paid model, what it returns, and when to use it. The structure is compact and scannable.

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

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

For a tool with no output schema, the description explicitly lists the per-model return fields and a combined view. It also covers the free vs BYO-key distinction, example use cases, and the entity input is documented in schema. Combined with strong annotations and 100% schema coverage, this is a complete tool description.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining the default model for the 'models' parameter, the requirement/style of '_apiKey' for Anthropic, and that omitting 'models' gives just workers-ai. This goes beyond the raw 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 opens with a specific verb ('Probe') and a clear resource ('one or more LLMs'), then states the core output: a visibility score (0-100) per model. It also clarifies the domain (business/brand/product/topic) and distinguishes the tool from siblings by focusing on LLM awareness scoring rather than general Q&A or 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?

The description gives explicit use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and clarifies the default model plus the _apiKey opt-in for Anthropic. It does not explicitly name alternative sibling tools or state when not to use it, but the context is clear enough 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds value by explaining that it 'returns the structured answer with stable pipeworx:// citation URIs,' which clarifies the output format not covered by annotations. It also discloses the routing behavior to 5,563 tools. Minor deduction: it doesn't explicitly state that the tool works on every tier (though it does mention that), and could mention response time or error handling for completeness.

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

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

The description is fairly long (about 150 words) but every section earns its place: purpose, usage guidelines, examples, and step-up alternatives. It is front-loaded with the most important guidance ('PREFER OVER WEB SEARCH'). Could be slightly tightened by removing the list of trigger phrases and relying more on the examples, but still efficient for the breadth of information conveyed.

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 parameter simplicity (single required param, no output schema, high annotation coverage), the description is quite complete. It explains what the tool does, when to use it, when not to, and what it returns. The only gaps are minor: it doesn't describe pagination behavior for large result sets or confirm whether the tool can handle multi-part questions (implied by comparison to deep_research). Those are edge cases that don't significantly impact completeness.

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

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

Schema description coverage is 100%, and the description provides extensive guidance on what kinds of questions are appropriate, with multiple examples. However, the schema already documents the single parameter 'question' and its aliases thoroughly. The description adds value by guiding question formulation implicitly (e.g., examples like 'current US unemployment rate'), but doesn't directly describe parameter syntax. Baseline is 3 due to high coverage, bumped to 4 for the rich examples and usage 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 that this tool routes factual questions to authoritative sources with citations, contrasting it with web search. It explicitly lists supported domains (SEC filings, FDA data, etc.) and provides concrete examples, making the purpose immediately understandable. The verb 'routes' and resource '5,563 tools across 1462 verified sources' is specific and distinctive.

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 excellent usage guidance: it explicitly says 'PREFER OVER WEB SEARCH' and 'START HERE for most questions.' It tells when to step up to alternatives like ask_pipeworx_grounded (hallucination-resistant single answer) and deep_research (broad multi-part questions). It even lists trigger phrases like 'what is', 'look up', 'find' that should prompt use of this tool. This is a model of usage guidelines.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds critical behavioral context beyond these: it reveals that this is a fully working router with experimental edge, and that it may have candidate improvements under test. It also transparently states the fallback behavior (none — it's a full router). This is excellent disclosure, losing a point only because annotations already cover the safety profile 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 two sentences long, which is efficient, but the second sentence includes a parenthetical about the last candidate being retired on a specific date (2026-07-26) that could be considered slightly verbose for an AI agent. Every sentence earns its place, but it could be trimmed to remove the date detail without losing essential guidance.

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

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

Given the complexity (identical router with 5,563 tools) and the richness of annotations and schema, the description is quite thorough. It explains the tool's relationship to the stable version, its current experimental state, and what to expect from output (compared against stable router). With no output schema, this level of detail is sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not list individual parameters beyond the schema, but it adds value by confirming that the tool expects the same arguments as ask_pipeworx (5,563 tools' worth of routing context), and by emphasizing that these are 'aliases' for the question field. This contextual insight justifies a minor upgrade beyond baseline.

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

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

The description states a clear verb ('ask') and resource ('Pipeworx Beta'), and explicitly differentiates it from its sibling ask_pipeworx by noting it is a beta version with candidate routing improvements. This high-quality description leaves no ambiguity about the tool's purpose.

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

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

The description gives explicit guidance on when to use this tool ('when you want the newest routing'), and clarifies that results are compared against the stable router. It also proactively notes the current state (no active candidate), preventing misuse. No alternative tool names or exclusions are needed beyond what is already implied by the 'beta' label.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds rich behavioral context: it costs one extra LLM call, returns a structured response with evidence and refusal reasons, and explicitly states it extracts only from tool results. No contradiction with annotations.

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

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

The description is well-structured with the primary purpose front-loaded, followed by mechanism, return format, use cases, and trade-off. Every sentence is informative, though slightly longer than necessary (about 150 words). Still very effective.

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

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

Given the tool's complexity (routing, extraction, refusal handling) and no output schema, the description fully covers the return structure, refusal reasons, use cases, cost trade-off, and comparison with sibling. No gaps remain for an agent to select or 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 description coverage is 100% — all 6 parameters are aliases for 'question' and each has a description. The description does not add any parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate since no extra value is added.

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 'Hallucination-resistant answer mode for high-stakes reads' and explicitly differentiates from sibling 'ask_pipeworx' by noting it uses the same routing but adds an extraction step that only uses tool results. The verb 'extracts' and noun 'answer' make the specific verb+resource clear.

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

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

The description provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on…' and when-not-to: 'prefer ask_pipeworx for casual lookups.' It also gives example domains (financial verdicts, legal claims, medical lookups). This is complete and explicit.

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

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). It discloses parallel fan-out behavior, resolver contract fields, low-confidence match short-circuiting, closed/dead market status, wide-spread illiquidity flags, and resolution-rule risk (e.g., refund_50_50). It also describes fallback behavior for GDELT 429s, which is exactly the kind of contextual detail agents need.

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 labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, etc.) and front-loaded with the core purpose. It is very long, but every section contributes operational detail. A slight trim could improve readability without losing value, so it earns a 4 rather than a 5.

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

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

Given the tool's complexity and lack of an output schema, the description comprehensively covers response shapes (result.market, result.analysis, result.evidence), the resolver contract (match confidence, alternatives, suggestions), parent event extraction, news fallback fields, safety statuses, and resolution-rule risk. This provides everything an agent needs to invoke the tool and interpret results 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?

While the schema already describes all three parameters (100% coverage), the description enriches them with concrete examples and usage implications. It shows example inputs for 'market' (slug, URL, question text), explains 'depth' differences (quick vs thorough with default), and clarifies 'include_raw' tradeoffs (undersized vs full payloads). This adds real value beyond schema descriptions.

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

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

The description opens with a specific verb and resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It clearly differentiates itself from siblings by describing fan-out to category-specific data packs and returning an evidence packet with market-vs-model comparison. No other sibling tool claims this specific 'bet research' purpose.

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

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

Explicit usage guidance is provided: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This gives clear context for when to invoke. However, it does not explicitly mention when NOT to use or name alternative sibling tools, so it stops short of a full 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 mark it read-only, idempotent, and non-destructive, so the bar is lower. The description adds substantial behavior: data sources (SEC EDGAR/XBRL, FAERS/FDA), handling of off-calendar fiscal years, sorting by primary metric, and return format (paired data + 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?

The description is front-loaded with examples and the core purpose. Each sentence earns its place: trigger phrases, scope, type-specific behavior, sorting, output, and efficiency gain. It is dense but not padded, covering all key aspects without redundancy.

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

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

Despite no output schema, the description explains return content and format sufficiently. It addresses the two entity types, data sources, sorting, and the efficiency advantage. For a comparison tool with this complexity, it leaves no major gaps in understanding when and how to use it.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches parameter understanding by explaining what each 'type' value pulls (latest 10-K financials vs adverse-event/trial counts) and explicitly mentions the 2–5 count and ticker/CIK/name formats. It adds meaning beyond the schema's short 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 states the tool's purpose with a specific verb ('compare'), resource ('companies or drugs'), and scope ('2–5 ... in ONE parallel call'). It distinguishes from alternatives by noting it replaces 8–15 sequential lookups and gives concrete trigger phrases. This clearly separates it from siblings like entity_profile.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' and provides example triggers like 'X vs Y' and 'rank these companies.' It also explains the two type-specific use cases (company vs drug), giving clear context for when to invoke this tool.

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

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

The description adds extensive behavioral context beyond annotations: parallel decomposition across 5,563 tools, findings packet structure (verbatim evidence, confidence, gaps[], contradictions[]), hop field, citation_uri fetchability, semantic excerpting, response time expectations, and second-hop iteration behavior. Annotations already declare readOnly, openWorld, idempotent, non-destructive, and the description is fully consistent with 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 well-structured with front-loaded account requirement, clear purpose, usage alternatives, and detailed behavior. However, it is quite long (multiple dense paragraphs) and could be tightened without losing meaning. The organization is good, earning a 4 rather than a 5 for conciseness.

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 (2 parameters, no output schema, rich behavioral details), the description is remarkably complete. It covers input format, output format (findings packet with explicit fields), limitations (gaps[] for unanswered facets, contradictions[]), iteration behavior, response time, and link to citations. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description repeats the same information for question and depth but adds value beyond the schema by including account/pricing context (e.g., 'thorough needs a paid plan') and emphasizing that broad/multi-part questions are appropriate. This extra context justifies a 4 rather than baseline 3.

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

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

The description clearly states the tool performs 'grounded multi-source research across Pipeworx's 1462 STRUCTURED data sources in ONE call', distinguishes it from open-web search, and explicitly contrasts with ask_pipeworx for single lookups and breaking news. The verb 'research' and resource 'structured data sources' are specific and unambiguous.

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

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

The description provides explicit guidance: when to use (broad/multi-part questions over structured data), when not to use (single lookup → use ask_pipeworx, breaking news → prefer ask_pipeworx), and prerequisites (account required, paid plan for thorough depth). It also explains the tier-based behavior, leaving no ambiguity for the agent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)' and emphasizes 'ready to call directly, no second schema lookup needed.' This gives the agent confidence about the return format and saves a step, which is valuable behavioral disclosure.

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 and is composed of three sentences. The long enumeration of domains is purposeful for a discovery tool, but it makes the description slightly less tight than the two-sentence ideal. Still, each element earns its place and there is 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?

Given the tool's role as a discovery interface and the absence of an output schema, the description covers the essentials: what it does, when to use it, and what it returns (names, descriptions, full schemas, examples). It does not address edge cases like no results, but for this complexity level, the description is sufficiently complete to guide an agent.

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

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

Schema description coverage is 100%, with all parameters documented in the schema, including aliases and default/max values. The description itself does not add semantic meaning beyond what the schema already provides—it only repeats the notion of describing a task. Per the baseline for high schema coverage, this is a 3.

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

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

The description opens with a specific verb+resource: 'Find tools by describing the data or task.' It further clarifies the action set (browse, search, look up, discover) and enumerates the covered domains, making it unmistakable what this tool does. It also distinguishes itself from siblings by stating 'Call this FIRST... when you have many tools available... not just one answer,' which positions it as the discovery entry point rather than a direct execution tool.

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

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

The description explicitly states when to use the tool ('Use when you need to browse, search, look up, or discover what tools exist') and gives a strong contextual cue ('Call this FIRST when you have many tools available'). However, it lacks an explicit when-not or reference to alternative tools by name, so it misses the full 'when/when-not/alternatives' guidance that would earn 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 the tool read-only, idempotent, open-world, and non-destructive. The description adds behavior context beyond annotations: it fans out across multiple sources, mentions the USPTO API sunset with soft-fail behavior, and the GDELT→GNews fallback. It also clarifies the return structure with 'up to 5' filings and sorted fundamentals.

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

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

The description is lengthy but information-dense; it front-loads example utterances and covers purpose, usage, sources, return fields, and limitations. Each sentence contributes value, though the seven example phrases at the start are somewhat redundant and could be trimmed for brevity.

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

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

With no output schema, the description carries full responsibility for explaining return values. It enumerates the returned fields (cik, company_name, recent_filings with URIs, fundamentals, patents, news, LEI) and notes fallbacks, soft-fail behavior, and parameter constraints, giving an agent a complete picture of the tool's capabilities and limitations.

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 schema already describes both parameters (type enum and value with ticker/CIK examples and name restriction). The description's parameter guidance ('Pass ticker "AAPL" or zero-padded CIK...') essentially duplicates the schema text, adding no new semantic meaning.

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

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

The description clearly states that the tool returns a 'full cross-source profile of a US public company in ONE parallel call' and lists the specific sources and return fields. It distinguishes itself from siblings by saying 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and contrasts with resolve_entity for name handling.

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 example user intents ('Tell me about X', 'research Acme', etc.) and states when to prefer this tool over chaining single-pack lookups. It also gives an exclusion: 'names not supported (use resolve_entity first if you only have a name)'.

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

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

Beyond the annotations (destructiveHint, idempotentHint), the description clarifies what is deleted ('a previously stored memory by key') and why it might be necessary (stale, done, sensitive data). It does not elaborate on edge cases like missing keys, but the idempotentHint annotation covers that.

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 deliver the core action and usage context. Front-loaded with the verb 'Delete,' no wasted words.

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

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

For a single-parameter tool with strong annotations and no output schema, the description covers the purpose, usage, and related tools thoroughly. It is fully sufficient for an agent to select and 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% and the schema already describes 'key' as 'Memory key to delete.' The description only repeats 'by key' without adding new nuance, 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 opens with a specific verb+resource: 'Delete a previously stored memory by key.' This clearly distinguishes it from sibling tools like remember and recall, which handle storing and retrieving memories.

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 contexts ('context is stale, the task is done, or you want to clear sensitive data') and pairs the tool with 'remember and recall,' offering actionable guidance on related alternatives.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints, and the description complements them by detailing the process: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' This adds behavioral context (network fetch, extraction logic) without contradicting any annotations, though it doesn't disclose rate limits or failure modes.

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 tightly structured: a direct opening sentence, a process sentence, an output sentence, and a concise 'Useful for' list. Every sentence contributes meaning, and the text is front-loaded with the primary action. No redundant or filler content.

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

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

Given the tool's simplicity (2 params, no output schema) and rich annotations, the description adequately explains what it does, the output format, and use cases. It is nearly complete, though it could mention that it only produces the standard format and not customized variants, but that is a minor 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 description coverage is 100%, so the baseline is 3. The description adds marginal context by mentioning 'key links' which relates to max_links, but it does not elaborate on parameter syntax or defaults beyond what the schema already provides. Thus, it meets the baseline without significant extra value.

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

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

The description clearly states the tool's function with a specific verb+resource: 'Generate a production-ready llms.txt file for any URL.' It also differentiates from siblings by focusing on file generation rather than mere auditing, and the use cases mention competitor auditing which ties to sibling tools but the primary purpose is 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 provides clear contexts for use: 'getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.' However, it does not explicitly exclude alternatives or mention when to choose a different tool (e.g., ai_visibility_check) for deeper analysis, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context by specifying the scope ('caller's') and the exact return fields (id, type, params, etc.), which is not present in the schema or 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?

Exactly two sentences: the first states the action and return fields, the second states the intended use cases. No filler, every word earns its place.

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

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

For a simple list tool with no output schema, the description includes the return fields and explicit usage guidance. Annotations handle safety semantics. This is complete for its complexity level.

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

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

The schema has 100% coverage for its single parameter, include_inactive, with a clear description. The tool description does not add any additional meaning about this parameter, so the baseline of 3 is appropriate given that the schema does the heavy lifting.

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

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

The description opens with 'List the caller's active subscriptions,' a specific verb+resource statement that clearly distinguishes this from sibling tools like subscribe and unsubscribe. It also enumerates the fields returned, further clarifying the tool's exact purpose.

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

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

The second sentence explicitly tells the caller when to use this: 'before adding more' subscriptions or 'to find an id to cancel.' This gives clear usage context, though it doesn't explicitly name alternative tools or state when not to use it, which is why it doesn't reach 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?

The annotations provide no safety/behavior hints (all false), so the description compensates by disclosing the claim_token mechanism, rate limiting, quota-free nature, and how the team processes feedback. This goes beyond structured data and fully informs the agent of side effects.

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

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

Though longer than typical, every sentence adds necessary context: usage scope, exclusions, workflow, rate limits. It's front-loaded with the core action and structured logically, so it is concise in 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?

With no output schema, the description fully explains the return token behavior and what to expect. It covers edge cases (different MCP servers) and operational details, making it complete for this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the claim_token round-trip flow and the 'no other arguments' condition, which isn't fully captured in the schema alone. This earns 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 clear verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates specific feedback types (bug, feature, data_gap, praise) and explicitly distinguishes from sibling research tools by limiting scope to Pipeworx-served tools.

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

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

It provides explicit when-to-use guidance: 'Use when a tool returns wrong/stale data...' and when-not-to-use: 'if the tool came from a different MCP server... file it with that server instead.' This is exemplary and goes beyond vague context.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds meaningful behavioral details: 'Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.' This gives agents important context about freshness, privacy, and data provenance.

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 efficiently structured: a one-sentence hook, a clear returns statement, a bulleted use-case list, and final transparency notes. Every sentence contributes value, and it is front-loaded with the core purpose.

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

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

With no output schema, the description explains returns ('top tools, top packs, and total call volume' and '(pack, tool, count)') and covers caching, privacy, and use cases. For a simple trend data tool, this is sufficient contextual completeness.

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

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

The single `window` parameter is fully documented in the schema with enum values and semantics. The description repeats these semantics ('Shorter windows surface what's hot right now; longer windows show steady-state demand') without adding new information, so the 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 a specific verb ('Returns') and resource ('top tools, top packs, and total call volume'), and frames it as 'what other AI agents are calling on Pipeworx right now.' This distinguishes it from sibling discovery tools by emphasizing aggregate usage trends.

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 an explicit 'Useful for' list with three concrete scenarios (discovering hot data sources, confirming canonical tools, aligning with agent needs). However, it does not name alternative tools or explicitly state when not to use it, so it falls short of a 5.

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

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

The description reveals behavioral details beyond annotations: the Jaccard similarity threshold, placeholder filtering rules, partition-check sum expectations, and the fill check logic that warns "do not trade it" if the edge is not realizable. This adds significant context on how the tool behaves in various scenarios.

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

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

The description is long but well-structured with clear sections for modes, semantic anchor, partition filter, response format, and fill check. It is front-loaded with the core purpose and immediately explains the no-arg vs event vs topic options. Some details, like the exact Jaccard threshold, may be more than needed but add depth without being wasteful.

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

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

Given the tool's complexity and the lack of an output schema, the description thoroughly covers response shapes, edge cases (e.g., placeholder fractions), and how to interpret results (realizable_edge_pp ≤ 0 means don't trade). It also points to a sibling tool for related but distinct functionality, ensuring the agent understands the full context.

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

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

The description provides rich semantic meaning for both parameters event and topic, with concrete slug examples and explanations of what each mode does. It also covers the no-arg behavior, which is essential since the schema marks no parameters as required but the tool has a meaningful default action.

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 and resource: "Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks." It clearly distinguishes from sibling tools like polymarket_edges, polymarket_edge_tracker, and polymarket_fill_risk by focusing on arbitrage detection methods.

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

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

Explicit usage guidance is provided: "Call with NO args for a trending_scan... pass event for the strongest per-event partition_check, or topic for a themed cross-event scan." It also differentiates when each mode is appropriate and references a sibling tool for custom sizing, giving clear when-to-use and when-not-to-use direction.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's transparency burden is low. Yet it goes far beyond with details on model families (lognormal barrier, GDELT ratio), edge computation (net of slippage, Kelly caps), output structure, diagnostics for empty segments, 24h-move warnings, and 1h caching. No contradictions with annotations.

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

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

The description is front-loaded with purpose and uses uppercase labels and numbered lists to organize dense information, making it scannable. However, it is verbose and contains a minor inconsistency: 'FIVE MODEL FAMILIES' but only four are enumerated. The technical jargon is heavy but mostly earns its place given the tool's complexity.

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

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

With no output schema, the description must explain return values, and it does thoroughly: per-opportunity fields, by_segment structure, fed_candidates/fed_note, and _diagnostics to explain why segments are empty. It also covers caching, knobs, and edge computation. For a 9-parameter tool with complex model logic, this is highly complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics, particularly for min_partition_leg_kelly (why min_kelly doesn't apply to partitions) and category_filter (mapping to model families). It also ties edge_pp_net and slippage_pp to execution costs. This elevates beyond schema-literal documentation, though not every parameter benefits equally.

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+outcome: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This clearly distinguishes the tool from siblings by focusing on Pipeworx disagreement and the 'what should I bet on today' use case, avoiding the need to page hundreds of markets. The purpose is unmistakable.

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

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

The description conveys a strong sense of when to use the tool ('what should I bet on today') and explains tradeable-edge knobs and response segments. However, it does not explicitly compare with sibling tools or state when not to use this tool. Fed bets are mentioned as excluded from ranking, but that's an output note, not tool selection 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 mark the tool as read-only, idempotent, and non-destructive. The description goes well beyond this by disclosing response structure, decay computation details, snapshot gap behavior, and the 60-day TTL limitation. These are valuable behavioral nuances not derivable from 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?

Though long, the description is well-structured with clear sections (Args, RESPONSE, LIMITS) and is front-loaded with the core purpose. Every sentence adds substantive information about behavior or output, and the format makes it easy to parse.

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

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

With no output schema, the description fully describes the response fields (tracked[], expired[], snapshot_dates[]) and their meaning. It also covers data availability limitations, snapshot TTL, and computation caveats, making it complete for an agent to decide and 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, but the description adds useful context: 'days' is explained as lookback with default and max, 'window' is called a 'snapshot family' and tied to the cache-miss snapshot mechanism. This helps the agent understand the meaning behind the parameters beyond their raw names.

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

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

The description clearly states the tool's function: tracking edge persistence and decay from daily polymarket_edges snapshots. It distinguishes itself from siblings by focusing on historical persistence ('how long has this edge existed and is it shrinking?') rather than current edge lists.

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

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

The description gives clear context for when to use the tool: when you need to know whether an edge is fresh or decaying, and how long it has persisted. It does not explicitly name alternatives like polymarket_edges, but the relationship to snapshots and the decision heuristic ('a fresh wide edge and a 3-week-old wide edge are different trades') imply the intended use case strongly.

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 define readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond those: it walks the ladder, returns specific metrics, and discloses failure modes like forced directional risk and partial baskets converting arbs into unhedged positions. No contradiction with annotations.

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

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

The description is long but appropriately so for a tool with two modes, four parameters, and complex return logic. It is front-loaded with the core purpose, uses clear SINGLE-MARKET/BASKET sections, and every sentence conveys necessary information. No fluff.

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

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

Given the tool's complexity and lack of output schema, the description fully lists return values for both modes, explains edge cases (thin books, forced directional risk), and gives sizing context. It is complete enough for an agent to invoke correctly and 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?

Although the schema has 100% coverage, the description adds critical semantics that the schema doesn't convey: how size_usd is interpreted differently in single-market (spend vs proceeds) vs basket (settlement notional per share), and how side defaults differ between modes. This meaningfully extends the schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: checking realizable-vs-theoretical edge against live CLOB order-book depth. It distinguishes between single-market and basket modes, and explicitly positions itself as a pre-trade risk check for polymarket_arbitrage and polymarket_edges trades, distinguishing it from sibling tools.

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

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

Provides explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains the trade-off between modes and why partial fills are dangerous, giving actionable context for tool 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 the annotations (readOnlyHint, idempotentHint), the description discloses behavioral nuances: compatibility_warning conditions, temporal alignment constraints, skipped_cross_type/subtype counters, and the warning that most pre-mapped topics return warnings. This is rich, non-obvious behavior not visible in the schema.

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 purpose and mode structure. Every sentence adds substantive detail about safety fields and limitations. Slight redundancy exists (e.g., repeated warnings), but overall it is efficiently organized for a complex tool.

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

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

Given three optional parameters, no output schema, and many semantic edge cases, the description fully covers response structure, safety fields, mode behavior, and limitations. It even preempts misuse by warning that pre-mapped does not equal tradeable.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the two logical modes (topic shortcuts vs explicit ticker/slug override) and how parameters interact, including override behavior. This goes beyond the schema's field descriptions.

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

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

The description clearly states the tool's function: cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes itself from siblings like polymarket_arbitrage by emphasizing the two-venue comparison and the safety fields for assessing comparability.

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 the tool is meaningful (equivalent bet shapes) and when it isn't (compatibility_warning, temporal misalignment), and describes two usage modes. However, it does not explicitly name alternative tools for single-venue analysis or situations where a different sibling would be 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?

Annotations already declare readOnly and idempotent, and the description adds meaningful behavioral context: scoping to 'anonymous IP, BYO key hash, or account ID', the ability to list all keys when omitting the argument, and the data origin ('previously saved via remember'). This goes beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the main action, and every phrase adds value (purpose, usage, scoping, pairing). No redundancy or 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?

For a simple read-only tool with one optional parameter and no output schema, the description fully covers purpose, usage, scoping, and related tools. It omits only minor details like error behavior, which is acceptable given the tool's simplicity.

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

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

Schema coverage is 100% for the single 'key' parameter, and the schema already describes the 'omit to list' behavior. The description repeats this without adding new parameter-specific meaning, so it meets the baseline but doesn't exceed it.

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

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

The description clearly states the tool's function with a specific verb ('retrieve') and resource ('value previously saved via remember'), and explicitly distinguishes it from siblings by mentioning 'list all saved keys' and pairing with 'remember' and 'forget'. This differentiates it from other tools like search_within or discover_tools.

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

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

The description provides explicit usage context: 'Use to look up context the agent stored earlier... without re-deriving it from scratch.' It also names alternatives by pairing with remember/forget, giving clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive aspects. The description adds important behavior beyond annotations: the mark_read flag causes an internal state change (only newer events appear next call), and polling is fine, which is not implied by the annotations. This gives useful context without contradiction.

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

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

The description is five sentences, each earning its place: main action, return format, filtering, mark_read behavior, and polling/alternate access. It is front-loaded with the core purpose, and every sentence adds distinct information without padding or repetition.

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

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

Despite having no output schema, the description fully explains the return payload (source, citation_uri, raw event), the filtering options, the state change semantics of mark_read, and the alternative HTTP access. Combined with rich annotations, the agent has all necessary context to invoke this tool safely and correctly.

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

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

The input schema covers all parameters with descriptions (100% coverage), establishing a baseline of 3. The description adds value by giving a concrete example for type ("sec_8k"), clarifying that since expects an ISO timestamp, and explaining the consequence of mark_read (subsequent calls return only newer events). These enrich the schema's otherwise terse 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 opens with a specific verb ('Pull') and resource ('fired events from your subscription feed'), clearly distinguishing this from siblings like recent_changes or list_subscriptions. It further specifies the return contents (source, citation_uri, raw payload), leaving no ambiguity about the tool's function.

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

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

The description provides clear context for use: retrieving recent alerts from the feed, with optional filters and polling behavior explicitly deemed acceptable. It also points to an alternative HTTP endpoint for scripts/dashboards, but does not explicitly contrast against sibling MCP tools, which prevents 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?

The description richly discloses behavior beyond the readOnly/idempotent annotations: it fans out to SEC EDGAR, GDELT→GNews with a fallback, and USPTO with a 'soft-fails' note due to PatentsView API sunset. This level of transparency about failure modes and data sources is beyond what annotations provide.

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

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

The description is long but well-structured, with a front-loaded intent phrase and methodical breakdown of sources and fallbacks. It could be tightened by trimming some repetitive examples, but it remains readable and informative.

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

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

For a complex tool with no output schema, the description explains the return shape (changes[], total_changes, citation URIs) and source-specific failure modes. It also provides an alternative, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100% and the description does not add much beyond the schema for `value`, `type`, or `since`. It restates the same ISO/relative shorthand for `since` and CIK format for `value`, so the 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 explicitly defines the tool as a 'change feed for a company' and provides natural language examples that clarify intent. It also distinguishes from entity_profile by explicitly noting when to use that alternative, making the tool's scope clear.

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

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

The description gives direct usage guidance: use for 'what's new' queries and explicitly says 'Use entity_profile instead when you want the static profile... regardless of window.' This clearly frames when to select this tool over a sibling.

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

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

Beyond the annotations (idempotentHint, destructiveHint), the description discloses that storage is scoped by identifier, mentions persistence for authenticated users vs 24-hour retention for anonymous sessions, and explains the key-value pair structure. This adds meaningful behavioral context.

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

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

The description is concise, front-loaded with the core purpose, and every sentence adds value – use cases, behavior, persistence, and companion tools. 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?

For a simple tool with full schema coverage and no output schema, the description covers purpose, usage scenarios, persistence semantics, and integration with related tools (recall/forget). It is fully sufficient for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so the description doesn't need to explain much. It adds the context that storage is key-value based and scoped by identifier, reinforcing the schema's examples without introducing new syntax rules.

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

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

The description starts with 'Save data the agent will need to reuse later' – a specific verb and resource that clearly defines the tool's function. It distinguishes itself from sibling tools by explicitly mentioning recall and forget for complementary operations.

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

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

It provides explicit guidance on when to use the tool ('Use when you discover something worth carrying forward') with concrete examples. It also names the companion tools (recall, forget), giving clear context and alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds significant behavioral context: it cascades through several lookup endpoints, degrades gracefully (if GLEIF or OpenFIGI is unavailable, EDGAR identifiers still return), and labels identifiers by source. It also states that unresolved identifiers are explicitly listed, which is beyond the annotations. This provides a comprehensive behavioral picture.

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 example queries, which is excellent. It is structured with bullet points for supported types and includes detailed technical notes. However, it is relatively long for a tool description, containing several sentences that could be considered verbose. Still, nearly every sentence adds value, and the structure is clear. Only slight inefficiency prevents a perfect score.

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

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

Given the tool's complexity (multiple entity types, cascading lookups, multiple identifier sources) and the absence of an output schema, the description is remarkably complete. It explains what is returned (canonical IDs, labels, source, unresolved list), graceful degradation, and the overarching behavior. No critical gaps are present.

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

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

Schema coverage is 100% with both parameters described. The description enriches these by providing concrete examples for 'value' (ticker, CIK, ISIN, name) and explaining each 'type' in detail (company with cross-source identity spine, drug with RxCUI). It also clarifies input formats (e.g., ISIN like 'CH0038863350' resolves to legal entity). This adds significant value beyond the schema.

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

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

The description explicitly states the tool resolves user-spoken names to canonical/official identifiers, with clear examples like 'What's the ticker for…' and 'find the CIK for…'. It distinguishes itself from siblings by being the primary name-to-ID tool, reinforced by 'Use FIRST whenever you have a name but need an ID.' The purpose is specific and clearly communicated.

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 strong usage guidance: 'Use FIRST whenever you have a name but need an ID.' It also specifies that it replaces 2-3 manual lookups, implying efficiency. While it does not explicitly list when not to use it, the context of being the first tool for name-to-ID resolution is sufficient. No alternative tools are mentioned, but the guideline 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 readOnly and idempotent, but the description adds behavioral details: it probes each entity, ranks by score, and returns a ranked list with score, confidence, and signal density. This goes beyond the safety hints to explain what the tool actually does internally.

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, each earning its place: first states purpose, second explains mechanism, third provides use case and output format. No redundant phrasing or fluff.

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

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

Given the tool's moderate complexity (4 params, no output schema), the description is complete: it covers the input semantics, the process, and the expected return format. Annotations cover safety, and the schema covers all parameters, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema by explaining that the first entity in 'entities' is treated as the subject, and that using 'anthropic' in models requires the '_apiKey'. This helps the agent correctly assemble parameters.

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 'Compare AI visibility across multiple entities side-by-side', which is a specific verb+resource. It distinguishes from the sibling ai_visibility_check by emphasizing multi-entity comparison and ranking, and from compare_entities by focusing on AI visibility specifically.

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

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

It provides a clear use case ('competitive AI-marketing audits') and an example query, implying when this is useful. It does not explicitly state when not to use it or name direct alternatives, but the mention of probing with ai_visibility_check suggests the single-entity alternative.

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 (readOnly, idempotent, openWorld, non-destructive), the description discloses performance characteristics (first bundlephobia measurement can take 5-30s), partial failure behavior (sources_failed will list it, rest still returns), and the default version behavior. This adds significant context without contradicting any annotations.

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

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

The description is dense but every sentence earns its place. It opens with purpose, then usage, then output summary, then ecosystem scope, then failure behavior. Structured logically with no redundancy or fluff, appropriately sized for the tool's complexity.

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

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

For a composite tool with no output schema, the description thoroughly covers return values (summary block fields, per-advisory detail, links, alternative versions), ecosystem limitations, performance caveats, and graceful degradation. The only minor omission is explicit error handling for invalid package names, but the graceful failure note covers unlisted scenarios adequately.

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

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

Schema coverage is 100%, so the baseline is 3. The description correctly references version defaults and accepted package names, but it does not add meaning beyond what the schema already provides. The description's mention of 'recent alternative versions' pertains to output, not 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 opens with a specific verb and resource: 'Composite "should I add this npm package to my project" check in ONE call' and details the data sources (deps.dev, bundlephobia). It clearly distinguishes itself from sibling tools by being npm-package-specific and composite, not just a generic research or scan tool.

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

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

The description explicitly states when to use the tool: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also provides an exclusion and alternative: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly', guiding the agent to alternative behavior for non-npm packages.

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 readOnlyHint/idempotentHint annotations, the description discloses several non-obvious behaviors: 200K character truncation with flagging, BGE-base-en embeddings with cosine similarity, 500-char overlapping windows, and that results include character offsets and similarity scores. This gives the agent accurate expectations about output shape and limitations, and it contradicts no annotations.

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

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

The description is dense but efficient: it leads with purpose, then usage context, then technical implementation details. Every sentence adds a new piece of information, though the middle section could be slightly tightened. It's not rambling or repetitive, earning a 4.

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

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

With no output schema, the description correctly explains what is returned (top-N passages with offsets and similarity scores). It covers input requirements (200K cap), method (embeddings/cosine), and relationship to a sibling tool. Given the tool's complexity, the description is thorough and self-contained.

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

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

The input schema already covers 100% of parameters with descriptions. The description adds semantic richness: for 'text' it clarifies it should be a previously fetched record with examples, and for 'query' it provides natural-language query examples. It doesn't add detail to 'limit' beyond the schema's max/range, so a 4 is appropriate.

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

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

The description opens with 'Semantic search INSIDE a fetched record', giving a specific verb (search) and resource (the provided text). It distinguishes from siblings by emphasizing that the text is already pulled, as opposed to fetch-first tools like ask_pipeworx_grounded. The parenthetical examples (SEC 10-K, article, long tool result) further pin the purpose.

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

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

It explicitly gives the use case: 'Use when the record is too big to cram into the prompt' and states that it 'saves context'. It also pairs with ask_pipeworx_grounded, indicating a complementary workflow. However, it doesn't explicitly state when NOT to use it (e.g., when the text is short or you need the whole document), so it's not a full 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 indicate this is a write and idempotent, but the description goes further by disclosing the OAuth account requirement, feed always-on behavior, SMS rate limits, phone verification prerequisite, and webhook auto-disable after 10 consecutive failures. These are genuine behavioral traits beyond the structured annotations.

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

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

The description is dense but every sentence serves a purpose: purpose, auth requirement, supported types with examples, and delivery options. It is well-structured and front-loaded with the core function, displaying no wasted words or redundant 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?

Despite having no output schema, the description covers the return value (new subscription id), auth prerequisites, all supported types, parameter examples, delivery channels, and technical caveats (phone verification, SMS cap, webhook signing secret). Given the tool's nested parameters and multiple modes, this is remarkably 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?

The schema covers all parameters at 100%, so the baseline is 3. The description adds value with concrete examples for each type (e.g., sec_8k items, polymarket topic), clarifies the 'params' structure, and explains delivery channel details like phone verification and the 10/day SMS cap. This extra context justifies a score above baseline.

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

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

The description opens with 'Create a proactive monitoring subscription to a live-data event stream,' clearly specifying the action and resource. It also states the return value (new subscription id) and distinguishes itself from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

The description provides clear context on when to use this tool: for setting up proactive monitoring subscriptions. It specifies supported subscription types and delivery channels, but does not explicitly mention alternatives or exclusion scenarios (e.g., 'use list_subscriptions to view existing'). This meets the 'clear context, no exclusions' level.

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, covering the safety profile. The description adds useful context beyond annotations: the tool draws from the live catalog, returns category-bucketed questions with tool/argument shapes, and supports optional topic focus. 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 long but dense with useful onboarding information. It lacks formal structure (single paragraph) and includes repetitive slash-separated example phrases, but it front-loads usability with common questions and efficiently covers purpose, return shape, and parameter behavior. Slightly overlong yet justifiable.

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, so the description must explain return semantics—it does so by stating 'category-bucketed example questions' each with 'the exact tool + argument shape'. It also explains no-arg vs. topic behavior and the meta-tool learning benefit, making it self-contained for first-time use.

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

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

The schema covers the single optional 'topic' parameter 100%, including a description that enumerates allowed values. The description repeats examples like 'finance' and 'pharma' but adds no new semantic details beyond the schema. Baseline 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states the tool is the onboarding entry point that returns category-bucketed example questions with the exact tool and argument shape for each. It distinguishes itself by saying 'Use this FIRST' and naming the meta-tools, separating it from related tools like discover_tools. The verb and resource are specific.

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

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

Explicitly provides when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you' and 'or to learn how to call the meta-tools'. It also gives guidance on how to call with no arguments vs. passing a topic, making usage instructions 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?

The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds valuable context by noting this is a 'third-party mirror' and that 'some fields may be blank', indicating potential data incompleteness and reliability constraints beyond what annotations provide.

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

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

The description is two sentences. The first sentence states the purpose and required parameters; the second lists return values and a caveat. Every word earns its place, with no redundancy or 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?

There is no output schema, so the description appropriately lists what is returned: agency contact info, procurement category, budget/award amount, deadlines, status, and a PCC link. It also notes the third-party mirror and potential blank fields, providing a complete picture for a single-tender detail 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 describes both parameters with 100% coverage, including the note that they come from a search result. The description goes further by explicitly naming the source as 'a taiwan_search_tenders result', linking the parameters to a specific sibling tool and clarifying their provenance.

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

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

The description begins with 'Get full detail for one Taiwan government procurement tender', clearly stating a specific verb and resource. It distinguishes itself from sibling tools like taiwan_search_tenders (which searches) and taiwan_list_by_date by focusing on retrieving full detail for a single tender using specific identifiers.

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 that unit_id and job_number must come from a taiwan_search_tenders result, providing a clear prerequisite and context for when to use this tool. It does not explicitly mention when not to use it or name direct alternatives, but the search-then-detail flow is clearly implied.

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

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

The description adds behavioral context beyond the annotations by disclosing that this is a third-party mirror and results are 'best-effort', which implies potential incompleteness or staleness. It also states what the tool returns (id, title, agency, announcement type, associated companies), which is useful. These go beyond the readOnly/openWorld/idempotent hints.

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

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

The description is concise and front-loaded with the action ('List') and subject. It packs essential details—format, default, output fields, and caveat—into four short sentences. While not as terse as a two-sentence ideal, every sentence contributes useful information and there is no redundancy or fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description is highly complete. It explains the purpose, the exact date format, the default value, the returned fields, and the best-effort nature of the third-party mirror. This covers all aspects needed for an agent to select and 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?

The input schema covers 100% of the parameter, including its format and default behavior. The description repeats this same information ('Pass a date as YYYYMMDD... defaults to today') without adding new semantic detail. Thus, the description provides no value beyond the schema, consistent with the baseline score of 3.

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

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

The description clearly states the tool lists Taiwan government procurement tenders published on a given date, with a specific verb ('List') and resource ('tenders'). It also implies differentiation from siblings by focusing on date-based listing, and includes the source (PCC) and the g0v mirror. This distinguishes it from search-by-company or general search tools.

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

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

The description provides clear context for when to use the tool: to list tenders published on a specific date, with the option and syntax for the date parameter and a default to today. However, it does not explicitly mention alternative tools or provide exclusions, such as 'for keyword search use taiwan_search_tenders', so it lacks explicit when-not guidance.

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

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

Annotations already declare the tool as read-only, non-destructive, open-world, and idempotent. The description adds important context beyond annotations: it is a 'third-party mirror' with 'best-effort' results, meaning data may be incomplete or delayed. It also describes the return fields, which is valuable given the lack of an output schema.

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: purpose, usage instructions, and return value. It is compact, front-loaded, and every sentence adds value. No wasted words.

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

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

For a simple two-parameter lookup tool, the description covers the essential information: the source, the query format, examples, the shape of results, and a caveat about reliability. Sibling tools are distinct, and the schema covers parameter details. No critical gaps remain.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces that 'query' expects a Chinese company name and includes examples, but does not add additional meaning beyond the schema descriptions. It does not mention the 'page' parameter in the description, though the schema already handles it.

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 ('Search') and identifies the resource ('Taiwan government procurement tenders') and the key dimension ('by company / vendor name'). It clearly distinguishes from sibling tools like taiwan_list_by_date (by date) and taiwan_get_tender (likely fetch by id) by focusing on company-based lookup.

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

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

The description clearly implies the use case: when you have a company name and want to find tenders a company bid on or won. It provides example queries and notes the Chinese-language requirement. However, it does not explicitly contrast with alternatives or state when not to use this tool, which would make it 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 readOnly, idempotent, and non-destructive. The description adds valuable context: it's a third-party mirror with best-effort results, and lists return fields. No contradiction with annotations, and additional caveats improve transparency.

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

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

Three sentences cover purpose, parameters, return fields, and follow-up tool. Front-loaded with the primary action, no redundant phrasing, every sentence earns its place.

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

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

With 2 params, full schema coverage, and annotations, the description is complete. It also fills the lack of an output schema by listing the return fields (tender id, title, agency, announcement type, date, category) and explains the result structure. The third-party caveat rounds out the context.

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

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

Schema coverage is 100% and both params have descriptions. The description adds further meaning by clarifying 'query' is a title keyword with Chinese/English examples ('電腦', 'AI', '消防'), and 'page' is 1-based. This exceeds the schema baseline.

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

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

The description clearly states the tool searches Taiwan government procurement tenders by title keyword, specifying the source (政府電子採購網/PCC via g0v mirror). It differentiates from siblings by mentioning taiwan_get_tender for full detail and implying keyword-based search vs other search tools.

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

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

It provides explicit follow-up guidance (use taiwan_get_tender with returned unit_id + job_number for full detail), and notes results are best-effort. It doesn't explicitly compare against taiwan_list_by_date or taiwan_search_by_company, but offers enough context for the intended use case.

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

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

The description discloses key behavioral traits beyond the annotations: ownership enforcement ('only cancel your own subscriptions') and the non-destructive nature ('row is deactivated, not deleted'). This adds meaningful context that annotations alone do not provide, such as the persistence of historical events in recent_alerts.

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 action, then efficient elaborations on ownership and deactivation. Every sentence earns its place with no filler or repetition of schema details.

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

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

For a simple single-parameter tool with no output schema, this description covers all necessary context: the action, the constraint (ownership), the side effect (deactivation), and the downstream availability of historical events. No significant 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?

The schema already describes the id parameter well ('Subscription id (uuid) returned by subscribe'). The description reinforces this by saying 'by id' and adds ownership semantics ('your own subscriptions'), which gives the parameter practical meaning beyond the schema's technical definition.

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: 'Cancel a subscription by id.' This clearly distinguishes it from siblings like subscribe and list_subscriptions, and the title confirms the alert context. It also adds ownership enforcement, further clarifying the tool's exact role.

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

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

The description implies when to use this tool (when you need to cancel a subscription) and provides important context about consequences (deactivation vs deletion, historical events remain via recent_alerts). It does not explicitly name alternatives or state exclusions, but the sibling set and clear purpose make the usage context obvious.

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

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

The description discloses several critical behavioral nuances: the distinction between could_not_verify (check did not happen) and unsupported (no source found), the presence of verification_error{stage,detail}, and the routing to 'SEC EDGAR + XBRL fast path' vs 'grounded pipeline.' This goes well beyond the annotations, which only indicate read-only and idempotent behavior.

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

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

The description is longer than average but front-loaded with trigger phrases and organized into routing, return, and caller warnings. Every sentence adds information (e.g., the could_not_verify warning is critical), though the 'Replaces 4–6 sequential calls' value proposition could be trimmed. Still, it remains 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 the absence of an output schema, the description clearly enumerates the possible verdicts, the returned actual value with citation, reasoning, and the semantics of error cases. It also covers the two distinct failure modes and instructs callers on how to handle them. This makes the tool self-contained for an agent.

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

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

The input schema already describes both parameters (claim and tolerance_pct) with 100% coverage. The description adds extra semantics for tolerance_pct, explaining that it overrides the claim wording's implied tolerance, defaults at 5, and can be set to 1–2 for hallucination detection — beyond what the schema provides.

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

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

The description opens with natural-language trigger phrases and defines exactly what the tool does: 'natural-language claim verification against authoritative sources.' It explicitly scopes when to use it ('Use whenever the agent needs to check whether something a user said is factually correct') and distinguishes it from multi-step alternatives by noting it replaces 4–6 sequential calls.

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 a clear directive on when to use ('Use whenever...') and explains the two routing paths (SEC EDGAR for company-financial, grounded pipeline for all else). However, it does not explicitly name sibling tools to use instead or provide 'when not to use' conditions, so it falls short of the top criterion.

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