Paris Events

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

Annotations declare safe, read-only behavior; description adds context about API key passthrough, payment, and return structure (per-model and combined view). 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?

Single concise paragraph with front-loaded action and scoring. Efficient but slightly dense; could benefit from minor structuring.

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?

Describes return shape (score, confidence, signals, raw_response, combined view) despite no output schema. Covers parameters and use cases adequately. Lacks error handling details.

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

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

Schema coverage is 100%, but description adds value by clarifying default model, optional _apiKey purpose, and context usage for disambiguation.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility. It specifies default model and optional Anthropic probing, differentiating it from sibling tools 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?

Explicitly mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. Explains model selection and API key requirement for Anthropic, but does not explicitly list alternatives or when not to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable context: routing behavior, citation URIs, 'one fast call', and default entry point. 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?

Long but well-structured, with key info front-loaded. Each section (preference, routing, examples, alternatives) earns its place. Slight redundancy between 'Use whenever' and 'START HERE' 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 a complex tool with no output schema, the description covers what it does, when to use it, what it returns (structured answer with citation URIs), and how to escalate. Missing error handling but overall 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 covers all 6 parameters with descriptions (100% coverage), so baseline is 3. Description provides examples of natural language questions but does not add specific parameter constraints or formats beyond schema.

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

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

Clearly states it routes questions to 5,529 tools across 1,455 verified sources and returns structured answers with citations. Distinguishes from siblings by naming ask_pipeworx_grounded and deep_research as alternatives.

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

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

Explicitly advises 'PREFER OVER WEB SEARCH', gives specific trigger phrases ('what is', 'look up', 'find'), and says 'START HERE for most questions'. Also explains when to step up to ask_pipeworx_grounded or deep_research, and notes breaking news is handled.

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?

Adds important behavioral context beyond annotations: candidate routing improvements may be active, currently none (last retired 2026-07-26), so it matches ask_pipeworx exactly. This discloses the experimental nature and current exact equivalence, which is crucial for an agent. No contradiction with readOnlyHint or other 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 efficiently structured and front-loaded. Each sentence adds value: definition, current status, usage instruction, and clarification that it's a full router. No waste 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 the tool's complexity as a router to 5,529 tools, the description covers all essential aspects: identical to ask_pipeworx, current experimental status, usage, and the fact it's a full working router. No output schema exists, but 'same response shape' suffices.

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

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

Input schema has 100% coverage with detailed descriptions for all 6 parameters, including aliases. The description only says 'same arguments' without adding meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it is a beta universal router identical to ask_pipeworx, routing questions to the same 5,529 tools. It explicitly differentiates itself from the stable ask_pipeworx by being the experimental edge, satisfying the verb+resource+distinction criteria.

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

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

Provides explicit guidance: 'Use it exactly like ask_pipeworx when you want the newest routing', and contrasts with the stable router by noting results are compared to decide merges. This clearly tells when to choose this tool over the sibling.

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

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

The description adds substantial behavioral context beyond annotations: it discloses that the tool makes an extra LLM call, returns evidence quotes and confidence scores, and explicitly refuses to answer when data is insufficient, including specific refusal reasons. This is far more transparent than the annotations alone.

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 then builds logically: routing, extraction behavior, return shape, refusal cases, use cases, and cost trade-off. Every clause adds distinct information, and the length is justified by the tool's behavioral 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 having no output schema, the description fully covers return values, failure modes, and usage context. It also differentiates from ask_pipeworx and discloses performance cost. This makes it complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100% and the description does not add parameter specifics beyond what the schema already documents. The question aliases are clearly enumerated in the schema, so the description appropriately relies on that. Baseline 3 is therefore 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 states a specific verb+resource: 'hallucination-resistant answer mode' that 'EXTRACTS the answer using ONLY what the tool result contains.' It clearly distinguishes itself from sibling ask_pipeworx by emphasizing grounded, evidence-backed answers for high-stakes reads.

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

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

Explicit usage guidance is provided: 'Use whenever an answer will be quoted, cited, or acted on' and 'prefer ask_pipeworx for casual lookups.' This directly addresses when to use the tool versus the alternative ask_pipeworx.

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 many behavioral traits beyond annotations: RESOLVER CONTRACT with confidence levels, low-confidence short-circuit behavior, closed market handling, wide-spread market warnings, resolution-rule risk, and cancellation rule parsing. Annotations already indicate read-only/idempotent; description adds critical safety and edge-case 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 long but necessary due to complexity. It uses clear section headers (RESPONSE SHAPES, RESOLVER CONTRACT, etc.) and front-loads the main purpose. Every sentence adds value, though it could be slightly more concise.

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

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

Given the tool's complexity and absence of an output schema, the description covers response shapes, evidence structure, error handling (429 retries), status codes, resolver contract, parent_event extractor, and safety mechanisms. It leaves very little ambiguous 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%, but description adds meaning: explains 'market' as slug/URL/question text, 'depth' with quick/thorough definitions, and 'include_raw' with size implications. Goes beyond the basic 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 states it researches a Polymarket bet by pulling Pipeworx data, specifying inputs (slug, URL, question text) and outputs (evidence packet + comparison). It provides clear verb+resource but does not explicitly differentiate from sibling tools 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?

Explicitly states use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z') and provides extensive examples of fan-out. Lacks explicit when-not-to-use or alternative tools, but the context is very 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 readOnlyHint=true, openWorldHint=true, etc. The description adds significant behavioral details: data sources (SEC EDGAR, FAERS), handling of off-calendar fiscal years, sorting by primary metric, and return of citation URIs. It also states the tool replaces many sequential lookups. 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 slightly long but well-structured. Trigger phrases are front-loaded in quotes, and key usage details follow. Every sentence adds value, though some minor redundancy exists (e.g., repeating 'type="company" pulls'). Still, it is efficient for the information conveyed.

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

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

Given only 2 parameters, no output schema, and simple annotations, the description provides adequate context. It covers what data is returned (paired data, citation URIs) and behavior (sorted by primary metric). While the exact output format isn't detailed, it is sufficient for an agent to understand usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining that 'values' should be tickers/CIKs for company and drug names for drug, specifying min/max items, and giving examples. This goes beyond the schema's description.

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

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

The description explicitly states the tool performs side-by-side comparison of 2-5 companies or drugs, provides trigger phrases like 'X vs Y' and 'compare', and distinguishes itself from sequential lookups. This gives a clear and specific purpose.

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

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

Clear when-to-use guidance is given: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities'. It specifies the number of entities, data sources for each type, and examples of triggers. This effectively differentiates from sibling tools like entity_profile.

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?

Goes far beyond the readOnly/openWorld/idempotent annotations by disclosing account/paywall requirements, parallel decomposition across 5,529 tools, gaps[] for unanswered facets, a never-invented guarantee, contradictions[] scanning, semantic excerpting of large records, and expected latency. This is exhaustive behavioral disclosure.

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

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

The description is long but information-dense, and every section (auth, use case, process, output guarantees, latency) serves a purpose. Minor redundancy exists (e.g., two mentions of structured vs. open-web nature, repeated pipeworx:// citation details), preventing a perfect score, but the structure is logical and front-loaded with the most critical constraint (account required).

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

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

For a tool with no output schema, the description fully covers the return format (findings packet with verbatim evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[]), authentication prerequisites, edge-case behavior for current-news topics, and timeouts. It is complete enough for an agent 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% for both parameters, but the description enriches meaning: question is defined as natural-language, broad/multi-part okay; depth options are explained in terms of facet count, gap-recovery hops, contradictions scanning, and paid plan requirements. This adds crucial decision-making context beyond the schema enum labels.

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 action ('Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources') and contrasts with open-web search. It explicitly distinguishes itself from ask_pipeworx as the tool for broad/multi-part structured data questions, making its purpose and scope unmistakable.

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

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

Provides explicit when-to-use and when-not-to-use guidance: 'For a single lookup use ask_pipeworx' and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx', plus a note that unsigned users should use ask_pipeworx instead. This clearly maps use cases to 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?

The description goes beyond annotations by stating results are 'ready to call directly' and require 'no second schema lookup'. It reinforces the read-only, idempotent nature. 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 5-6 sentences, each serving a purpose: statement of purpose, use cases, output description, and usage guidance. No wasted words, well-structured.

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

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

For a simple discovery tool with no output schema, the description covers when to use, what it does, and what it returns. It could mention sorting by relevance, but it's not critical for usability.

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 good parameter descriptions and examples. The description does not add new semantic value beyond schema, but it reinforces the concept of aliases. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It is specific, uses action-resource pairing, and distinguishes itself from siblings as the primary tool discovery mechanism.

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 advises: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It provides clear when-to-use context and lists example domains, though it does not explicitly state when not to use, the guidance is strong enough.

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

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

The description adds significant behavioral context beyond annotations, such as the data sources used, return structure, patents soft-fail after May 2025, and the preference for parallel calls. No contradiction with annotations.

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

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

The description is a single dense paragraph, front-loaded with example queries. While it is somewhat lengthy, every sentence adds value and 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 the tool's complexity and lack of an output schema, the description comprehensively explains the return fields (CIK, filings, fundamentals, patents, news, LEI) and limitations, making it fully informative for an agent.

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

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

Schema coverage is 100% and both parameters are well documented in the schema. The description reiterates the same information without adding new semantic details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it provides a full cross-source profile of a US public company in one parallel call. It distinguishes from sibling tools like resolve_entity and compare_entities by explicitly stating when to prefer this tool over chaining single-pack lookups.

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

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

The description explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and warns that names are not supported, directing to use resolve_entity first. Both when-to-use and when-not-to-use are 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 confirm read-only, idempotent, non-destructive behavior. The description adds that results are sorted by start date and that titles/descriptions are in French, which provides modest additional behavioral context beyond annotations.

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

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

The description is two succinct sentences, front-loading the core purpose and key filters. Every sentence adds value, with no redundancy or extraneous information.

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

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

For a read-only event search with 6 optional parameters and no output schema, the description covers main filters, sorting, and language. It is mostly complete, though pagination (offset) behavior or default date windows could be mentioned.

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 restates filtering dimensions already present in the schema (keyword, free, date window) without adding new semantic detail beyond what the schema provides.

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

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

The description clearly states the tool finds current 'things to do' in Paris from the official City of Paris events API, with specific filter options (keyword, free, date window). It distinguishes itself effectively from sibling tools, none of which target events.

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

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

The description implies usage for finding Paris events but lacks explicit guidance on when to use vs alternatives. No 'when not to use' or comparison to siblings is provided, leaving the agent to infer context.

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

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

Annotations already convey destructiveHint=true and idempotentHint=true. The description adds context about clearing 'sensitive data', which is a mild behavioral nuance. 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 two sentences, front-loaded with the core action, and no extraneous information. Every sentence adds value, achieving conciseness.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose, usage, and behavioral hints. It does not specify behavior for missing keys, but this is minor given idempotent hint.

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

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

Schema coverage is 100%, with the parameter 'key' described as 'Memory key to delete'. The description does not add significant meaning beyond that, 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 'Delete a previously stored memory by key', specifying a concrete verb (delete), resource (memory), and mechanism (by key). This distinguishes it from sibling tools '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 explicitly provides when-to-use scenarios: 'context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with 'remember' and 'recall', giving clear usage context.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds that it fetches the page and extracts specific elements, providing useful context beyond annotations. 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 concise paragraph, front-loaded with the primary action. It efficiently conveys purpose and use cases without unnecessary fluff.

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

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

The description explains the output format (standard llms.txt markdown) and its intended placement, compensating for the lack of an output schema. Complexity is low, and the description is complete enough.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool generates an llms.txt file for a URL, specifying the actions (fetch page, extract title/description/key links) and output format. It is distinct from siblings like 'scan_competitor_ai_presence' and 'ai_visibility_check'.

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

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

The description lists specific use cases: getting a client's site indexed, drafting for own project, or auditing a competitor. While not explicitly stating when not to use, the context is clear and sufficient for an agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific return fields and context, aligning with 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 efficient sentences: first states purpose and output, second provides usage guidance. No wasted words, 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 simple signature (one optional param) and rich annotations, the description covers purpose, return fields, and usage adequately. No missing context.

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

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

Schema description coverage is 100% for the single parameter. Description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

Clearly states the verb 'List' and the resource 'the caller's active subscriptions', and lists the return fields. Distinguishes from sibling tools like subscribe/unsubscribe.

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

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

Explicitly tells when to use the tool: 'review what you're monitoring before adding more or to find an id to cancel', providing clear context and implicit 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 are all false, so the description carries the transparency burden. It discloses rate limiting (5 per identifier per day), the free/quota status, and the claim_token pattern (filing without an account returns a token; passing it later reads status). Does not fully describe the side effect of sending data to the team, but the core mutation is clear. No contradiction with annotations.

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

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

The description is a single dense paragraph, but every sentence adds operational value (scope, usage, claim_token workflow, rate limits, quota). It is front-loaded with purpose and flows logically. Slightly long 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?

Given the tool has 4 parameters, a nested context object, and no output schema, the description covers all important aspects: categories, scope boundaries, claim_token workflow, and limits. Minor omissions like what an account-based report returns do not significantly reduce completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful guidance beyond the schema: explains how to use claim_token ('pass it back later'), what message should contain ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), and scopes 'context' to relevant tools/packs. This enriches parameter understanding beyond field descriptions.

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

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

The description opens with a specific verb ('Tell the Pipeworx team') and a clear resource (feedback about broken, missing, or desired tools). It distinguishes itself from sibling research/memory tools by explicitly scoping to Pipeworx-served tools and mentions 'bug', 'feature/data_gap', and 'praise' categories.

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

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

Provides explicit when-to-use guidance with concrete examples ('Use when a tool returns wrong/stale data...') and an exclusion rule for tools from other MCP servers. Also instructs how to distinguish Pipeworx tools and how to use the claim_token workflow to check resolution status.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds data sourcing (CF analytics-engine, no PII) and caching behavior (5min-1h), which are beyond annotations. No mention of auth or rate limits, but overall good.

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

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

Three concise sentences with no wasted words. Front-loaded with purpose, then use cases, then technical detail. Structure is optimal.

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?

Adequate for a simple, well-annotated tool with one optional parameter. Describes return content (top tools, packs, volume) and data source. No output schema, but description covers key aspects.

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

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

Schema covers 100% of parameter with enum and description. Description reinforces window implications (shorter for hot, longer for steady-state), adding marginal 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?

Clear verb 'returns' and specific resources 'top tools, top packs, and total call volume'. Distinguishes from siblings like ask_pipeworx (Q&A) and discover_tools (exploration).

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

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

Lists three explicit use cases (discovering hot data sources, confirming canonical tool, checking alignment). Provides window selection guidance. No explicit when-not-to-use or sibling comparisons, but context 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 rich behavioral context beyond annotations: explains Jaccard similarity anchor, partition placeholder filter, and fill check logic. No contradiction with readOnlyHint or other 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?

Well-structured with clear sections (modes, details, response). Though lengthy, every sentence adds value; could be slightly tighter but remains informative without redundancy.

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

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

Despite no output schema, description fully explains return structure (opportunities array, partition_check object) and covers edge cases (low similarity, placeholder filtering, fill check). Complete for a complex tool.

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

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

Schema already covers both parameters well (100% coverage), but description enriches with usage guidance, examples (e.g., 'fed-decision-may-2026'), and explains behavior for each mode, including the no-arg case.

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

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

Clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. Differentiates between event and topic modes, and distinguishes from siblings 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 explains when to use no args (trending scan), event mode (single event), or topic mode (cross-event scan). Provides examples of valid inputs and warns when not to trade (realizable_edge_pp ≤ 0).

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 extensive behavioral traits beyond annotations: model families, slippage handling, Kelly sizing, tradeable-edge filters, response structure with diagnostics, and caching. No contradiction with annotations.

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

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

The description is long and dense with technical detail. While well-structured into sections, it is not concise and could be trimmed for better readability without losing essential information.

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

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

For a complex tool with 9 parameters, no output schema, and nested logic, the description is thorough, covering response structure, edge calculation, filtering knobs, and limitations (fed bets). It provides sufficient information for correct 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?

All 9 parameters have schema descriptions (100% coverage), and the tool description adds significant meaning by explaining relationships between parameters (e.g., min_kelly vs min_partition_leg_kelly), sensible defaults, and usage scenarios.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It includes the use case 'what should I bet on today' and distinguishes it from siblings by focusing on Pipeworx data disagreement and segmentation.

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

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

The description provides clear context on when to use the tool (discovering betting opportunities) and details about caching and knobs, but 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: response structure (tracked, expired, snapshot_dates), data source (daily snapshots), limitations (60-day TTL, snapshot gaps, decay computed from daily closes). 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 longer but well-structured: purpose sentence, key question, args, detailed response breakdown, and limitations. Every sentence is informative. Slight density prevents a 5, but it remains focused 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?

With no output schema, the description thoroughly explains the response fields (tracked arrays with time-series, trend, decay; expired with lifespan; snapshot dates) and limitations. For a read-only tool with 2 parameters, this covers all needed context for an agent to understand what it returns and its constraints.

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

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

Schema coverage is 100%, providing names and descriptions. The description adds value beyond: default values (14 days, '1wk' window), clamping range for 'days' (2-30), and explanation of 'window' as snapshot family. This enriches the semantic meaning for an agent.

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

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

The description starts with a clear verb+resource: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It explicitly states the question it answers, making the tool's purpose highly specific and distinguishable from sibling tools like 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 provides strong usage context by contrasting a fresh edge vs. an old one, implying when this tool is valuable. It does not explicitly mention when not to use or give alternatives, but the sibling list includes polymarket_edges, and the description clarifies this tool is derived from those snapshots.

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, non-destructive. Description adds context: 'walks the ladder', 'thin books not capturable', 'partial basket fills convert an arb into an unhedged directional position.' 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 long but well-structured with sections (SINGLE-MARKET, BASKET) and bold/uppercase emphasis. Every sentence adds value; could be slightly more concise 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?

Despite no output schema, description comprehensively explains return fields for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, verdict, per-leg detail, thin_legs, etc. Covers use cases, risks, and input requirements completely.

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

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

Schema coverage is 100%, but description adds defaults (size_usd=1000, side defaults), interpretations (size_usd as spend vs proceeds for single-market; settlement notional for basket), and clamp range 10–1,000,000. Also explains side default logic in basket 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?

The description clearly states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes, lists outputs, and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains consequences of not using it (partial fills leading to unhedged directional risk).

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 complemented by extensive behavioral details: compatibility_warning cases, temporal_alignment, skipped counters, and explanation of when spreads are meaningless. No contradiction with annotations.

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

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

The description is moderately long but well-structured with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence adds value; no fluff. Could be slightly more concise but highly informative.

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

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

Given no output schema, the description explains the response structure (leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). It covers edge cases (non-equivalent bet shapes, unrelated events) thoroughly. Complete for a complex tool.

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

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

Schema coverage is 100% with descriptions for each parameter. The description adds meaning by explaining that topic overrides via explicit tickers, listing all macro shortcuts, and clarifying that explicit pairings require overriding. Adds value beyond the schema.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It uses specific verbs ('compute spread') and names both venues, distinguishing it from all sibling tools (no other cross-venue spread tool).

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

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

The description explains two modes (topic shortcuts vs explicit tickers) and provides strong guidance: warns that most pre-mapped topics return compatibility warnings, and that 'pre-mapped ≠ tradeable'. It lacks explicit 'when not to use' but the warnings serve that purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scope by identifier and pairing info, but no new behavioral traits beyond annotations.

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

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

Three sentences, front-loaded with main purpose, followed by usage context and pairing. No unnecessary words; every sentence earns its place.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description fully covers purpose, usage, scoping, and pairing. No gaps.

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

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

Parameter 'key' has schema description stating 'omit to list all keys'. Description adds usage examples and clarifies behavior when key is omitted. Schema coverage is 100%, but description 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 clearly states the tool retrieves a value saved via remember or lists all keys, with specific verb 'retrieve'/'list' and resource 'previously saved value'/'saved keys'. It distinguishes from siblings like remember and forget.

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

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

Describes when to use it: to look up context stored earlier without re-deriving. Explains scoping and pairing with remember/forget. Lacks explicit when-not-to-use, but context is clear given siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the side effect of mark_read (flagging events as read), the return field details, and the fact that the same feed is accessible via an alternative endpoint. No contradictions with annotations.

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

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

The description is a single paragraph of about 4 sentences. It is front-loaded with the main action and uses clear language. While it could be broken into bullet points for readability, it remains concise and free of unnecessary words.

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

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

Given no output schema, the description adequately explains return contents (source, citation_uri, payload). It covers filtering options and the mark_read side effect. However, it lacks details on pagination, error handling, or behavior when limit is exceeded. Annotations cover safety, so overall it is fairly complete.

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

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

Schema coverage is 100%, so the schema documents parameters. The description adds context by explaining the purpose of mark_read, unread_only, and providing examples (e.g., 'sec_8k' for type, ISO timestamp for since). This goes beyond what the schema provides, earning 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 clearly states 'Pull fired events from your subscription feed' as the main purpose. It specifies the return content (source, citation_uri, raw payload). However, it does not explicitly differentiate from sibling tools like 'events' or 'list_subscriptions', which could have overlapping functionality.

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

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

The description explains how to use parameters for filtering (type, since) and state management (mark_read). It also mentions that polling is acceptable and provides an alternative access endpoint. However, it does not explicitly state when not to use this tool or compare it to alternatives like 'events'.

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

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

The description goes well beyond annotations (readOnlyHint, idempotentHint, destructiveHint, openWorldHint) by detailing the multi-source fan-out behavior, fallback logic (GDELT→GNews on rate limits/5xx), USPTO soft-fail due to PatentsView sunset, and return structure (changes[], total_changes, pipeworx:// URIs). No contradiction with annotations.

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

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

The description is a single dense paragraph but every sentence provides essential context (query examples, tool behavior, fallback, return structure, alternative). It is concise with no fluff, though a slight structural break (e.g., bullet points) could improve scanability. Still, it earns its length.

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

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

Given 3 parameters, no output schema, and comprehensive annotations, the description covers all necessary aspects: what the tool does, how multiple sources are queried, fallback behavior, return format, and when to use an alternative. It fully equips an agent to invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions for all 3 parameters, so the baseline is 3. The description adds value by including usage examples (e.g., 'Use "30d" or "1m" for typical monitoring') and explaining the relationship between 'since' and supported formats, which enhances the schema's basic description.

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

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

The description starts with concrete example queries ("What's new with X", "latest on Y"), clearly states it provides a change feed for a company within a time window, and explicitly distinguishes itself from the sibling tool entity_profile by specifying when to use the alternative.

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

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

The description provides explicit guidance: 'Use entity_profile instead when you want the static profile... regardless of window.' This clearly states when not to use the tool and names the appropriate alternative, leaving no ambiguity about selection.

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

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

Annotations already indicate idempotentHint=true, but the description adds context about storage being scoped by the agent identifier and persistence duration (24 hours for anonymous, persistent for authenticated). This provides behavioral transparency beyond annotations. 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 concise at around 80 words, with the purpose stated in the first sentence. Every sentence adds value, and there is no redundant or extraneous information.

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

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

Given the tool's simplicity (2 required params, no output schema), the description is fully complete. It covers purpose, usage, pairing, scope, and persistence, leaving no gaps for the agent.

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

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

The input schema has 100% parameter description coverage, so baseline is 3. The description adds examples of key ('subject_property') and value ('findings, addresses'), but does not add substantial new semantic meaning beyond what the schema already provides.

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

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

The description uses a specific verb 'Save' and resource 'data' and clearly explains the tool's purpose: storing data for later reuse across conversations or sessions. It distinguishes itself from siblings like 'recall' and 'forget' by mentioning pairing, making purpose unambiguous.

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

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

The description explicitly states when to use the tool ('when you discover something worth carrying forward') and provides examples. It also covers scope differences (authenticated vs. anonymous) and recommends pairing with 'recall' and 'forget', offering clear 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 already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond that: it discloses graceful degradation ('if GLEIF or OpenFIGI is unavailable, the EDGAR identifiers still return'), explicit handling of unresolved identifiers ('stated explicitly under `unresolved` rather than omitted'), and the internal cascading lookup behavior. No contradiction with annotations.

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

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

The description is long and dense, but it is front-loaded with concrete examples and then explains supported types and edge-case behavior. Every sentence conveys needed information, though a structured list of types would improve scannability. It earns its length given the complex 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?

Despite no output schema, the description thoroughly explains what is returned (identifiers with source labels, unresolved field), how failures degrade, and what input types are accepted. It also positions the tool in the broader workflow ('replaces 2-3 manual lookups'). This gives the agent enough context 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?

Schema coverage is 100% and both parameters are well-described. The description adds nuance by clarifying that 'value' accepts ticker, CIK, or name for company, and brand or generic for drug, with examples. It also frames the input as 'user-spoken NAME,' which helps the agent understand the flexible input. This enriches but does not drastically extend the schema.

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

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

The description clearly states the tool's purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It gives specific examples of user queries and supported entity types (company, drug), making it distinct from siblings like entity_profile or compare_entities.

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

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

The description gives explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also notes that using it 'replaces 2-3 manual lookups.' However, it does not explicitly mention when not to use or name specific alternative tools, so it falls short of the highest bar.

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 context beyond annotations: it details the probing process (ai_visibility_check), ranking, and output (score, confidence, signal density). No contradiction with idempotent/read-only annotations.

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

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

Two sentences plus a motivating example. Front-loaded with main purpose. 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 return type (ranked list with per-entity metrics). Parameters are well-documented in schema and description provides usage guidance, making it complete for its complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining entity ordering (first as subject) and the purpose of models and context parameters, though not exhaustive.

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 'Compare AI visibility across multiple entities side-by-side' with specific verb and resource. Differentiates from sibling tools like ai_visibility_check by explicitly mentioning it probes each entity and ranks them.

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 usage context: 'useful for competitive AI-marketing audits' and gives an example question. Notes first entity is treated as 'subject'. Could be improved by explicitly stating when not to use or listing alternatives.

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

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

Annotations already declare readOnly (safe, non-destructive), openWorld, and idempotent semantics. The description adds valuable behavioral context: partial failure degradation, bundlephobia's first-measurement timeout (5-30s), and the sources_failed field in the response. This goes well beyond the annotations.

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

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

The description is relatively long but well-structured: a front-loaded summary sentence followed by a detailed breakdown of return content, ecosystem scope, and failure behavior. Every sentence provides essential information, though slight tightening could improve conciseness.

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

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

No output schema exists, so the description must detail return values. It adequately describes the summary block fields, per-advisory details, links, and alternative versions. It also covers partial failure and timing. However, it does not explicitly list all fields in the summary block, leaving some ambiguity.

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

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

Schema coverage is 100%, so the schema already documents both parameters (package, version) and their defaults. The description does not add new parameter-level meaning beyond confirming that scoped packages are accepted, which is implied by the schema's type. No significant additional semantics are provided.

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

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

Description clearly states it performs a composite check for evaluating npm packages, specifying the two data sources (deps.dev and bundlephobia) and the returned metrics. It distinguishes from sibling tools by noting the NPM-only scope and directing other ecosystems to alternative tools.

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

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

Explicitly states when to use the tool (e.g., 'is X safe/popular/small' or 'what does adding lodash cost me') and provides a clear exclusion — non-NPM ecosystems fall under deps.dev:version directly. This gives agents clear decision boundaries.

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

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

The description adds significant behavioral context beyond the annotations, such as the embedding model (BGE-base-en), similarity metric (cosine), window size (500-char overlapping), character cap (200K chars) with truncation and flagging, and the fact that each passage includes a character offset for verification. 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 (three sentences) and front-loaded: the first sentence states the primary action, the second explains when to use and the pairing, and the third provides technical specifics. Every sentence adds unique 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 lacking an output schema, the description fully explains what is returned: top-N passages with character offsets and similarity scores. It also covers limits (200K chars, truncation flagging), the embedding model, and pairing with a sibling tool. This is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of each parameter: 'text' is the document to search (max 200K chars), 'query' is a natural-language query with examples, and 'limit' controls the number of passages. This enhances understanding beyond the schema descriptions.

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

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

The description clearly states the tool performs semantic search inside a fetched record, specifying the verb 'search within', the resource 'a fetched record', and the use case when the record is too big for the prompt. It also distinguishes from sibling tools like 'ask_pipeworx_grounded' by explaining how they pair.

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: 'Use when the record is too big to cram into the prompt' and explains that it saves context by returning only relevant passages. It also provides a pairing guideline with 'ask_pipeworx_grounded' for grounding over the results instead of the whole document.

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?

Goes well beyond annotations: details authentication, type-specific filters, delivery constraints. 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?

Dense but well-structured: purpose first, then prerequisites, then type breakdown, then delivery options. Every sentence adds value.

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

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

Covers all aspects: return value, auth, types, delimiter details, delivery channels, limitations, webhook signature verification. Complete despite no output schema.

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

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

Adds significant value beyond schema: explains item codes for sec_8k, examples for each type, delivery validation, webhook signing secret. 100% schema coverage but description enriches understanding.

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

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

Clear verb 'Create' and specific resource 'proactive monitoring subscription to a live-data event stream'. Returns subscription id, distinguishing it from list/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?

Explicit prerequisites (Pipeworx OAuth account), supported types with parameter examples, delivery channels, and limitations (SMS cap, webhook auto-disable). Helps agent decide when to use.

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

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

The description explains that the tool returns category-bucketed example questions with exact tool+argument shapes, drawn from a live catalog. It also details the return structure (company financials, drugs, etc.). Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive, and the description is fully consistent with these traits, adding valuable behavioral context beyond the annotations.

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

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

The description is a single, long sentence that packs a lot of information, including common queries, return format, and usage guidance. While every part is useful, it could be slightly more concise by removing some of the redundant examples at the beginning. However, it is well-structured and front-loaded with the most important information.

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

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

Given the complexity of an onboarding tool with no output schema, the description covers everything needed: purpose, usage scenario, return structure (category-bucketed examples with tool arguments), parameter behavior, and even mentions related meta-tools. It is complete and leaves no critical gaps.

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

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

The input schema already describes the `topic` parameter with possible values. The description adds the behavior: omitting the parameter yields a cross-category spread, while providing a topic focuses the results. Since schema coverage is high (100%), the description provides meaningful extra context about the effect of using or not using the 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?

The description clearly identifies the tool as the onboarding entry point for Pipeworx, listing natural language queries that trigger it and explicitly distinguishing it as the first tool to use when exploring capabilities. It specifies the verb 'returns category-bucketed example questions' and the resource 'the live catalog of thousands of tools', making the purpose unambiguous.

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

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

The description explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. It provides concrete examples of when to use the tool (e.g., 'what can I ask?', 'getting started') and implies it is not needed once the agent is familiar with the available tools. This is clear usage guidance with proper 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 significant behavioral context beyond annotations: it reveals that the action is a deactivation (not deletion) and that historical events remain via recent_alerts. This aligns with annotations (destructiveHint=false, idempotentHint=true) and adds value.

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

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

Two concise sentences that are front-loaded with the core action. Every sentence provides essential information without redundancy.

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

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

Given the simple one-parameter tool with good annotations and no output schema, the description is complete. It covers ownership, side effects (deactivation), and references a related tool (recent_alerts) for context.

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

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

The single parameter 'id' is fully described in the schema ('Subscription id (uuid) returned by subscribe.'). The description does not add further information about the parameter, so it meets the baseline for 100% schema coverage.

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

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

The description clearly states the action ('Cancel a subscription by id') and specifies the resource ('subscription'). It also distinguishes itself by noting ownership enforcement, which is unique among siblings like subscribe or 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?

The description explains when to use the tool (to cancel a subscription) and notes ownership constraints. However, it does not explicitly state when not to use it or compare with alternatives such as a hypothetical delete tool, though the sibling list provides context.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses critical behavioral nuances: the fallback routing logic, the specific verdict types, the meaning of 'could_not_verify' (which is not evidence for/against and must not be presented as such), and the distinction between 'unsupported' and 'could_not_verify'. This provides the agent with essential context for interpreting results safely and accurately, going far beyond what annotations alone offer.

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

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

The description is long but every sentence earns its place. It is front-loaded with examples, then covers usage, pipeline, output, and an important caller warning. The structure is logical and the content is dense without fluff. Given the tool's complexity, the length is justified and nothing feels redundant.

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

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

With no output schema, the description must carry the burden of explaining return values, and it does—listing the verdict types and the verification_error field. It also covers edge cases (e.g., 'could_not_verify' vs 'unsupported'), routing behavior, and high-level performance (replaces 4-6 calls). For a 2-parameter tool with no nested objects, this is exceptionally complete and leaves no critical gaps.

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

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

The schema descriptions for both 'claim' and 'tolerance_pct' are already detailed, but the tool description adds even more meaning. It explains that 'claim' is a natural-language factual claim and gives examples; it elaborates on 'tolerance_pct' by explaining how it overrides implied tolerance, giving a use case for hallucination detection, and stating the default. This enriches the parameter semantics beyond the schema, fully compensating for any ambiguity.

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

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

The description clearly states the tool's purpose: natural-language claim verification/fact-checking against authoritative sources. It uses specific verbs like 'verify', 'confirm or refute', and provides example phrases that trigger its use. It also distinguishes itself from siblings by describing its dual pipeline (SEC EDGAR for company-financial claims, grounded pipeline for everything else) and by noting it replaces 4-6 sequential calls, making its role 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 explicitly states when to use the tool: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also provides concrete example phrasing and clarifies the routing behavior for different claim types. It does not explicitly list exclusions, but the guidance is concrete and clearly positions this tool as the primary fact-checking resource among siblings.

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