Crc

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds key behavioral context: 'Keyless, offline' and that it works on UTF-8 text, 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?

Two sentences with zero waste. The first sentence immediately states the core action and resource, the second provides return type and key characteristics. Perfectly front-loaded and concise.

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

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

Given the tool is simple with one parameter and no output schema, the description covers the essential behavior: input is UTF-8, output is unsigned value and hex, tool is keyless and offline. The return format could be more explicit, but overall it is complete enough for correct usage.

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

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

The single parameter 'text' is fully described in the schema. The description adds the constraint that input must be UTF-8, which is useful and not in the schema, thus adding meaning beyond the structured field.

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 computes an Adler-32 checksum on UTF-8 text, with specific output details (unsigned value and hex). It is specific about the algorithm and context (used by zlib), but does not explicitly distinguish from sibling crc32.

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

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

The description implies usage for checksumming text via 'Keyless, offline', but lacks explicit guidance on when to use this over alternatives or when not to use it. No alternatives are referenced.

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 false. The description adds context about default model (Workers AI Llama-3.3-70b free) and the need for an API key for Anthropic. No contradiction.

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

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

The description is three sentences long, front-loads the purpose, and every sentence adds value. No redundant or unnecessary information.

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

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

For a tool with 4 parameters and no output schema, the description explains the return structure (per-model {score, confidence, signals, raw_response} + combined view). This compensates for the lack of output schema. Still, it could mention pagination or rate limits, but the provided context 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 covers all 4 parameters with descriptions. The description adds meaning by explaining default values ('Default model is Workers AI Llama-3.3-70b'), the API key purpose ('BYO key — you pay Anthropic directly'), and context disambiguation. This goes beyond the schema.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and returns a visibility score. It uses specific verbs ('probe', 'score') and resource ('visibility') and distinguishes from siblings like scan_competitor_ai_presence which focuses on competitor 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 clear use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring'. It doesn't explicitly state when not to use, but the purpose is well-defined and different 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 establish this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it routes to the right tool, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. This goes beyond what the annotations alone convey and shows no contradiction with them.

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

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

The description is heavily repetitive: the 'Use whenever...' guidance, the example list, and the 'START HERE for most questions' phrase appear multiple times, and the phrase 'START HERE for most questions — for most questions' is visually malformed. It front-loads the key guidance well, but the redundancy substantially hurts information density.

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

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

For a router-style tool with no output schema, the description provides the essential context an agent needs: when to invoke it, what kinds of questions it handles, that it fills arguments, and what kind of answer it returns. The main gap is that it does not clarify the boundary against similarly named siblings, which is notable given the sibling list.

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

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

Schema coverage is 100% and the schema already documents the 'question' parameter and its aliases. The description enhances this by showing realistic example questions and listing natural-language trigger patterns, which helps the agent compose valid queries. It does not discuss parameter formats or constraints, but the schema already handles those.

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 question router that selects from thousands of verified sources, fills arguments, and returns structured answers with citations. This is a specific verb+resource statement. It loses the top mark because sibling tools 'ask_pipeworx_beta' and 'ask_pipeworx_grounded' are not differentiated at all, leaving an agent uncertain which variant to select.

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 extensive when-to-use guidance, explicitly preferring this tool over web search and listing concrete trigger phrases and examples such as 'what is', 'look up', and 'current US unemployment rate'. It does not, however, provide explicit when-not-to-use rules or mention how it differs from closely related siblings like ask_pipeworx_grounded or deep_research.

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 readOnly, idempotent, and non-destructive hints. The description adds substantial behavioral context: candidate routing improvements, the current absence of an active candidate, exact current match to the stable router, and that results are compared for merge decisions. No contradictions with annotations.

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

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

The description is front-loaded with the core identity and each sentence contributes value, but it is slightly verbose with some redundancy ('identical universal router' and 'this IS a full working router') and includes a specific retirement date that is informative but not essential.

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 mentions 'same response shape' as a pointer to ask_pipeworx rather than describing the actual output format. For a beta variant with complex underlying behavior, this is adequate but not fully self-contained for an agent without prior knowledge of ask_pipeworx.

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 six parameters fully documented as aliases for the required 'question' parameter. The description only references 'same arguments' without adding parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states that this is a beta version of ask_pipeworx, a universal router with identical tools, arguments, and response shape. It explicitly distinguishes itself from the stable ask_pipeworx and the grounded variant, making its role unambiguous.

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

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

The description provides an explicit usage condition: 'Use it exactly like ask_pipeworx when you want the newest routing' and points to ask_pipeworx as the stable alternative. However, it does not explicitly state when not to use it, relying on 'beta' and 'experimental edge' to imply caution.

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

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

Beyond the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint annotations, the description discloses the return contract, evidence behavior, refusal reason enum, and the extra LLM call cost. It also explains that the tool may return an explicit refusal rather than guessing. This is rich behavioral transparency that helps the agent predict outcomes.

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

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

The description is dense but every sentence earns its place: purpose, routing behavior, return contract, refusal behavior, use cases, and cost trade-off are all covered. It is front-loaded with the most important differentiator, hallucination resistance, and avoids filler.

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

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

There is no output schema, so the description properly compensates by specifying the exact success payload and refusal reasons. It also explains routing breadth, when to prefer the sibling tool, and the cost implications. An agent has enough information to decide when to call it 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?

The input schema has 100% description coverage, documenting the question parameter and all six aliases. The description adds no parameter-specific semantics, but it does not need to because the schema fully explains the input. 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 names a specific verb and resource: a grounded, hallucination-resistant answer mode. It explicitly distinguishes itself from ask_pipeworx by explaining that it extracts answers using only tool results, and it clarifies the high-stakes read use case. This makes it immediately distinguishable from sibling tools.

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

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

The description explicitly states when to use this tool: when answers will be quoted, cited, or acted on, and when the agent must not invent facts. It also gives an exclusion: prefer ask_pipeworx for casual lookups because this mode costs an extra LLM call. This is clear when/when-not guidance with a named alternative.

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

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

The description goes far beyond annotations (readOnlyHint, openWorldHint, idempotentHint). It details the resolution process, classifier selection, parallel fan-out, response shapes (market, analysis, evidence), resolver contract with confidence levels, parent event extraction, news fallback, safety mechanisms for low-confidence matches and closed markets, wide-spread warnings, 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 very long and dense, covering many details. While the first sentence front-loads the purpose, the extensive paragraphs may overwhelm an AI agent. Some details (e.g., classifier list, fan-out examples) could be summarized or moved to the schema. It earns its place in many parts, but conciseness could be improved.

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 (multi-step resolution, fan-out, multiple response subfields, safety checks, error handling) and the lack of an output schema, the description is remarkably complete. It covers all critical aspects an agent needs to understand the tool's behavior, including edge cases like low-confidence matches, closed markets, wide spreads, and resolution rules.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining the market parameter's acceptable formats (slug, URL, question text) and providing usage guidance for include_raw (when to use false vs true). The depth parameter is also described in the schema, but the description does not repeat it. The description complements the schema effectively.

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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies inputs (slug, URL, question text) and outputs (evidence packet + comparison). It also distinguishes from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on comprehensive single-bet research.

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

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

The description provides explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It does not explicitly compare to siblings or state when not to use, but the context is clear. The guidance is strong enough to help an agent decide when to invoke.

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 valuable context: handles off-calendar fiscal years, sorts results by primary metric, returns citation URIs, and specifies the exact data pulled per type. No contradiction with annotations.

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

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

The description is concise given the complexity, with front-loaded examples. Every sentence adds value, but could be slightly trimmed by removing some redundant natural language examples. Overall 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?

No output schema is provided, but the description mentions paired data and citation URIs. Given the tool's complexity (two entity types with different data sources), the description covers key behavioral aspects like sorting and fiscal year handling. Could be improved by explicitly stating that results are returned in a structured format.

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 has 100% coverage for both parameters. The description enriches meaning by explaining what each type returns (company: financial metrics, drug: adverse events etc.) and provides format examples for values (tickers/CIKs for company, drug names). This goes beyond the schema's brief 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 performs side-by-side comparisons of 2–5 companies or drugs in one parallel call, specifies data sources (SEC EDGAR/XBRL for companies, FAERS etc. for drugs), and distinguishes from sequential lookups. It provides concrete examples of triggering phrases, making the purpose immediately clear.

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

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

Explicitly advises to prefer this tool over sequential single-pack lookups when comparing entities. Provides natural language triggers and mentions it replaces 8–15 sequential lookups, giving clear when-to-use guidance. The sibling tools (entity_profile) are implicitly alternatives for single lookups.

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 behavior. Description adds that it works offline, requires no keys, and returns both unsigned 32-bit and hex values. 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?

Two sentences with zero waste. First sentence covers purpose, algorithm, and output format. Second adds usage constraints. Ideal 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?

For a simple deterministic function with one input and no output schema, the description covers algorithm, output type, and usage caveats completely.

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

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

With 100% schema coverage, the description adds value by specifying 'UTF-8 text' input, which is beyond the schema's 'The text to checksum.' The single parameter is well-documented.

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 computes CRC-32 checksum of UTF-8 text, names the algorithm (IEEE) and its common uses (zip/gzip/PNG), and distinguishes it from sibling 'adler32' by specifying the algorithm type.

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 'Keyless, offline. (Error-detection checksum, not cryptographic.)' guiding the agent to use it for error detection only, not security. Could mention sibling adler32 as alternative but not necessary.

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

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

Annotations already mark the tool read-only, idempotent, open-world, and non-destructive, and the description adds substantial behavioral context: account/tier requirements, no-invention gap reporting, resolvable citation_uri only when the source emits one, contradictions[] on deeper depths, semantic excerpting rather than head-truncation, and expected latency. No statement conflicts with the annotations.

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

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

The description is long but information-dense, with the critical account prerequisite front-loaded before the core capability and every clause covering a real operational or behavioral fact. Some depth-mode details repeat the schema near the end, which prevents a perfect score, but there is no filler or vague marketing language.

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 there is no output schema, the description compensates well by enumerating the return packet (verbatim evidence, confidence, source, fetched_at, stable pipeworx:// citation), gap and contradiction behavior, fetchable citation_uri semantics, excerpting behavior, and latency. An agent has enough information to decide whether to call this tool and what to expect back.

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

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

The schema already covers both parameters at 100%, including detailed depth-mode semantics (quick/standard/thorough hop behavior, contradictions, paid plan) and question natural-language semantics. The description mostly restates these schema details; it adds usage framing but little parameter-level meaning beyond what the schema already provides.

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

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

The description states a specific operation: grounded multi-source research across Pipeworx's 1517 structured data sources in one call, with decomposition and parallel routing. It also distinguishes itself from open-web search and from single-lookup siblings, so an agent can classify this tool cleanly.

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

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

It gives explicit selection criteria: best for broad/multi-part structured-data questions, and 'For a single lookup use ask_pipeworx instead.' It also handles the auth edge case directly: 'If you are not signed in, use ask_pipeworx instead — it works on every tier.' This names the alternative and the conditions that disambiguate it.

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

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

Annotations already mark it as readOnly and idempotent. The description adds that it returns top-N tools with full schemas and examples, ready to call directly. No contradictions.

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

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

The description is front-loaded with key information. It lists many domains, which is slightly redundant but still helpful. No wasted sentences.

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

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

Given the tool has 6 parameters, 1 required, full schema coverage, and no output schema, the description is complete. It explains what the tool returns and how to use results, with 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%, so baseline is 3. The description adds value by providing examples of natural language queries and listing aliases for the query parameter, making it 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 states the tool's purpose: 'Find tools by describing the data or task.' It lists numerous domains and explicitly says to call it first to see the option set, distinguishing it from sibling tools.

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

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

The description says 'Call this FIRST when you have many tools available and want to see the option set,' providing clear usage context. It does not explicitly state when not to use it, but the context implies it's for discovery, not for direct answers.

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?

Even with readOnly/openWorld/idempotent annotations present, the description adds substantial behavioral context: it fans out across multiple external sources, exposes sources_used/sources_failed, clarifies that an empty section means 'no data, not a bug', and explains private-company behavior with resolved:false and a notes line. It also sets expectations for fda_products when a company has no biologic products.

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 front-loads examples and the key 'ALWAYS PREFER' guidance, but it contains a garbled, malformed middle section — e.g., 'fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted?); (weird string: patents (USPTO patents); ...' — which reads as corrupted text and harms scannability. It is also much longer than needed without clean sectioning.

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

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

For a tool with no output schema, the description covers a great deal: accepted input forms, source fan-out, main output fields, maximum filings count, resolved:false behavior, and empty-section semantics. The garbled middle section slightly obscures the exact list of returned blocks, so it is not a flawless 5.

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 both parameter descriptions already explain accepted forms and interchangeability. The description reinforces this with concrete examples and a private-company edge case, but it does not add substantial new parameter semantics beyond what the schema already documents.

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

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

The description states a specific, high-value action: producing a 'full cross-source profile of a US public company in ONE parallel call.' It is packed with example queries ('research Acme', 'brief me on Tesla') and clearly distinguishes itself from 'chaining single-pack SEC/XBRL/news lookups.'

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

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

The description explicitly says to 'ALWAYS PREFER' this tool over chaining single-pack lookups when the user asks for a holistic view, naming the alternative category explicitly. It does not give a crisp 'when not to use' or route to sibling tools like resolve_entity or deep_research, so it stops just short of a 5.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description discloses the destructive nature ('Delete') but does not add context like idempotency or behavior for missing keys. With annotations covering safety profile, the description is adequate.

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

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

Two sentences with no wasted words. The main action is front-loaded. 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?

Tool is simple with one required parameter and no output schema. Description fully covers purpose, usage, and parameter context. 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%, and the schema describes the 'key' parameter as 'Memory key to delete'. The description does not add extra meaning beyond the schema, so baseline 3 applies.

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

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

The description clearly states the verb 'Delete' and the resource 'previously stored memory by key'. It directly tells what the tool does and distinguishes it from siblings like 'remember' and 'recall'.

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

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

Explicitly states when to use: when context is stale, task is done, or to clear sensitive data. Also pairs with 'remember' and 'recall', implying 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?

Description adds behavioral details beyond annotations: fetches page, extracts title/description/key links, emits standard markdown format. No contradictions.

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

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

Two concise sentences plus use-case list. Front-loaded with key information, no fluff.

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

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

With good annotations, high schema coverage, no output schema, description explains output format, behavior, and use cases. Complete.

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

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

Schema coverage is 100%, baseline 3. Description does not add extra parameter information beyond what schema already provides.

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

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

Description clearly states verb 'generate', resource 'llms.txt file', and scope 'for any URL'. Siblings are unrelated, so no confusion.

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

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

Explicitly lists three use cases (client indexing, own project drafting, competitor auditing). Does not mention when not to use, but siblings are irrelevant.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds value by detailing the returned fields and the optional filtering of inactive subscriptions, providing behavioral context beyond annotations.

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

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

The description is two concise sentences, front-loading the core action and return info, then adding usage guidance. 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 low complexity (1 optional param, no output schema), the description is complete: it explains what is returned, the parameter effect, and why to use the tool. 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?

The schema fully documents the single parameter 'include_inactive' with 100% coverage. The description does not add additional semantic detail beyond the schema, so baseline score is appropriate.

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

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

The description clearly states the tool lists the caller's active subscriptions and specifies the returned fields. It distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on listing existing 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?

The description provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This clearly indicates when to use the tool relative to subscribing/unsubscribing.

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 (all false), the description discloses rate limits (5 per identifier per day), cost (free, no quota), the claim_token return behavior for anonymous filing, and that the team reads digests daily. This significantly enriches the agent's understanding.

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

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

Every sentence adds value, from purpose to exclusions to token semantics to rate limiting. It is front-loaded with the core purpose and structured logically, with no filler.

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

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

Despite having no output schema, the description explains the claim_token lifecycle (filing returns a token, passing it later reads status), rate limits, scope, and cost. For a feedback tool, this is complete coverage of what an agent needs to know.

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 4 parameters at 100%, so baseline is 3. The description adds guidance on claim_token usage with a concrete invocation example and instructs users to frame messages around Pipeworx tools/packs rather than pasting user prompts. This modestly exceeds 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?

Description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes from siblings like ask_pipeworx by focusing on feedback and explicitly scoping to Pipeworx tools.

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

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

Provides explicit when-to-use criteria for each feedback type (bug, feature/data_gap, praise) and an explicit when-not-to-use: if the tool came from a different MCP server, file elsewhere. Offers a disambiguation rule ('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 declare readOnly, idempotent, non-destructive. Description adds data source (CF analytics-engine), no PII, caching times (5min-1h), and return structure (pack, tool, count) – going beyond annotations.

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

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

Reasonably concise with bullet-like structure. Front-loaded with primary function. Each sentence adds value without redundancy.

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

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

Given the tool's simplicity (1 optional param, no output schema), the description covers return value, use cases, data source, caching, and privacy completely.

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 with description and enum. Description adds nuance about shorter vs longer windows for different use cases, adding 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?

Clearly states it returns top tools, packs, and call volume over recent windows. Distinguishes from siblings like ask_pipeworx and discover_tools by focusing on aggregated trending 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?

Provides three explicit use cases and notes caching behavior. Does not contrast with specific sibling tools but the description implies when to use (discovery vs asking questions).

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 detailed behavior beyond annotations: scanning logic, semantic anchor (Jaccard similarity, skipped pairs), partition filter (placeholder fraction), fill check with book depth analysis, and references to sibling tools for sizing. 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?

Descriptive and well-organized with clear sections, but somewhat lengthy. Every sentence adds value, though slight verbosity in technical details could be tightened without losing clarity.

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

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

Comprehensive coverage for a complex tool with no output schema: explains response fields (opportunities[], partition_check), fill check logic, and edge cases (deviations >3pp, placeholder filtering, realizable edge). No missing 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?

Adds extensive meaning beyond schema descriptions: explains each parameter's mode, gives example values, describes internal behavior (e.g., walk child markets, compute partition_check), and clarifies outputs and conditions.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks on Polymarket, distinguishing it from sibling tools like polymarket_fill_risk by mentioning its integration and comparison.

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

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

Explicitly explains three modes (no args, event, topic) with examples and when to use each, including recommendations (e.g., 'event recommended for a specific market') and warnings about when not to trade based on fill check results.

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

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

Annotations already declare the tool is safe (readOnly, idempotent, not destructive). The description adds transparency about caching (1h KV-level), response structure (by_segment, diagnostics), and parameter effects (e.g., tradeable-edge knobs). No contradictions.

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

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

The description is very detailed and well-structured, front-loading purpose and model families. However, it is overly verbose with mathematical formulas and nested explanations, which could be condensed for better agent parsing without losing essential information.

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

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

Despite lacking an output schema, the description thoroughly covers the response structure (by_segment, fed_candidates, diagnostics), caching, parameter interactions, and edge cases (e.g., fed bets exclusion, filter skips). It is complete for an agent to understand the tool's behavior.

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

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

All 9 parameters have descriptions in the schema (100% coverage). The tool's description adds significant context beyond the schema, such as explanation of slippage and min_partition_leg_kelly interaction, which helps the agent understand trade-offs.

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

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

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, with a specific use case 'what should I bet on today'. It distinguishes from siblings like polymarket_arbitrage by focusing on edge detection from multiple model families.

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

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

The description provides clear context for when to use the tool (discovering betting opportunities) and mentions the built-for-purpose, but does not explicitly state when not to use it or compare directly with sibling tools. However, the detail implies its unique role.

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 readOnly, openWorld, idempotent, non-destructive. Description adds concrete behavioral details: serves daily snapshots, 60-day TTL, snapshots from daily closes at default slippage, and output structure including expired edges and snapshot dates. No contradictions.

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

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

Description is well-structured with a clear purpose sentence then detailed output explanation in sections. Every sentence adds value, though slightly verbose with some technical details that could be streamlined.

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

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

Despite no output schema, the description thoroughly explains the response format (tracked, expired, snapshot_dates with fields) and limits. Covers behavioral aspects and sufficient context for a telemetry tool.

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

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

Both parameters have full schema descriptions (100% coverage). The description restates defaults and bounds for 'days' but adds minimal value beyond the schema. 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 it provides edge persistence and decay telemetry from daily snapshots, answering a specific question about edge age and trend. It distinguishes from siblings like polymarket_edges and polymarket_arbitrage by its analytical focus.

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 description implies it's for analyzing edge persistence, but does not contrast with siblings or mention alternatives. Context is inferred from output details.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's behavioral disclosure is not essential but adds value: it details that the tool 'walks the ladder', returns verdicts like clean/degraded/cannot_fill, and warns about forced directional risk in basket mode. No contradictions with annotations.

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

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

The description is dense but well-structured with bold headings for modes and clear bullet points in the return fields. It could be slightly trimmed (some redundancy e.g., 'REQUIRES one of' repeated), but front-loading the purpose and using formatting makes it scannable for an AI.

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 explains return values for both modes, including edge cases (thin_legs, forced_directional_risk). It covers the key risk ('partial basket fills convert an arb into an unhedged directional position'). For a tool with two modes and four parameters, this is comprehensive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains defaults per mode (e.g., side default changes based on mode), clarifies interpretation of size_usd (spend vs target proceeds vs settlement notional), and details return fields that depend on parameters. This is exemplary 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's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes two modes (single-market and basket) and explicitly contrasts with sibling tools polymarket_arbitrage and polymarket_edges, making it easy for an AI agent to select correctly.

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

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

The description provides explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why (theoretical overround on thin books is not capturable, partial fills create directional risk). No when-not-to is needed beyond the implicit threshold.

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?

With readOnlyHint=true and destructiveHint=false already declared, the description still adds substantial behavioral depth: compatibility warnings, mismatch codes, fee caveats, gross vs. net spreads, skipped-pair counters, and the fact that pre-mapped topics are often not tradeable. This goes well beyond the annotations.

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

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

The description is long but every sentence carries distinct operational or safety information. It is broken into clear sections (TWO MODES, RESPONSE, SAFETY FIELDS, fees, skipped counters) and front-loads the core definition and mode selection before caveats.

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

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

For a tool with no output schema and a complex return shape, the description is remarkably complete: it documents response fields, compatibility codes, temporal alignment meaning, fee treatment, and which comparisons are dropped. An agent has enough context to invoke the tool correctly and interpret its results.

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

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

The schema already has 100% coverage, so the baseline is 3. The description adds real value on top: it explains that both modes run the identical matcher, that explicit parameters override the topic-mapped side, and that custom pairings carry the same disclosures. That is meaningful semantic enrichment.

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 precise verb and resource: a cross-venue spread between Kalshi and Polymarket for the same resolving question. It also clearly distinguishes the two operational modes (topic shortcuts vs. explicit tickers/slugs) and describes the output, making it easy to tell this tool apart from related 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 gives clear when-to-use context for both modes: use `topic` for pre-mapped macro shortcuts and explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings. It does not explicitly name alternative sibling tools or state when not to use this tool in favor of polymarket_arbitrage or similar, but the within-tool guidance is strong.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable scoping information ('scoped to your identifier') beyond what annotations provide, without contradicting them.

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

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

Two concise sentences, each serving a distinct purpose: first explains the dual behavior, second explains usage context. 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?

Given one optional parameter, no output schema, and annotations covering safety, the description fully explains behavior, scoping, and pairing with sibling tools. 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% for the single parameter 'key'. The description explains that omitting the key lists all keys, which adds meaning beyond the schema's description.

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

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

The description uses a specific verb ('Retrieve') and resource ('a value previously saved via remember'), and distinguishes itself from siblings by naming 'remember' and 'forget'. The dual behavior (single key vs. list all) is clearly stated.

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

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

The description provides clear context for use (retrieve stored context) and mentions that omitting the key lists all saved keys, and pairs with 'remember' and 'forget'. However, it does not explicitly state when not to use this tool.

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

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

Annotations declare readOnlyHint=true, but the description discloses a side effect: marking events as read via mark_read. This adds transparency beyond annotations, though the description could clarify that this is a non-destructive state change. 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 paragraph that front-loads the main purpose. It is efficient but could benefit from bullet points or a clearer separation of parameters and behavior. No unnecessary sentences.

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

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

The description explains return fields, filtering, and polling behavior. However, it does not address pagination (e.g., what happens if more than limit events exist) or the exact response format. Given the no output schema, it is mostly complete but has a minor gap.

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

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

Schema coverage is 100%, baseline is 3. The description adds value by providing example filter values (e.g., 'sec_8k') and clarifying that 'since' expects an ISO timestamp. This enhances understanding 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 retrieves fired events from the subscription feed and lists key fields (source, citation_uri, raw event). However, it does not differentiate from siblings like 'recent_changes' or 'list_subscriptions', leaving the distinct use case slightly ambiguous.

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 filtering by type and since, and mentions that polling works fine. It also provides an alternative endpoint for scripts and dashboards. Missing explicit when-not-to-use guidelines or comparison to 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?

Beyond annotations (read-only, idempotent), the description details the fan-out to multiple sources, fallback behavior, soft-fail for patents, and return structure, giving full transparency.

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

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

The description is dense and informative, with front-loaded examples and clear structure. It is concise for the complexity, though slightly long.

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

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

The description covers all aspects: purpose, behavior, parameters, return structure, and alternative tool usage, making it fully complete for an agent to use correctly.

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

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

Although schema coverage is 100%, the description adds considerable value by explaining the `since` parameter with examples and typical usage, clarifying the `type` restriction, and the `value` formats.

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 provides a consolidated change feed for a company (SEC filings, news, patents) in one call, with specific example queries and explicit differentiation from the sibling tool 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?

The description not only explains what the tool does but also explicitly advises when to use entity_profile instead, providing clear guidance on tool selection.

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

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

Annotations already idempotentHint=true and destructiveHint=false. Description adds valuable context: scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous. No contradictions.

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

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

Four sentences with no wasted words. Front-loaded with core purpose, then usage, then behavioral details. Highly 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?

Given the simplicity (2 params, no output schema, good annotations), the description covers all relevant aspects: purpose, when to use, scoping and persistence behavior. Complete for an agent.

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

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

Input schema has 100% coverage with clear descriptions. Description adds examples (e.g., 'subject_property') but does not significantly extend meaning 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?

The description uses a specific verb 'Save' with resource 'data the agent will need to reuse later', and provides concrete examples (resolved ticker, target address, etc.). It clearly distinguishes from sibling tools 'recall' and 'forget'.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward'. Mentions pairing with recall and forget, implying when not to use. Lacks explicit exclusions but provides sufficient context.

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

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

Beyond the readOnly/idempotent annotations, the description discloses important behaviors: multi-endpoint cascading lookups, graceful degradation when GLEIF/OpenFIGI are down, explicit `unresolved` reporting, and the `figi_candidates` behavior when a name matches multiple instruments. It also explains edge cases like non-equity instruments and ISIN-to-LEI resolution, giving the agent a realistic model of the tool's behavior.

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

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

The description is long, but the length is justified by the tool's multi-type, multi-source complexity. It is front-loaded with use cases, organized by entity type, and the critical caveats are placed inline where they are relevant. A slightly tighter edit could reduce repetition, but the structure earns its 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?

For a tool with no output schema and complex multi-source resolution behavior, the description is remarkably complete: it covers the identifier sets, the source labels, the unresolved behavior, multi-match handling, fallback degradation, and the mapping from an ISIN to a legal entity. An agent has enough to invoke it correctly and anticipate the shape of its results.

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

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

Although the schema already covers both parameters at 100%, the description adds substantial meaning: accepted input forms for company (ticker, CIK, ISIN, name) and drug (brand or generic), the exact formatting warning for bonds, and a concrete instruction to pass only the entity name, not the full noun phrase. This goes well beyond the schema's generic descriptions.

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

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

The description opens with concrete trigger phrases and defines the core action: resolving a user-spoken name to the canonical identifiers other tools require. It names the supported entity types (company, drug) and the identifier families returned, making the tool's role unmistakable and distinct from siblings like entity_profile or compare_entities.

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 direction: 'Use FIRST whenever you have a name but need an ID,' and enumerates many example queries that signal the right moment to call it. It does not explicitly state when NOT to use it or compare it to sibling tools, but the positive guidance is strong and clear.

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

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

Description specifies it probes each entity with ai_visibility_check, ranks by score, returns ranked list with score/confidence/signal density, treats first entity as subject. Annotations confirm read-only, idempotent, non-destructive. No contradictions.

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

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

Two sentences front-loading purpose and behavior. No unnecessary words. Every sentence adds value.

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

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

Complex tool (4 params, comparison logic) with no output schema, but description explains return format (ranked list with metrics). Covers usage, behavior, parameters, and output sufficiently for agent usage.

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

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

Schema coverage 100%, but description adds meaning: first entity is subject, models default to workers-ai, _apiKey only for anthropic, context disambiguates. These details enhance schema descriptions.

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

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

Clear verb 'compare' and resource 'AI visibility' across multiple entities. Distinguishes from sibling ai_visibility_check (single probe) and compare_entities (general comparison). Specific action: probes, ranks, surfaces most/least recognized.

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 use case: 'competitive AI-marketing audits' with example question. Implicitly when not to use (single entity) but no explicit alternatives mentioned. Clear context provided.

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive. Description adds behavioral details: partial failures degrade gracefully, bundlephobia timing (5-30s on first measurement), sources_failed list, and return format. No contradictions.

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

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

Description is a single dense paragraph that front-loads the core purpose and then details sub-checks, timing, and fallbacks. Somewhat verbose but efficient, with no wasted sentences.

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 (summary block, advisory details, links, alternative versions) and error handling. Covers all necessary context for a composite tool with two parameters.

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

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

Schema description coverage is 100% (both parameters have descriptions). The tool description adds minor value (e.g., scoped packages accepted for 'package'), but largely repeats schema info (default version behavior). Limited additional meaning 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 is a composite check for evaluating whether to add an npm package, listing specific checks (license, advisories, bundle size, etc.) and explicitly noting it is npm-only in v1, distinguishing it from sibling tools like deps.dev:version.

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

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

Explicitly says when to use (agent asks about safety/popularity/size) and when not to (PyPI/Maven/Cargo/Go use deps.dev:version directly). Provides clear usage 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 indicate readOnly, openWorld, idempotent, and non-destructive. Description adds technical details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation and flagging. Provides operational constraints 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 paragraph is well-structured and front-loaded with purpose and usage. Every sentence adds value; no fluff. Exactly 4 sentences: purpose, use-case, pairing, technical details.

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

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

No output schema, but description explains return type: top-N passages with character offsets and similarity scores. Covers parameters, behavior, limitations (200K chars, truncation). Sufficient for an AI agent to understand the tool's functionality and expected 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 description coverage is 100% for all 3 parameters. Description adds limited value: clarifies 'max ~200K chars' for text and provides example queries. Baseline 3 is appropriate as schema already does heavy lifting.

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

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

Description clearly states 'Semantic search INSIDE a fetched record' with specific verb (search) and resource (record). It distinguishes from sibling tools like ask_pipeworx_grounded by noting that it searches within a fetched document.

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

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

Explicitly says to use 'when the record is too big to cram into the prompt' and explains benefits (saves context, returns passages with offsets). Pairs with ask_pipeworx_grounded for grounded responses. No explicit when-not-to-use, but context is clear.

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

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

The description discloses behavioral traits beyond annotations: returns subscription ID, requires OAuth for persistence, delivery channel limits (SMS 10/day, webhook auto-disable after 10 failures), and that the feed is always on. Annotations show idempotentHint=true, but the description does not mention idempotency, which is a minor gap.

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

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

The description is well-organized, starting with the main purpose and then detailing types and delivery options. Each sentence provides necessary information. However, it is somewhat dense and could benefit from clearer structuring or bullet points for readability.

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

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

Given the tool's complexity (3 params, nested objects, no output schema), the description covers all essential aspects: types, parameters, delivery constraints, prerequisites, and the return value (subscription ID). It also includes edge cases like webhook auto-disable and SMS cap, making it sufficient for an agent to use correctly.

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

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

Schema description coverage is 100%, but the description adds significant value by explaining the semantics of each type and its params with concrete examples (e.g., sec_8k items codes, polymarket_edge topics). It also elaborates on delivery channels beyond the schema, such as webhook HMAC signing.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream. It specifies the resource and action, and lists supported types. However, it does not explicitly differentiate from sibling tools like list_subscriptions or unsubscribe, though it mentions pulling via recent_alerts as an alternative.

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

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

The description provides clear prerequisites (requires OAuth account, not anonymous/BYO), supported types with parameter examples, and delivery channel options with constraints (SMS cap, webhook auto-disable). It lacks explicit when-not-to-use guidance or direct references to alternative tools for listing or unsubscribing.

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 valuable context: it returns example questions with exact tool+argument shape, drawn from a live catalog, and describes behavior with/without the topic parameter. No contradictions with annotations.

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

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

The description is well-structured, starting with typical user queries, then stating purpose, output details, and usage instructions. It is slightly long but all sentences earn their place. Minor improvement could be trimming the list of categories.

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

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

For a simple tool with one optional parameter and no output schema, the description covers everything: when to use, what output to expect (category-bucketed examples with tool+argument shape), and how to customize with topic. No gaps remain.

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

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

Schema coverage is 100% (1 param with description). The description adds meaning by listing example values for topic ('finance', 'pharma', 'betting') and explaining that omitting it gives a cross-category spread. This goes beyond the schema's basic description.

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

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

The description clearly identifies the tool as an onboarding entry point that returns category-bucketed example questions. It uses specific verbs ('returns', 'learn how to call') and distinguishes from sibling tools like ask_pipeworx and discover_tools by stating it is for 'getting started'.

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 this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' Also provides examples of when to omit or pass the topic argument, and references sibling tools like ask_pipeworx, entity_profile, compare_entities as 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?

Describes deactivation behavior beyond annotations: row is deactivated not deleted, historical events remain. Annotation 'destructiveHint: false' aligns; 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?

Two concise sentences with key details front-loaded. 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 single parameter, no output schema, and adequate annotations, description fully explains mutation behavior and data persistence.

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 parameter 'id' with description 'Subscription id (uuid) returned by subscribe.' Description adds no extra semantics, 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?

Verb 'cancel' clearly indicates the action on resource 'subscription by id'. Distinguishes from siblings like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly states ownership enforcement: 'you can only cancel your own subscriptions', guiding the agent on when it's appropriate. Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations already declare read-only, open-world, and idempotent hints, but the description adds substantial behavioral context: the automatic fallback routing, the definition and significance of the `could_not_verify` verdict (with `verification_error` detail), the meaning of `unsupported`, and the fact that it replaces 4–6 sequential calls. None of this contradicts the annotations.

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

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

The description is long but every sentence earns its place. It is front-loaded with usage examples, then covers routing, output, and caveats. The structure is logical: examples → general usage → specific behaviors → return values → important caveats → efficiency benefit. No filler 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?

Given the tool has no output schema, the description must explain return values and behavior, and it does thoroughly. It enumerates the exact verdicts, explains the meaning and proper handling of `could_not_verify` and `unsupported`, and describes the routing logic. The description is sufficient for an agent to select and invoke the tool correctly without additional context.

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

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

Schema coverage is 100%, but the description goes beyond schema descriptions. For `claim`, it provides concrete examples and clarifies the type of natural-language claim expected. For `tolerance_pct`, it explains the override effect, default behavior (implied by wording, capped at 5), and a specific use case (1–2 for hallucination detection). This adds meaningful semantic depth 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: natural-language claim verification against authoritative sources. It opens with concrete query patterns ("Is it true that…", "fact check") and explicitly distinguishes itself from generic Q&A by returning verdicts. It also differentiates the tool's behavior from siblings by mentioning the structured SEC EDGAR/XBRL fast path for company-financial claims and the grounded pipeline for other claims.

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

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

Provides explicit when-to-use guidance: "Use whenever the agent needs to check whether something a user said is factually correct." It also explains the routing behavior (company-financial vs. other claims), which helps the agent decide when this tool is appropriate. However, it does not explicitly name sibling tools as alternatives or say when NOT to use it, so it misses the full 'when-not/alternatives' criterion.

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