Intact

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds that it makes external API calls to Workers AI and optionally Anthropic, and that the user pays Anthropic directly when using that model. This is useful behavioral context beyond annotations, though it does not mention rate limits or error handling.

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

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

The description is four sentences that flow logically: action, default behavior, return format, use cases. Every sentence adds value without repetition 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?

Despite no output schema, the description fully explains the return structure (per-model score, confidence, signals, raw_response, plus combined view). With 4 parameters fully described and clear use cases, the tool is self-contained and understandable.

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 documents each parameter. The description adds value by explaining the default model, the need for _apiKey only for Anthropic, and the return format. This enhances understanding beyond the bare schema.

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

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

The description clearly states the tool probes LLMs for knowledge about entities and scores visibility (0-100). It specifies the default model and the option to add Anthropic. This differentiates it from siblings like 'scan_competitor_ai_presence' which likely does a different task.

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 lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring). It explains the default model and the API key requirement for Anthropic. However, it does not explicitly state when not to use it or contrast with alternatives, though the context implies its niche.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it routes to thousands of tools, fills arguments, and returns stable citation URIs. It also notes 'works on every tier, one fast call,' which helps set operational expectations.

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

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

Despite being a dense 200-word block, every sentence contributes new actionable information: preference over web search, routing behavior, triggers, examples, default status, escalation path, and a note on breaking news. It is front-loaded with the highest-value guidance and contains no redundant phrases.

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

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

The tool has no output schema, but the description explicitly states it 'returns the structured answer with stable pipeworx:// citation URIs,' covering the return format. It also explains the tool's broad coverage and provides examples for common use cases. Given the tool's complexity as a meta-router, this is a complete and self-contained 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?

Input schema coverage is 100% and the schema already describes the question parameter with aliases and a clear example. The description adds example queries and triggers, but doesn't elaborate on parameter syntax or formats beyond what the schema provides. Therefore 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 what the tool does: 'Routes the question to the right one of 5,529 tools across 1455 verified sources, returns the structured answer with stable pipeworx:// citation URIs.' It also positions itself as the default entry point versus siblings like ask_pipeworx_grounded and deep_research, making its scope 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?

Explicit guidance is provided: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and 'Step up only when needed' with specific alternative tools for grounded answers or broad research. Trigger phrases ('what is', 'look up', 'find', etc.) and examples make selection criteria clear.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive hints. The description adds experimental-beta context, live candidate testing behavior, and explicitly states it is a full working router with no fallback, providing valuable behavioral transparency beyond the annotations.

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

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

The description is front-loaded with the key beta identity and provides necessary context about candidate testing and current state. All four sentences add value, though some phrasing could be tightened without losing meaning.

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

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

As a simple single-question router with no output schema, the description fully addresses identity, experimental behavior, usage, and response shape equivalence. It is complete 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 fully documents the question parameter and all aliases with 100% coverage, so the description need not repeat those details. The description only adds that it uses the same arguments as ask_pipeworx, which offers slight confirmation but no new parameter-level semantics.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, an identical universal router with the same scope, and explicitly differentiates it from the stable ask_pipeworx sibling by highlighting candidate routing improvements. The verb and resource are well-defined.

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 direct usage guidance: use it exactly like ask_pipeworx when the newest routing is desired, and notes that results are compared against the stable router to decide merges. It also clarifies the current inactive candidate state, making it clear when it behaves identically to the stable version.

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

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

Annotations already declare readOnly/openWorld/idempotent, but the description adds substantial depth: return format with evidence and confidence, explicit refusal reasons (not_in_source, no_tool_match, etc.), and the guarantee of grounding to tool results. It also notes the extra LLM call cost, all without contradicting annotations.

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

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

The description is longer than average but every sentence contributes: purpose, routing, return format, refusal behavior, use cases, and cost trade-off. It is front-loaded with the key concept and structured in a logical flow, though slightly verbose with the list of refusal reasons.

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

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

No output schema is present, so the description compensates by fully specifying the success and refusal return shapes. It covers behavioral guarantees, cost implications, and concrete use cases (financial verdicts, legal claims, etc.). The description is complete for an agent to decide when to invoke this tool and what to expect.

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

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

Schema coverage is 100% (all six parameters are aliases for 'question'), so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema provides, but given all parameters are aliases of a single natural-language question, this is sufficient.

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 'Hallucination-resistant answer mode for high-stakes reads,' clearly identifying the tool's purpose and differentiating it from the sibling ask_pipeworx. It explains the mechanism ('picks the right tool... then EXTRACTS the answer using ONLY what the tool result contains'), which is specific and actionable.

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

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

Explicitly states when to use: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' Also provides an exclusion: 'prefer ask_pipeworx for casual lookups' and mentions the cost difference ('Costs one extra LLM call'). This fully distinguishes from alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral context beyond these: resolution contract (market_match_confidence, suggestions), parent_event extractor, news fields with fallback, safety (low-confidence short-circuits, closed/dead markets), wide-spread market handling, and resolution-rule risk. 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 long but well-structured, front-loaded with the core purpose and followed by detailed sections. Every sentence provides specific value (classifiers, fan-out examples, response shapes, edge cases). Could be slightly more concise, but the complexity of the tool justifies the length.

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 (resolver, fan-out, safety checks) and lack of output schema, the description is exhaustive: it explains return shapes (result.market, result.analysis, result.evidence, etc.), edge cases (low-confidence, closed markets), and safety mechanisms. No gaps are apparent.

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

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

Schema coverage is 100% with descriptions. The description adds value beyond the schema by explaining the depth parameter (quick vs thorough with source counts) and the include_raw parameter (summarized vs full payloads). The market parameter is effectively explained via examples in the schema. No additional param details are needed, but the description provides 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 starts with a clear verb+resource: 'Research a Polymarket bet'. It specifies inputs (slug, URL, question text) and outputs (evidence packet + comparison). It distinguishes from sibling tools by being specific to Polymarket betting research, while siblings include general tools like deep_research and ask_pipeworx.

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

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

Explicit usage guidance is given: 'Use for should I bet on X, what does the data say about Y, or is there edge in Z'. It provides examples of classifiers and fan-outs. However, it does not explicitly state when not to use this tool, e.g., for non-Polymarket bets or when simpler queries suffice.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds context on data sources (SEC EDGAR/XBRL for companies, FAERS/fda for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. No contradiction with annotations.

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

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

Single dense paragraph with no wasted words. Every sentence adds value: usage examples, data source details, sorting info, citation URIs, and efficiency claim. Front-loaded with key phrases.

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

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

Given 2 params, 100% schema coverage, and no output schema, description covers all needed aspects: purpose, usage, data retrieval, sorting, return format, and efficiency benefit. No gaps.

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

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

Schema coverage is 100%, but description adds crucial meaning: explains how 'type' determines data fetched, provides examples for 'values' (tickers/CIKs vs drug names), states min/max items, and clarifies sorting behavior. Enhances schema significantly.

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

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

Description clearly states the tool performs side-by-side comparison of 2–5 companies or drugs in one call, with specific verb phrases ('Compare X and Y', 'rank these companies'). It distinguishes from sequential lookups and provides clear scope.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear when-to-use guidance. Provides example queries and implies alternatives (single entity lookups). No exclusions needed.

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), the description discloses account/plan requirements, output packet structure (verbatim evidence, confidence, source, fetched_at, citations), gap and contradiction handling, semantic excerpting, latency expectations, and second-hop iteration behavior. No contradiction with annotations.

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

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

The description is a single dense paragraph, but every sentence adds unique operational value—from account requirements to research mechanics, use cases, alternatives, depth semantics, citation guarantee, and timing. It is front-loaded with the signing-in caveat, though bullet points could improve scanability.

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

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

With no output schema, the description fully explains return values: 'findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding' plus gaps[] and contradictions[]. It covers prerequisites, alternatives, performance, and edge cases like breaking news yielding empty gaps—making it complete for a complex tool.

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

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

Schema description coverage is 100%, so baseline is 3, but the description materially enriches both parameters: it explains depth levels' hop/recovery behavior beyond the enum text and gives example questions for the question parameter. It also clarifies that broad/multi-part questions are acceptable.

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 1455 STRUCTURED data sources' via decomposition and parallel routing to '5,529 tools'. It distinguishes itself from sibling ask_pipeworx by describing it as a multi-hop research tool rather than a single 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?

Explicitly specifies when to use ('Best for broad/multi-part questions over structured data') and when not to ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'). Also gives the prerequisite of an account and a fallback recommendation if unsigned-in.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false. Description adds details about return value: 'top-N most relevant tools with names, descriptions, and full input schemas' and 'each result is ready to call directly, no second schema lookup needed.'

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 usage, but it runs long. Every sentence adds value, though minor trimming could improve 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 no output schema, the description explains what is returned (top-N tools with full schemas). It covers the main behavior but does not specify empty query handling or ranking details.

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

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

Schema description coverage is 100% with all parameters described. Description adds context by listing aliases (task, q, search, description) and providing examples of query values, adding 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 states 'Find tools by describing the data or task,' a specific verb+resource. It distinguishes itself from sibling tools (e.g., deep_research, entity_profile) as the discovery/search tool among many specialized 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?

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set.' Provides use cases like 'browse, search, look up, or discover what tools exist for: ...' but does not explicitly state when not to use.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds details: fans out across multiple sources, returns specific fields, includes patent soft-failure, GDELT→GNews fallback, and single parallel call. Adds value beyond annotations.

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

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

Description is lengthy but well-organized with bullet points. Some redundancy in examples (multiple ask variants) but packs essential information. Could be slightly more concise.

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

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

No output schema, so description must explain returns. Lists fields (cik, company_name, recent_filings, fundamentals, patents, news, LEI) and notes patent limitation. Covers most aspects, though formal response structure not detailed.

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

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

Schema has 100% coverage with descriptions, so baseline 3. Description adds examples ('AAPL', '0000320193') and clarifies that 'type' only supports 'company'. Meaningful additional 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?

Description clearly states the tool provides a holistic profile of a US public company from multiple sources, with specific input (ticker/CIK) and output fields listed. It distinguishes from sibling tools by explicitly preferring over chaining and mentioning resolve_entity for names.

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?

Clear guidance to use when user asks for a holistic view, and to prefer over chaining. Warns that names are not supported and suggests using resolve_entity first. Lacks explicit 'when not to use' but adequate.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable context: data source (IntAct), 'keyless' access, and output fields. No contradictions. Adds appropriate behavioral context beyond annotations.

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

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

Single sentence efficiently conveys source, purpose, input, and output. Front-loaded with 'IntAct (EBI) molecular-interaction database'. No redundancy.

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

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

Though no output schema, description lists key output fields. Lacks mention of pagination behavior or result format, but schema covers page/limit. Adequate for a simple retrieval tool with good annotation support.

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

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

Schema coverage is 100% with descriptions for all parameters (page, limit, query). Description repeats parameter examples but does not add new semantics beyond schema. Baseline 3 is appropriate.

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

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

Description clearly states the tool finds molecular interactions from IntAct database, specifies input types (gene/protein name or UniProt id), and lists output fields (detection method, interaction type, organism, PubMed ref, MI confidence). It distinguishes from sibling 'interaction_count' by indicating it returns detailed results and is 'keyless'.

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

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

No explicit when-to-use or when-not-to-use guidance. The term 'keyless' hints at no authentication needed, but alternatives like 'interaction_count' are not mentioned. Usage context is implied but not clarified.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context about clearing 'sensitive data' and is consistent with annotations. No additional behavioral details needed.

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 succinct sentences: action, usage guidance, and related tools. No fluff, effectively front-loads the core purpose.

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

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

Given the tool's simplicity (1 parameter, no output schema), the description covers purpose, usage, and related tools. It could mention permanence or error handling but overall is adequate.

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

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

Schema coverage is 100% with a single parameter 'key' described as 'Memory key to delete.' The description does not add further meaning or constraints beyond the schema, so baseline 3 is appropriate.

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

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

The description explicitly states 'Delete a previously stored memory by key,' clearly identifying the verb and resource. It distinguishes from siblings like 'remember' and 'recall' by focusing on deletion.

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

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

Provides explicit scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' Also mentions pairing with 'remember' and 'recall,' guiding appropriate use.

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

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

Annotations already declare read-only, idempotent, open-world nature. Description adds fetching and extraction behavior, but does not detail failure modes or rate limits. Baseline 3 because annotations carry the bulk of safety information.

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 with no waste: first defines purpose and audience, second explains process, third lists use cases. Front-loaded and efficient.

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

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

For a simple 2-parameter tool with no output schema, the description covers purpose, process, output format, and use cases. Lacks detail on error handling but sufficient for agent invocation.

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

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

Schema coverage is 100% with clear descriptions. Tool description does not add extra meaning beyond mentioning 'key links' implied in output. Baseline 3 as schema already provides complete parameter documentation.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb and resource. It distinguishes from sibling tools by focusing on generation of the file itself, not auditing or scanning.

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

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

Provides explicit use cases (indexing a client's site, drafting for own project, auditing competitor). Implicitly suggests when to use but lacks explicit alternatives or when-not-to-use guidance compared to siblings.

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 'fast' and 'keyless', providing performance and authentication context beyond the annotations.

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

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

The description is a single concise sentence that front-loads the key information: purpose, input, and keyless nature. No unnecessary words.

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

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

Given the tool's simplicity (one param, no output schema), the description covers the essential aspects. Could mention output format but not necessary for understanding.

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

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

The schema has 100% coverage with a clear description for the 'query' parameter. The description reinforces the input types but adds no new information beyond the schema.

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

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

The description clearly states the tool counts molecular interactions for a gene/protein, specifies input types (name or UniProt ID), and notes it is keyless. This distinguishes it from sibling tools like find_interactions.

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

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

The description implies use for a fast count and mentions keyless access. It does not explicitly state when not to use or mention alternatives, but the context is clear for a simple count tool.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds that it returns specific fields and implies subscription status filtering (active by default). No contradiction; adds useful context beyond annotations.

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

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

Two-sentence description: first sentence declares function and return fields, second sentence guides usage. Front-loaded, every sentence adds value, no extraneous words.

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

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

Given the tool's simplicity (single optional parameter, no output schema) and rich annotations, the description sufficiently covers what the tool does and when to use it. Minor omission: does not mention default behavior of include_inactive false, but schema covers 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% with the single parameter 'include_inactive' well-described in the schema. Description does not repeat parameter details but adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

Description clearly states 'List the caller's active subscriptions' and enumerates return fields. It differentiates from sibling tools like subscribe and unsubscribe by focusing on listing, and the verb 'list' plus resource 'subscriptions' is 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?

Explicitly advises using the tool to 'review what you're monitoring before adding more or to find an id to cancel,' providing clear when-to-use guidance and implicit alternatives (subscribe, unsubscribe).

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?

Since annotations are all false and provide no safety or behavioral hints, the description carries the full burden and delivers: it discloses the anonymous claim_token flow, the daily rate limit of 5 per identifier, the fact that it is free and doesn't count against quota, and that the team reads digests daily. This is far beyond what the annotations offer.

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 the core action first, then use cases, exclusions, token lifecycle, and rate limits. Every sentence earns its place; there is no fluff or repetition of schema 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?

This tool has no output schema and all-false annotations, so the description must cover behavior and return semantics; it fully does. It explains scope ('ONLY for tools served by this Pipeworx connection'), the claim_token response, rate limiting, and how to describe issues, making it complete for a feedback tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful guidance beyond the schema: it explains the message format ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), gives typical length ('1-2 sentences'), and shows the exact claim_token round-trip syntax. This elevates the parameter semantics 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 a specific action and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It explicitly enumerates feedback categories (bug, feature/data_gap, praise), clearly distinguishing this from sibling tools like ask_pipeworx and 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 gives explicit trigger conditions: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides a strong exclusion criterion: reports about other MCP servers should be filed with that server instead, and tells users that Pipeworx tool names are the ones this connection lists.

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

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

Annotations already provide safety info; description adds data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). No contradiction.

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

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

Concise and well-structured: action first, then use cases, then technical details. No unnecessary words.

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

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

Despite no output schema, description explains what is returned (top tools, packs, call volume). Also covers caching and data source. Complete for a simple tool.

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

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

Schema covers 100% of parameters, and description adds context for window meaning (shorter for hot, longer for steady-state demand), exceeding schema detail.

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

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

Description clearly states the tool returns top tools, top packs, and call volume over a window. Uses specific verbs and distinguishes from siblings by focusing on trending/call volume data.

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

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

Lists three explicit use cases and explains window context but doesn't mention when not to use or compare directly with sibling tools.

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

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

The description discloses key behavioral traits beyond annotations: Jaccard similarity filter (SEMANTIC ANCHOR), placeholder slug filtering (PARTITION FILTER), and fill check with realizable edge calculation. Annotations already mark it as read-only and idempotent, which the description aligns with, and no contradictions are present.

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

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

The description is dense but well-structured with sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). It front-loads the core purpose. While slightly long, the complexity of the tool justifies the length. A minor reduction in detail on edge cases could improve 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?

Despite no output schema, the description explains the response structure (opportunities array with fields, partition_check object) and covers edge cases like skipped_low_similarity and placeholders_filtered. It also references polymarket_fill_risk for custom sizing, showing thoroughness. The tool's behavior is fully documented.

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

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

Schema coverage is 100%, but the description adds significant context: it explains that no args triggers trending scan, event and topic modes have specific meanings, and provides examples. The description also details the partition check and fill check behavior tied to the parameters, adding 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 clearly states the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes (no args, event, topic) with specific examples, making it easy to understand what the tool does relative to siblings.

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

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

The description explicitly instructs when to use each mode: no args for trending scan, event for specific market, topic for cross-event scan. It provides example inputs and explains the partition check and fill check. However, it does not directly compare with sibling tools like polymarket_edges or polymarket_edge_tracker, which could be alternatives.

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

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

Discloses caching behavior ('Cached 1h at the KV level'), response structure (by_segment, fed_candidates, _diagnostics), and explains why segments may be empty (funnel counters). Also notes the Fed bets exclusion reason. No contradiction with annotations (readOnlyHint, idempotentHint).

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 detailed and uses sectioning for the three model families and response segments. It front-loads the main purpose. While it is long, every sentence carries necessary information for a complex tool; structure is clear but could be more concise.

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

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

Given complexity (9 parameters, no output schema), the description thoroughly explains output structure, model families, edge cases (placeholder filter, partition jumps), and diagnostic information for empty segments. It covers all aspects needed for an agent to invoke the tool correctly.

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

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

All 9 parameters are described in the input schema (100% coverage). The description adds value by grouping parameters into 'TRADEABLE-EDGE KNOBS' and explaining rationale for defaults (e.g., slippage_pp default 0.3, min_partition_leg_kelly logic). This enriches understanding beyond the schema.

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

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

Clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' The verb 'scan' and resource 'Polymarket markets' are specific, and the description differentiates from sibling tools like polymarket_arbitrage by focusing on Pipeworx discrepancy.

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 targets 'what should I bet on today' use case and mentions that Fed bets are excluded from ranking due to unreliable signal. Providing knobs like min_liquidity and max_spread_pp gives guidance on filtering. However, it does not explicitly mention when not to use or list alternative tools by 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral details: it reads from daily snapshots, uses a 60-day TTL, explains that decay numbers come from daily closes not intraday, and that gaps mean no scan. No contradiction with annotations.

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

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

The description is front-loaded with the purpose and structured with explicit sections (RESPONSE, LIMITS). Every sentence adds value, and while it is long, the detail is necessary given no output schema. It is well-organized and concise for the complexity.

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

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

With no output schema, the description thoroughly explains the return structure: tracked[], expired[], snapshot_dates[], including fields like trend, decay_pp_per_day, and lifespan_days. It also covers limits like the 60-day TTL. The description is fully complete for effective tool invocation.

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

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

Schema coverage is 100% with both parameters having clear descriptions. The tool description adds default values and range for days (clamp 2-30) and options for window, but these are already present in the schema description. Thus, the description does not add meaning beyond the schema, leading to a 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's purpose: 'edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools by focusing on edge tracking and decay analysis.

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

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

The description provides explicit context for when to use the tool: to differentiate fresh edges from old ones. It implies usage by stating 'a fresh wide edge and a 3-week-old wide edge are different trades.' While it doesn't explicitly exclude alternatives, it gives clear guidance on the telemetry aspect.

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 and idempotent. The description adds critical behavioral context: partial basket fills convert arb into unhedged directional position (dominant loss mode), and clarifies the tool walks the order book ladder. 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 structured with capitalized mode markers and lists return fields for each mode. Every sentence adds value, though a slightly shorter version might be achievable without losing information. Still, it's well-organized and front-loaded.

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

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

Given no output schema, the description enumerates all return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, etc.) and explains the risk of unhedged positions. It provides complete context for the tool's behavior and output.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains default values (size_usd=1000, side defaults), interpretation differences between single-market and basket modes, and what returns are produced. This significantly aids correct parameter selection.

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

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

The description explicitly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and clearly distinguishes between single-market and basket modes. It names the specific resource and action, and the distinction from siblings is evident.

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

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

The description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why (theoretical overround not capturable, partial fills cause directional risk). This provides clear when-to-use and risk context.

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

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

Annotations already indicate safe, non-destructive, read-only behavior. The description adds critical context: safety fields (compatibility_warning, temporal_alignment, skipped counters) that disclose when results are meaningless. 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 lengthy but dense with necessary information. It follows a logical flow: purpose, modes, response, safety fields. Slightly verbose but every sentence adds value; no redundancy.

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

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

Given no output schema, the description fully covers the return structure and edge cases (compatibility warnings, temporal alignment, skipped comparisons). All 3 parameters are documented with examples and behavior. No gaps.

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

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

Schema coverage is 100%, but the description enriches meaning: lists all 10 topic shortcuts, explains override behavior, and describes response fields (leg-by-leg prices, spread array, safety fields).

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

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

The description clearly states it computes cross-venue spreads between Kalshi and Polymarket for the same question, distinguishing it from sibling tools like 'polymarket_arbitrage' and 'compare_entities'. It specifies two modes and the nature of the signal.

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 explains when to use (finding spreads when bet shapes are equivalent) and when not (compatibility warnings, temporal misalignment). Warns that most pre-mapped topics are not currently tradeable, preventing misuse.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is already clear. The description adds context about scope (anonymous IP, BYO key hash, account ID) and behavior when key is omitted (list all keys), which goes beyond annotations.

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

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

The description is three sentences, front-loaded with the action, and every sentence adds value. There is no redundancy or 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?

Given the tool's low complexity (one optional parameter, clear annotations, no output schema), the description fully covers purpose, usage, behavior, scope, and pairing with related tools. It is complete 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?

Schema coverage is 100% with clear parameter description. The description adds the key insight: 'omit the key argument' to list all keys, clarifying the optional behavior that is not fully explained in schema alone.

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

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

The description states 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' This clearly specifies the verb (retrieve/list) and resource (saved memories), and distinguishes from sibling tools like remember and forget.

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

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

The description explains when to use: 'look up context the agent stored earlier... without re-deriving it from scratch.' It also provides exclusions and alternatives: 'Pair with remember to save, forget to delete.' Mentions scoping to identifier.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds valuable behavioral details: what each alert carries (source, citation_uri, payload), filtering options, and the mark_read flag's effect on subsequent calls. 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?

Three sentences: first states core purpose, second lists key fields and filtering, third explains mark_read and polling alternative. Front-loaded, no wasted words, every sentence earns its place.

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

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

Description is complete given no output schema: explains return content (source, citation_uri, payload), covers all 5 parameters, mentions alternative URL for scripts. Could optionally mention default limit value explicitly, but not necessary. Well-rounded.

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

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

Schema coverage is 100% with clear descriptions. Description reinforces parameter usage: filter by type, since, limit, mark_read (flag to mark read), unread_only. Adds context like 'ISO timestamp' and 'default 50' for limit, and explains mark_read behavior. Adds value beyond schema.

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

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

Description clearly states the tool pulls fired events from subscription feed, returns recent alerts with specific fields (source, citation_uri, payload). Distinguishes from sibling tools like list_subscriptions (focused on subscriptions themselves) and subscribe/unsubscribe (managing subscriptions).

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

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

Explicitly says 'Pull fired events from your subscription feed' and 'Polls work fine; the same feed is also at GET registry.pipeworx.io/alerts.json for scripts and dashboards', indicating when to use and an alternative access method. Does not explicitly exclude scenarios but provides sufficient context for appropriate usage.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds: fans out to multiple sources, fallback logic, soft-fail for USPTO, and return structure with sources, counts, and URIs.

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

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

Single dense paragraph, front-loaded with use cases, efficient in wording, covers purpose, behavior, return structure, and alternatives without redundancy.

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

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

Given complexity (multi-source, fallback, time windows, no output schema), description provides all needed context: what it returns, how fallback works, when not to use it (entity_profile).

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

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

Schema covers all 3 params with descriptions; description adds concrete examples (ISO vs relative dates), entity types (ticker/CIK), and usage recommendations. Adds value beyond schema.

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

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

Description starts with concrete example queries and clearly states it's a change feed for a company in a time window via one parallel call. It explicitly distinguishes from sibling '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?

Provides explicit guidance: use 'entity_profile' for static profiles. Also explains fallback behavior (GDELT to GNews) and parameter suggestions (e.g., '30d' for monitoring).

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

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

Discloses scope (key-value per identifier), persistence (persistent for authenticated, 24h for anonymous), and aligns with annotations (write, idempotent, non-destructive). Adds value beyond annotations.

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

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

Four well-structured sentences, front-loaded with purpose, no redundant information—every sentence adds value.

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

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

Covers all aspects: what, when, how (key-value), scope, persistence, and companion tools. No gaps 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 covers both parameters with examples; description adds real-world context (e.g., 'user_preference') and scenarios, enhancing understanding despite full schema coverage.

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

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

The description clearly states the tool saves data for reuse across conversations/sessions, with specific examples like 'resolved ticker, target address'. It distinguishes from siblings like recall and forget.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and provides concrete scenarios. It also directs to pair with recall/forget for lifecycle management.

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 (read-only, idempotent), the description reveals data sources (SEC EDGAR, GLEIF, OpenFIGI, RxNorm), behavior for unresolved identifiers ('stated explicitly under unresolved'), and graceful degradation. It also notes internal cascading lookups. This is rich behavioral context 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 long but well-structured: starts with example queries, states purpose, then details supported types and behavioral nuances. While verbose, the information is relevant and front-loaded. It earns its length by covering multiple entity types and edge cases.

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

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

With no output schema, the description takes on the burden of explaining return values. It does so thoroughly for both supported types, including exact identifier fields, sources, and citation format. It also addresses failure modes and degraded behavior, making it complete for a lookup tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining what each type returns (e.g., company yields CIK, ticker, LEI, FIGI; drug yields RxCUI, ingredient, brand) and by giving input examples for each type. This goes beyond the schema's simple parameter descriptions.

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

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

The description clearly states the tool's purpose: resolving user-spoken names to official identifiers. It provides specific verbs ('resolve', 'look up'), a resource ('entity'), and gives multiple example queries. It distinguishes itself from siblings by positioning as the entry point ('Use FIRST') and noting it provides identifiers other tools require.

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

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

Explicit guidance is given: 'Use FIRST whenever you have a name but need an ID.' It also provides examples of triggering queries. However, it does not explicitly mention alternatives or exclusions, though the 'Use FIRST' phrase implies prioritization over sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's burden is lower. The description adds value by revealing that it internally probes each entity with 'ai_visibility_check' and returns a ranked list with specific fields (score, confidence, signal density). This goes beyond annotations to explain the tool's internal behavior and output structure.

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 (4 sentences) and front-loaded with the main purpose. Every sentence adds value: purpose, behavior, use case, and output format. There is no redundancy or fluff. The structure is well-organized and easy to scan.

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, internal sub-tool call, no output schema), the description is complete. It explains the return format (ranked list with score, confidence, signal density), the role of parameters, and the use case. Annotations provide safety context, and the description fills the gaps left by the lack of an output schema.

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

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

Schema coverage is 100%, but the description adds meaning beyond parameter descriptions. It notes that the first entity in the array is treated as the 'subject' for narrative purposes, and explains the 'context' parameter as disambiguating common names. This provides additional semantic context that helps an agent use the parameters correctly.

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: 'Compare AI visibility across multiple entities side-by-side'. It specifies the verb (compare/probe), the resource (AI visibility), and the outcome (ranked list). It distinguishes from sibling tools by explicitly mentioning that it calls 'ai_visibility_check' and frames it for competitive audits, differentiating it from single-entity checks or generic comparison 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 a clear use case: 'Useful for competitive AI-marketing audits' and gives an example question. It implies when to use (multi-entity comparison) and suggests the first entity as subject. However, it does not explicitly state when not to use or directly contrast with sibling tools like 'compare_entities' or 'ai_visibility_check', leaving some implicit guidance.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds critical behavioral details: partial failures degrade gracefully, bundlephobia first measurement can take 5-30 seconds, and sources_failed will list timed-out sources. No contradiction with annotations.

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

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

Description is dense but well-structured. It front-loads the core purpose and then lists details. Could be slightly more concise but effectively uses space.

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

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

Given no output schema, description thoroughly lists return fields (summary block with specific metrics, per-advisory detail, links, alternative versions). Covers edge cases (partial failures, timing). Highly complete for a composite tool.

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

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

Schema covers both parameters with clear descriptions (package name, optional version). Description adds context: version defaults to latest, scoped packages accepted. This adds slight value beyond schema.

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

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

Description clearly states it is a composite check for npm package evaluation combining deps.dev and bundlephobia. It explicitly names the resources (license, advisories, version history, bundle size) and distinguishes from siblings by being npm-specific and composite.

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

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

Explicitly states when to use: when an agent asks about safety, popularity, size, or cost of adding an npm package. Also notes NPM-only in v1 and directs users to deps.dev:version for other ecosystems.

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, describes embedding model, chunk strategy, character cap, offset feature, and truncation behavior. No contradiction with readOnly/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?

Three concise, front-loaded sentences covering purpose, usage, and technical details. 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?

Despite no output schema, description covers output format (passages, offsets, scores), technical constraints, and pairing context. Complete for a complex tool.

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

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

Schema coverage is 100%, so baseline 3. Description adds value by providing query examples and confirming limit range, but largely repeats schema. Slight step 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 clearly states the tool does semantic search inside a fetched record, using specific verbs and resource. It distinguishes from siblings by naming ask_pipeworx_grounded and contrasting with using whole documents.

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

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

Explicitly states when to use ('when record is too big for prompt'), provides pairing advice, and mentions alternatives implicitly.

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 show idempotentHint=true, openWorldHint=true, non-destructive. Description adds behavioral details: OAuth requirement, phone verification, SMS cap, webhook auto-disable after failures. 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?

Single paragraph but front-loaded with core purpose. Contains all necessary information without unnecessary words. Could benefit from bullet points but still efficient.

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

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

For a tool with 3 params (nested), no output schema, the description covers all: required OAuth, all subscription types with examples, delivery channels with limitations, and return value. Leaves no ambiguity.

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 rich descriptions. The description adds even more: type-specific examples (e.g., sec_8k items, polymarket_edge topic), delivery options with details like webhook HMAC signing. Provides significant value beyond schema.

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

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

The description clearly states it 'Create[s] a proactive monitoring subscription to a live-data event stream' and that it 'Returns the new subscription id.' The verb is specific (Create) and the resource is defined (proactive monitoring subscription). It distinguishes from siblings like list_subscriptions and unsubscribe.

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

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

Explicitly states requirement: 'Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions).' Also notes SMS cap (10/day) and phone verification. Lacks explicit when-not-to-use but context implies appropriate scenarios.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds context about returning categorized examples with tool shapes from a live catalog, and that it's an onboarding entry point, which is extra value beyond annotations.

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

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

The description is a single paragraph but well-organized: starts with example natural language queries, then explains return format, then usage instruction. It's informative though slightly lengthy; front-loading key points would improve 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?

With no output schema, the description compensates by detailing return content: category-bucketed example questions with exact tool and argument shapes. Given low complexity (1 optional parameter), the description is complete and sufficient for the tool's purpose.

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

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

Schema coverage is 100% for the single optional 'topic' parameter (description lists values and effect). Description further explains that omitting gives full spread, and passing a topic focuses results, adding meaning beyond the schema alone.

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

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

The description clearly states the tool returns onboarding example questions categorized by topic, with specific verb 'returns' and resource 'category-bucketed example questions'. It distinguishes from siblings like ask_pipeworx by being the entry point for learning what to ask.

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

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

Explicitly says 'Use this FIRST' when not yet knowing what Pipeworx can do, and to learn how to call meta-tools. Provides when-not guidance implicitly by being the first step, and mentions optional topic parameter for focus.

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

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

Discloses key behavioral traits beyond annotations: ownership enforcement, soft deletion (deactivate), and availability of historical events via recent_alerts. Annotations (idempotentHint, destructiveHint) are consistent, and the description adds valuable 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?

Two sentences, no filler. Every sentence provides essential information: action, constraint, and effect. Highly concise and front-loaded.

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

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

For a simple tool with 1 required param, no output schema, and no nested objects, the description fully covers functionality, constraints, and side effects. Mentions related tool (recent_alerts) for further 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% with clear parameter description ('Subscription id (uuid) returned by subscribe'). The description does not add extra parameter semantics, but baseline is sufficient.

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 'Cancel a subscription by id' with a specific verb and resource. It clearly distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by describing the cancellation action.

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 that ownership is enforced (only cancel own subscriptions) and that the row is deactivated rather than deleted, providing context on when to use. It does not explicitly name alternatives or when not to use, but the guidance is clear.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds critical behavioral details: explains the meaning of could_not_verify (check did not happen, carries verification_error, must not be shown as evidence), distinguishes it from unsupported, and clarifies the two routing paths. This is essential context that annotations alone do not 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 highly structured and front-loaded with trigger phrases. Every sentence adds value: usage context, routing logic, return values, and caller warnings. No fluff or repetition; the length is justified by 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 adequately describes return values (verdict types, actual value with citation, reasoning) and error semantics. It also covers the two processing paths and the replacements for sequential calls, making it self-contained for an agent to select and use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra semantics for tolerance_pct, explaining how it overrides the implied tolerance and advising 1–2 for hallucination detection. This provides guidance beyond the schema, making the parameter more actionable.

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

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

The description clearly identifies the tool as a fact-checking/claim verification tool with specific trigger phrases. It distinguishes between company-financial claims (SEC EDGAR/XBRL fast path) and other claims (grounded pipeline), which differentiates it from siblings like deep_research or ask_pipeworx_grounded.

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

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

The description gives explicit usage guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also notes that it replaces 4–6 sequential calls, implying a consolidated alternative. However, it does not explicitly state when not to use it or name alternatives for exclusion.

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