Emailable

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds critical behavioral details: the probing mechanism, cost implications (BYO key for Anthropic), default model, and output structure. No contradiction with annotations.

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

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

The description is three sentences with a concise list of output fields, all front-loaded and free of fluff. Every sentence adds essential information (purpose, parameters, return format, use cases).

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

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

Despite having no output schema, the description explicitly states the return format (per-model score, confidence, signals, raw_response, combined view). It covers purpose, all parameters, defaults, and use cases, making the tool fully understandable for an AI agent.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the default model for the 'models' parameter, how the '_apiKey' is used (passed through to Anthropic), and the purpose of 'context' for disambiguation. This enrichment justifies a score above baseline.

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

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

The description uses a specific verb 'probe' and clearly identifies the resource (LLMs) and output (visibility score per model). It distinguishes the tool's purpose for AI-marketing audits, brand checks, and competitive monitoring, making it highly clear despite not explicitly differentiating from siblings like 'scan_competitor_ai_presence'.

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 (e.g., 'AI-marketing audits') and clarifies when to use the Anthropic model (requires passing _apiKey). However, it does not mention alternatives or when not to use this tool relative to siblings, leaving some room for ambiguity.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds useful behavior: it routes to one of many tools, returns citation URIs, works on every tier, and is one fast call. It could mention failure modes or caveats about delegation, but the disclosed routing/citation behavior goes 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?

Front-loaded with 'PREFER OVER WEB SEARCH', followed by scope, mechanism, trigger phrases, examples, and alternative routing. Every sentence earns its place, and despite the long domain list the structure is scannable and purposeful.

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

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

Covers what the tool does, when to choose it, when to escalate, what it returns (structured answer with pipeworx:// citation URIs), and its broad domain coverage. There is no output schema, but the description explains return behavior well enough for an agent to select and call it.

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

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

Schema coverage is 100% and the 'question' property documents its aliases (query, q, prompt, text, input), so the schema carries the parameter weight. The description adds useful example questions but no additional parameter semantics, matching the baseline for fully documented schemas.

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 states a clear action: routes the user's factual question to the appropriate one of 5,721 tools and returns a structured answer with citation URIs. It explicitly distinguishes itself from web search and sibling ask_pipeworx_grounded/deep_research, so an agent can tell what this tool is for.

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?

Gives explicit trigger conditions ('what is', 'look up', 'find', 'get the latest', factual questions) and says to prefer it over web search. It also names step-up alternatives and their selection criteria: ask_pipeworx_grounded for hallucination-resistant single answers, deep_research for broad/multi-part fan-out.

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

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

Annotations already declare the tool read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context beyond those: it discloses that candidate routing improvements are enabled live, that no candidate is currently active (retired 2026-07-26), that results are compared against the stable router, and that the tool does not fall back to anything. This experimental-state transparency is exactly what annotations cannot capture, and there is 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 four sentences and reasonably well structured: purpose, current status, usage instruction, and reassurance. It likely repeats the 'identical/exactly matches ask_pipeworx' idea several times, but each repetition serves a slightly different purpose (identity, current state, and usage). It is slightly wordier than necessary but remains clear and front-loaded.

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

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

Given the tool's complexity — a universal router over 5,721 tools, no output schema, and beta status — the description covers the experimental state and usage well. However, it does not explain what the response shape actually is, only that it is the same as ask_pipeworx, and it relies on the reader knowing what ask_pipeworx does. The lack of an output schema makes this reliance more significant, so the description is not fully self-contained.

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

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

The input schema already provides 100% description coverage, clearly documenting a 'question' parameter and five aliases (q, text, input, query, prompt) with natural-language guidance. The tool description adds no parameter-specific meaning beyond saying 'same arguments' as ask_pipeworx, so the baseline of 3 applies because the schema carries the semantic weight.

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 identifies the tool as 'Beta version of ask_pipeworx' and an 'identical universal router (same 5,721 tools, same arguments, same response shape)', which conveys that it routes natural-language questions to Pipeworx tools. It makes the beta relationship to the stable ask_pipeworx explicit, and the sibling list confirms that distinction. However, it never states from scratch what 'routing' actually means or what kind of answer the user receives, so it relies somewhat on prior knowledge of ask_pipeworx.

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

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

The description explicitly tells the agent to use it 'exactly like ask_pipeworx when you want the newest routing' and reassures that it is a full working router, not a fallback. This gives clear when-to-use guidance and indirectly points to ask_pipeworx as the stable alternative. It does not provide explicit when-not-to-use exclusions or address ask_pipeworx_grounded, so it stops short of a 5.

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

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

The description substantially extends the annotations by detailing refusal behavior, exact refusal reasons, the evidence quote mechanic, and the extra LLM call cost. It explains what happens when data doesn't directly answer—an explicit refusal—rather than silently guessing. This is rich behavioral disclosure beyond the readOnly/idempotent hints.

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

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

Every sentence earns its place: the top line states the core value, the middle explains mechanics and output/refusal shapes, and the close gives selection guidance. It is dense but not bloated, and the key differentiator ('hallucination-resistant', 'high-stakes') is front-loaded.

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

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

Even without an output schema, the description fully documents the success return object with all fields, the refusal object with its possible reasons, and the behavioral contract. Combined with annotations and full schema coverage, an agent has everything needed to select and invoke the tool correctly and interpret its result.

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

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

Schema description coverage is 100%, and the schema already explains that all 6 parameters are aliases for a natural-language question. The description adds no new parameter-level meaning beyond reinforcing that a question is expected. Baseline 3 is appropriate because the schema carries the full burden and the description does not need to compensate.

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 precise purpose: a hallucination-resistant answer mode for high-stakes reads that extracts answers only from the tool result. It clearly distinguishes itself from ask_pipeworx by naming the sibling and explaining the difference in output guarantees. The phrasing 'Hallucination-resistant answer mode' is specific and action-oriented.

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 when to use the tool: 'whenever an answer will be quoted, cited, or acted on' and when not to: 'prefer ask_pipeworx for casual lookups.' It names the alternative (ask_pipeworx) and provides a cost-based selection criterion. This is direct, actionable routing guidance.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds extensive behavioral context: fan-out to various data sources, resolver contract with confidence levels, parent event extraction, news field error handling, safety short-circuits, illiquid spread handling, and resolution-rule risk. No contradictions with annotations.

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

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

Description is lengthy but well-structured with sections and examples. It is front-loaded with core purpose. Some details could be condensed, but overall effective for a complex tool.

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

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

Despite no output schema, description covers input, behavior, output shapes, error states, and edge cases thoroughly. All relevant aspects for agent decision-making are addressed.

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%. Description enriches parameter meanings: explains market accepts slug, URL, or question text; depth enum options (quick vs thorough); include_raw purpose and impact on response size. Adds significant value beyond schema.

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

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

Description clearly states the tool researches a Polymarket bet by pulling Pipeworx data in one call. It specifies input types (slug, URL, question text) and output (evidence packet + comparison). This differentiates it from sibling tools like polymarket_edges or polymarket_arbitrage, which focus on different aspects.

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

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

Explicit usage examples are given: 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings, leaving some ambiguity.

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

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

Annotations already indicate read-only, idempotent, not destructive. The description adds specific behavioral details: data sources (SEC EDGAR/XBRL for companies, FAERS/FDA/clinical trials for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. No contradictions.

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

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

Highly concise yet information-rich. Front-loaded with example queries, followed by clear explanation of behavior for each type, and a concluding sentence on efficiency. Every sentence adds value.

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

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

Despite no output schema, the description explains what is returned (paired data with citation URIs) and sorting order. Both entity types are fully covered. For a tool with 2 parameters and simple behavior, the description is 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%, but the description adds meaning: explains type values ('company' vs 'drug') and the expected value formats (tickers/CIKs for companies, drug names for drugs). It also clarifies sorting behavior and data sources.

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

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

The description clearly states the tool does side-by-side comparison of 2-5 companies or drugs, with a specific verb-resource ('compare entities') and explicit example queries. It distinguishes from siblings like entity_profile by emphasizing parallel over sequential 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?

Explicit guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' with example commands. It explains what types ('company' or 'drug') and constraints (2-5 items) are appropriate, leaving no ambiguity about when 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?

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses account requirements, paid tier for thorough, latency expectations, gap behavior ('never invented'), resolvable citations, semantic excerpting, contradictions scan, and hop fields. These are rich behavioral details not carried by annotations, and they do not contradict 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 densely informative; every sentence covers a distinct aspect (prerequisites, alternatives, output structure, depth behaviors, latency). The most critical context is front-loaded with the account requirement. It could be tightened, but the length is justified by the complexity of the tool.

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

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

For a complex research tool with no output schema, the description fully covers prerequisites, return format (findings packet with verbatim evidence, confidence, source, fetched_at, citation, gaps, contradictions, hop), latency, and operational behavior. An agent has all the context needed to invoke it correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra value by clarifying that 'question' can be 'broad/multi-part' and by explaining the behavioral consequences of each depth value beyond the enum descriptions, such as gap recovery and iteration. This moves it above the baseline.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1497 STRUCTURED data sources ... in ONE call.' It explicitly differentiates from siblings by naming ask_pipeworx as the alternative for single lookups and breaking news. The 'NOT open-web search' clarification further disambiguates it from general search tools.

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

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

The description gives explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data' and names the alternative for single lookups, breaking news, and unsigned-in users. It even explains the depth tiers and when each is appropriate, leaving no ambiguity about 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 indicate read-only, idempotent, non-destructive. The description adds that results include full schemas and are ready to call directly, which is beyond the annotations and helpful.

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

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

The description is front-loaded with the core purpose and provides domain examples and benefits without being overly verbose. It is well-structured for quick comprehension.

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 clearly explains the return value (tools with names, descriptions, schemas, examples) and covers the purpose, usage, and behavior comprehensively.

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

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

Schema coverage is 100% with all parameters described. The description provides natural language examples and explains aliases, adding value over 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 it finds tools by describing data or tasks, lists many domains, and explicitly says 'Call this FIRST' for browsing, distinguishing it from sibling tools that perform specific functions.

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 tells when to use it ('when you need to browse, search, look up, or discover what tools exist for' various domains) and advises to call it first. It does not explicitly state when not to use, but the 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?

Description adds behavioral details beyond annotations: uses SMTP-level check, state options (deliverable/undeliverable/risky/unknown), score range (0-100), and potential latency up to 10s. Annotations already indicate readOnly and idempotent, so 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 plus a clear example. Every sentence adds value. Information is front-loaded: purpose, outputs, source, and expected behavior.

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 5 parameters with full schema coverage and no output schema, the description adequately explains return values (state, score, flags, typos) and provides an example. No missing context for a verification tool.

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

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

Schema coverage is 100% with descriptions for all 5 parameters. The description provides an example but adds no new semantics beyond what the schema already covers, so baseline score of 3 is appropriate.

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

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

The description clearly states it verifies email deliverability, listing specific outputs (state, score, flags, typo suggestions) and provides an example invocation. This distinguishes it from sibling tools which are unrelated.

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 the tool's purpose and mentions that a slow SMTP check can take up to 10s, which is expected. It does not explicitly exclude alternatives, but the context is clear enough for an AI agent to understand when to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. The description adds extensive behavioral context: it fans out across multiple sources (SEC EDGAR, XBRL, USPTO, GDELT, GLEIF), explains soft-failure of patents due to sunset, and details return fields (cik, filings, fundamentals, etc.). 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 dense but front-loaded with examples and key guidance. Every sentence carries weight, though it could be slightly more structured (e.g., bullet points for returned data). However, given the complexity, the length is justified.

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

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

No output schema exists, but the description compensates by detailing return fields and sources. Two required parameters are fully documented. For a tool of this complexity (multi-source, multiple sub-tools behind the scenes), the description 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% with descriptions for both parameters. The description adds significant meaning by specifying valid inputs (ticker like 'AAPL' or zero-padded CIK), explicitly excluding names, and referencing a sibling tool (resolve_entity) for alternative identification.

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

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

The description uses specific verbs like 'tell me about', 'research', 'brief me on' and clearly states it returns a 'full cross-source profile of a US public company in ONE parallel call'. It distinguishes itself from chaining single-pack lookups, making the purpose very 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 states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and 'names not supported (use resolve_entity first if you only have a name)'. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already mark destructiveHint=true, so the description's statement 'delete' is consistent. The description adds context about when to use, but no additional behavioral traits beyond annotations. Contributes some value without contradiction.

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

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

The description is two sentences with a clear action verb and context, front-loaded and efficient with no wasted words.

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

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

Given the tool has one parameter, no output schema, and clear annotations, the description provides sufficient completeness: it explains what the tool does, when to use it, and which tools to pair it with.

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 does not add extra meaning beyond the schema's description of 'Memory key to delete', so baseline 3 is appropriate.

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

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

The description clearly states 'Delete a previously stored memory by key.' The verb 'Delete' and resource 'memory by key' are specific, and it distinguishes from sibling tools 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?

The description provides explicit usage context: 'Use when context is stale, the task is done, or you want to clear sensitive data...' and mentions related tools ('Pair with remember and recall').

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds value by explaining the internal process (fetches page, extracts title/description/key links, emits markdown) and the output format (single text blob). No contradictions with annotations.

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

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

Three sentences cover purpose, process, and use cases. Front-loaded with the main action ('Generate a production-ready llms.txt file'). 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?

Given two simple parameters, no output schema, and clear annotations, the description fully covers what the tool does, how it works, and what the output looks like. No gaps remain for an agent to configure or invoke it correctly.

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

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

Schema coverage is 100% with descriptions for both parameters (url, max_links). The description adds context beyond schema by explaining that the output is a text blob ready for site-root/llms.txt and how the tool processes the URL. This enriches meaning beyond raw parameter names.

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

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

The description clearly states the tool generates an llms.txt file for a URL, specifying the action (generate), resource (llms.txt file), and scope (for any URL). It distinguishes from siblings like scan_competitor_ai_presence and ai_visibility_check by focusing specifically on producing the standardized llms.txt format, making it unique.

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

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

The description provides explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor indexing. This gives clear context for when to use. However, it does not explicitly state when not to use or list alternative tools, missing full exclusion criteria.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds the return format and usage context, complementing the annotations without contradiction.

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

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

Two sentences, front-loaded with purpose, no wasted words.

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

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

For a simple read-only list tool with good annotations, the description is complete: it explains what it does, what it returns, and when to use it.

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

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

Schema coverage is 100%, with description for the one parameter. The tool description does not add extra meaning beyond what is in the schema for this parameter.

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 lists the caller's active subscriptions and specifies the returned fields. Distinguishes from siblings like 'subscribe' and 'unsubscribe' by providing context for use.

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: to review monitored subscriptions before adding more or to find an id for cancellation. Though it doesn't mention alternatives, the 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 far more than the annotations convey. It explains the return token flow ('Filing without an account returns a `claim_token`; pass it back later... to read whether it was fixed and what changed'), rate limiting ('Rate-limited to 5 per identifier per day'), and side effects on roadmap ('signal directly affects roadmap'). It also tells users what not to do ('don't paste the end-user's prompt'), adding behavioral context the annotations lack.

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

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

The description is longer than average but every sentence earns its place. It is front-loaded with the core purpose and then proceeds logically through usage, exclusions, token flow, and rate limits. While it could be trimmed slightly, the structure is clear and the length is justified by the tool's complexity.

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

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

With no output schema, the description carries the burden of explaining return values. It does so thoroughly: 'Filing without an account returns a `claim_token`; pass it back later... to read whether it was fixed and what changed.' It also covers all parameter usage, constraints, and the tool's scope, 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the claim_token lifecycle (how to use it to check status) and elaborating on the message parameter ('Describe the issue in terms of Pipeworx tools/packs'). It also clarifies the enum values with examples. This lifts the score above baseline.

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

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

The description opens with a clear verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It further scopes the tool to 'this Pipeworx connection' and explicitly distinguishes it from sibling tools that answer questions or explore data. It even provides exclusion guidance for tools from other MCP servers, making the purpose unmistakable.

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

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

The description gives explicit when-to-use criteria: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also states when NOT to use it: if the tool came from a different MCP server, 'file it with that server instead.' This is excellent, actionable guidance that prevents misuse.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that data is self-aggregating, no PII, and cached 5min-1h, which provides additional behavioral context.

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

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

The description is concise with two paragraphs, front-loaded with key information. It uses bullet points for use cases, making it scannable. 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 the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains what is returned, the caching behavior, and the value proposition, leaving no obvious gaps.

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

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

Schema coverage is 100% with one parameter (window) with enum and description. The description adds context that shorter windows show hot trends while longer windows show steady-state demand, which enhances 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 it 'returns the top tools, top packs, and total call volume over a recent window', with specific timeframes. This distinguishes it from siblings by being a read-only discovery tool for trending usage.

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

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

Three explicit use cases are listed: discovering hot data sources, confirming canonical tool, and aligning use case. This provides clear guidance on when to use the tool.

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

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

Despite annotations already indicating readOnly, idempotent, and non-destructive, the description adds deep behavioral context: internal logic (similarity threshold, placeholder filtering, fill check), response structure, and edge cases. 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?

While front-loaded with core purpose, the description is lengthy with many details. Structure is logical (modes, filters, response, fill check) but could be slightly trimmed without losing information.

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

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

Covers all aspects: default behavior, two parameter modes, semantic anchor, partition filter, response fields, fill check, and referral to another tool for custom sizing. No output schema but response is fully described.

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

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

Schema coverage is 100% but description adds significant meaning: explains the difference between event and topic modes, gives concrete examples of valid inputs, and describes the underlying logic for each mode.

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

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

Description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) and contrasts with sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicitly says when to use each mode: call with no args for trending scan, event for a specific market, topic for cross-event scanning. Explains why cross-event mode is valuable and provides example inputs. Also includes fill check warning when not to trade.

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 and idempotent. The description adds extensive behavioral details: caching at KV level for 1 hour, response structure with diagnostics, edge calculation, per-field explanations, and model families. No contradictions with annotations.

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

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

The description is long but well-structured and front-loaded. Every sentence adds value, though some technical details could be streamlined. Overall, it's appropriately sized for the tool's complexity.

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

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

Despite no output schema, the description fully compensates by detailing the response structure (by_segment, diagnostics, field explanations) and handling edge cases like empty segments and Fed bets. It covers all aspects an agent needs to invoke and interpret results correctly.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema for each parameter. For example, slippage_pp explains Polymarket fee structure and fill assumptions; min_partition_leg_kelly clarifies why min_kelly doesn't filter partition arbs. All parameters gain meaningful context.

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

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

The description clearly states the tool scans Polymarket markets to find opportunities where Pipeworx data disagrees with market price. It explicitly states 'Built for "what should I bet on today"' and distinguishes itself from paging hundreds of markets, differentiating it from siblings like polymarket_arbitrage.

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

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

The description provides strong usage context: it's for discovering daily betting opportunities and includes tradeable-edge knobs and category filter. It mentions Fed bets are excluded from ranking, but does not explicitly state when not to use this tool versus alternatives like polymarket_arbitrage or polymarket_edge_tracker.

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 comprehensively discloses behavioral traits beyond annotations: read-only nature, snapshot structure, trend classification, decay calculation, expired opportunities, and limitations (60-day TTL, no intraday). 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 thorough but somewhat verbose, mixing purpose, input details, and response format. It is front-loaded but could be more concise while retaining all necessary information.

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

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

Given no output schema, the description fully explains the response structure (tracked, expired, snapshot_dates) with field details and interpretations, making it 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?

Input schema coverage is 100% with clear descriptions. The description adds default values and clamping ranges but does not significantly enhance understanding beyond the 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 clearly articulates the tool's purpose: edge persistence and decay telemetry. It answers specific questions and distinguishes from related tools like polymarket_edges by focusing on time-series 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 detailed context on when to use the tool, explaining the significance of edge age and decay. It does not explicitly state when not to use it or name alternative tools, but the usage 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 declare readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint false. Description adds rich behavioral context: walks the ladder, returns top_of_book, vwap_fill_price, slippage, shares_filled, max_fillable, verdict; basket mode returns theoretical vs realizable sums, thin_legs, forced_directional_risk. No contradiction with annotations.

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

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

Description is dense and informative but somewhat long. It front-loads purpose and required arguments, then details both modes and return fields. Every sentence adds value, but structure could be tightened slightly.

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

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

For a complex tool with two modes and no output schema, the description is remarkably complete. It explains return fields for both modes, includes practical caveats (thin books, partial fills), and gives usage context. No gaps identified.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. Description adds extra context beyond schema: default values (size_usd default 1000, clamp 10-1,000,000), side defaults (auto for basket), and behavior explanations (e.g., 'max spend on buys, target proceeds on sells').

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?

Purpose is explicitly stated: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes single-market and basket modes with clear verb+resource (check/fill risk) and differentiates from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also warns against using when books are thin or fills are partial, explaining the risk of unhedged directional positions.

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 read-only/idempotent annotations, the description discloses extensive runtime behavior: response composition, safety fields (compatibility_warning, compatibility_codes[]), pairing rules, per-entry flags, never-pairing of unknown legs, temporal_alignment semantics, and skipped counters. It even explains when premapped_pairing_unverified is always set. This is exceptional transparency about what the tool does and what the agent should inspect.

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 unusually information-dense: every sentence adds a caveat, a field explanation, or a usage rule. It front-loads the core purpose and the key warning. However, it is formatted as one continuous paragraph, and breaking the safety codes, modes, and response fields into lists would make it substantially more scannable. Minor structural inefficiency, but no filler.

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

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

Given there is no output schema, the description carries full responsibility for explaining return semantics, and it does so thoroughly: it names top_spreads_pp, compatibility_warning/codes, skipped_unclassified, low_confidence_pairs, temporal_alignment, and skipped counters. It also covers mode behavior and important caveats. An agent has enough information to invoke the tool correctly and interpret its results, which is complete for this level of complexity.

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

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

The schema already covers 100% of parameters with descriptions and examples, so the baseline is 3. The description adds substantive meaning on top: it enumerates the allowed topic values, defines explicit ticker/slug as overrides for the topic-mapped side, and explains how the two modes interact. It does not add much about ticker/slug format beyond the schema examples, but it clarifies the semantic relationship between parameters.

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

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

The description opens with a precise statement: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It names the exact resource, the two venues, and the operation, and distinguishes itself from sibling tools by emphasizing the same-question constraint and the two modes. This gives an agent a clear basis for selecting this tool over polymarket_arbitrage or polymarket_edges.

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

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

The description thoroughly explains both invocation modes: pre-mapped topic shortcuts and explicit ticker/slug pairings, and it clearly states when each is appropriate. It also adds a crucial usage caveat: 'pre-mapped ≠ tradeable' and warns that most topics return compatibility_warning today. However, it never explicitly contrasts this tool with sibling spread/edge tools or states when not to use it in favor of those 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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context about scoping (anonymous IP, BYO key, account ID) and the behavior of omitting the key (lists all). 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 concise, with no wasted words. It front-loads the action and provides essential details in a well-structured manner.

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

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

Given the tool's simplicity (one optional parameter, no output schema, thorough annotations), the description adequately covers retrieval, listing, scoping, and pairing. It is complete enough for an agent to use correctly.

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

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

Schema coverage is 100%, and the schema clearly documents the 'key' parameter. The description adds only marginal value by reiterating that omitting the key lists all keys, which the schema already states.

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's function: retrieving a saved value by key or listing all keys. It distinguishes itself from sibling tools like 'remember' and 'forget' by explicitly mentioning them and explaining the pairing.

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 guidance on when to use the tool—to look up previously stored context without re-deriving it. It mentions scoping and pairing with related tools. However, it does not explicitly state when not to use it or suggest alternative tools.

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

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

Discloses important behavioral details beyond annotations: mark_read mutates state by flagging events as read, affecting future calls. Also confirms polling safety. Annotations declare readOnlyHint=true, but description clarifies the non-destructive side effect.

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, tightly written. Front-loads the core purpose, then details fields, filtering, side effects, and alternatives. Every sentence adds value with no redundancy.

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

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

Despite no output schema, description covers key return fields. Missing details on limit parameter and unread_only behavior, but overall complete enough for a read-only polling tool with good annotations.

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

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

Schema coverage is 100% with parameter descriptions. The description adds some value (e.g., clarifying mark_read effect) but largely rephrases what is already in the schema. Baseline 3 is appropriate.

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

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

Description clearly states the tool 'pull fired events from your subscription feed' and specifies that it returns recent alerts with source, citation_uri, and raw payload. It distinguishes itself from siblings like list_subscriptions by focusing on event retrieval with filtering.

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 context for polling ('polls work fine') and mentions an alternative HTTP endpoint for scripts/dashboards. However, it does not explicitly compare with sibling tools like 'subscribe' or 'list_subscriptions' to guide when to use this tool versus them.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is clear. Description adds useful behavioral details: data sources, fallback behavior (GDELT→GNews), and USPTO soft-fail. 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?

Description is dense but front-loaded with examples. Some technical details could be more structured, but every sentence adds value. Could be slightly more concise.

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

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

Despite no output schema, description explains return structure (grouped changes by source, total_changes count, pipeworx:// URIs). Also covers failure modes and limitations, making it self-contained for agent invocation.

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

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

Schema description coverage is 100%, but description adds value beyond schema: explains enum limitation, gives examples for 'since' and 'value', and recommends typical usage ('30d').

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

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

Description clearly states the tool provides a change feed for a company, fanning out to multiple sources. It distinguishes itself from sibling tool entity_profile by specifying when to use each.

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

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

Explicitly provides when-to-use and when-not-to-use guidance: 'Use entity_profile instead when you want the static profile...' Also gives example queries and 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?

The description adds useful behavioral context beyond annotations: it explains memory persistence (24 hours for anonymous, persistent for authenticated), scoping by identifier, and the key-value storage model. Annotations already indicate idempotent and non-destructive, which the description does not contradict.

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

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

The description is concise (three sentences) and well-structured. It starts with the core purpose, then provides usage guidance, and ends with pairing with other tools. Every sentence adds value without repetition.

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

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

The description covers all essential aspects: purpose, when to use, data persistence, scope, and integration with recall and forget. For a simple key-value store with no output schema, it provides sufficient context for correct tool 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 input schema has 100% coverage with descriptions for both 'key' and 'value'. The description adds context about usage (e.g., naming conventions for keys) but does not significantly extend the schema's explanation beyond examples. Baseline score of 3 is appropriate.

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

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

The description clearly defines the tool's purpose: saving data for reuse across conversations or sessions. It uses specific verbs ('save', 'reuse') and distinguishes from sibling tools like recall and forget by explaining the pairing.

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

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

The description explicitly states when to use the tool ('when you discover something worth carrying forward'), provides examples of data to save, and mentions alternatives (recall, forget). It also clarifies scope and persistence differences between authenticated and anonymous sessions.

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 readOnly/openWorld/idempotent/non-destructive, and the description adds critical behavior beyond them: non-equity instruments resolve, ambiguous matches return figi_candidates instead of asserting, unresolved identifiers are explicitly listed, and enrichment degrades gracefully. This governs agent expectations without contradicting annotations.

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

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

The description is long but earns its length by packing dense, operational detail. It front-loads the trigger phrases and 'Use FIRST,' then organized supported types. Some parenthetical asides are heavy, but every sentence adds behavioral or usage information an agent needs.

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 2-parameter, read-only lookup with no output schema, the description fully explains input forms, resolution behavior, edge cases, and fallback semantics. There is no gap an agent would face when deciding to call it or interpreting ambiguous returns; the shared output-shape conventions for identifiers are sufficiently described.

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 substantial meaning beyond schema: input examples, what 'value' means for an entity name, the exact form for issuers, why trailing security-class words break matches, and per-type resolution behavior. Slight redundancy with enum descriptions but clearly adds value.

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

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

The description opens with concrete user phrasing and a crisp statement of purpose: resolve a user-spoken NAME to canonical identifiers, with supported types company and drug. It differentiates from siblings by noting it produces IDs other tools require, and contrasts with entity_profile/compare_entities implicitly. Highly specific verb+resource.

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

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

Explicitly says 'Use FIRST whenever you have a name but need an ID,' lists accepted input formats, distinguishes instrument vs issuer matching for bonds, and documents graceful degradation when enrichment sources fail. It clearly signals when to choose this tool and warns against passing full noun phrases, exceeding minimal usage guidance.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are present and consistent. The description adds behavioral context by explaining the probing mechanism (calls ai_visibility_check for each entity), ranking logic, and output fields (score, confidence, signal density). 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 two sentences long, front-loaded with the primary action, and packs in all essential information: purpose, method, use case, and output. No filler or redundancy.

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

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

Given no output schema, the description adequately specifies return format (ranked list with score, confidence, signal density). It explains the multi-step process without being overly verbose. Minor gap: does not explicitly mention the default model or that _apiKey is only needed for Anthropic, but those are in the schema.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining that the first entity is treated as the 'subject' and that the context parameter disambiguates common names. This goes beyond the raw schema descriptions.

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

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

The description clearly states it compares AI visibility across multiple entities, uses ai_visibility_check, ranks by score, and returns a ranked list. It distinguishes from siblings like ai_visibility_check and compare_entities by focusing on multi-entity comparison for AI presence audits.

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

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

The description provides a clear use case ('competitive AI-marketing audits') and contextualizes with an example question. It implicitly suggests using ai_visibility_check for single entities, but does not explicitly state when not to use this tool or list alternatives.

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

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

Annotations already signal read-only, idempotent, non-destructive behavior. The description adds crucial details like partial failure graceful degradation, bundlephobia first-measurement timeout (5-30s), and how failures are reported in sources_failed. No contradictions.

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

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

The description is a single dense paragraph, front-loading purpose, then use cases, return format, and limitations. No unnecessary words; each sentence earns its place.

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

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

Given the tool's complexity (multiple external APIs, composite result), the description covers purpose, usage, input format, return fields, failure modes, and ecosystem scope. No output schema exists, but the description lists all return fields explicitly.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds practical usage notes: scoped packages are accepted, default version is latest. This enriches 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 composite nature of the tool, which is a one-call check for npm package addition across deps.dev and bundlephobia. It specifies the verb ('check') and resource ('npm package'), and implicitly distinguishes from related sibling tools like resolve_entity or deps.dev:version calls.

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

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

Explicit guidance is provided: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also explains ecosystem limitations and alternatives for non-npm packages.

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

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

Annotations declare readOnly, openWorld, idempotent, non-destructive. Description adds specifics: uses BGE-base-en embeddings + cosine over 500-char windows, 200K char cap, truncation behavior flagged. 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?

Description is a paragraph with some technical details but not overly verbose. Could be slightly more structured (e.g., bullet points) but still efficient.

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

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

No output schema, but description explains return format (passages with offsets and similarity scores). Covers input limits and behavior. Lacks details on error handling but generally complete.

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

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

Schema coverage is 100% with descriptions for all parameters. Description adds minimal extra meaning beyond schema (e.g., examples for query). Baseline 3 is appropriate.

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

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

Description clearly states 'Semantic search INSIDE a fetched record', specifying the action (search inside), resource (fetched record), and method (semantic search returning passages). It distinguishes from siblings by mentioning it pairs with ask_pipeworx_grounded.

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

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

Provides explicit when-to-use: 'when the record is too big to cram into the prompt' and mentions alternative pairing with ask_pipeworx_grounded. Lacks explicit 'when not to use' but gives 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?

The description thoroughly explains behavioral traits beyond annotations: return value (subscription ID), mutating nature (create), account requirements, type-specific filtering details, delivery channel behavior (feed always on, email/SMS/webhook with rates and verification), and webhook auto-disable. It aligns with annotations (readOnlyHint false, destructiveHint false) and adds significant context.

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

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

The description is well-structured: first sentence gives core purpose, then prerequisites, then types, then delivery channels. It is dense but not verbose. Minor wordiness could be trimmed, but overall it is efficiently front-loaded.

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

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

Given the tool complexity (3 params, nested objects, no output schema), the description is comprehensive. It covers all aspects: return value, subscription type details, delivery mechanisms, limitations (SMS cap, webhook secret), and how to access the feed (via recent_alerts or GET URL). No output schema is needed because the return is simply the ID.

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

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

The description adds substantial meaning beyond the input schema: for each subscription type, it provides concrete examples, field explanations (e.g., items codes like '5.02' for officer change), and required versus optional fields. Schema coverage is 100%, and the description enriches the semantics considerably.

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 explicitly that the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription ID. It uses specific verbs and clearly identifies the resource (subscription). This distinguishes it from siblings like list_subscriptions and unsubscribe.

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

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

The description specifies prerequisites (Pipeworx OAuth account), supported subscription types and their parameter patterns, and delivery channels. It implicitly differentiates from other tools but does not explicitly state when not to use it or list alternatives. The guidance is clear and actionable.

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

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

Annotations already provide readOnly, openWorld, idempotent, non-destructive hints. Description adds that output is category-bucketed example questions drawn from live catalog, and non-argument call gives full spread. 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?

Description is somewhat long but front-loaded with purpose and examples. Structured list of categories and explanation. Every sentence adds value; could be slightly more concise but not wasteful.

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

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

For an onboarding tool, description covers purpose, usage, examples, relation to other tools, return structure (category-bucketed example questions with tool+argument shapes). No output schema but description sufficiently explains what to expect.

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

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

Only one optional parameter 'topic' with schema description. Description adds explicit topic examples (finance, pharma, etc.) and explains how it focuses output. Schema coverage 100% raises baseline to 3; description adds clear value.

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

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

Description clearly states tool is an onboarding entry point, returns category-bucketed example questions with tool+argument shapes, and lists specific use cases. It distinguishes from siblings like ask_pipeworx by being the first call when unsure.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Describes when to call with/without 'topic' and what happens in each case.

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

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

Annotations already indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true). Description adds ownership enforcement and clarifies deactivation vs deletion, providing beyond what annotations provide.

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

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

Three sentences, front-loaded with the core action, no wasted words. Efficient and clear.

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

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

For a simple single-parameter mutation with no output schema and rich annotations, the description covers ownership, effect on data, and idempotency implication, making it fully complete.

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

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

Schema description coverage is 100% for the single parameter 'id', so the description adds no extra meaning beyond the 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 'Cancel' and resource 'subscription by id'. It clearly differentiates from sibling tools 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?

States ownership enforcement ('only cancel your own subscriptions') and notes that the row is deactivated not deleted, providing context for when to use. Could mention explicit 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 indicate read-only/idempotent behavior, but the description adds depth by explaining verdict semantics, the meaning of `could_not_verify` (check did not happen, not evidence), and `unsupported` (no source found). It also flags that `could_not_verify` carries a `verification_error` and must not be treated as a verdict. This surpasses annotation-only 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 longer than typical, but every sentence adds vital information: trigger phrases, routing, verdict list, error-handling instruction, and efficiency claim. It is front-loaded with the key purpose and usage, making the initial scanning easy.

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 compensates fully by listing the verdict values, the presence of a citation, reasoning, and the error payload. It covers the two routing paths and explains edge cases. The tool's complexity is high, and this description addresses all key aspects an agent needs to invoke it 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 the schema already fully describes both parameters, the description adds crucial semantic nuance: `tolerance_pct` overrides the tolerance implied by the claim wording and that it defaults to wording-based (capped at 5). It also gives a concrete example of the `claim` parameter, clarifying natural-language format 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 opens with natural-language phrasing and clearly states the tool's function: 'natural-language claim verification against authoritative sources.' It distinguishes itself from siblings by describing its two-pipeline behavior (SEC EDGAR for company-financial claims, grounded pipeline for everything else) and explicitly notes it replaces 4–6 sequential calls, making the unique value proposition obvious.

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

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

It explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It further gives granular guidance on when the structured SEC path applies versus the grounded fallback, and warns what `could_not_verify` means for callers. This is strong when-to-use guidance with clear routing logic.

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