Emsc

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by explaining the return format (per-model and combined view) and cost implications for Anthropic, though rate limits or error handling are not mentioned.

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 covering purpose, default behavior, optional parameters, return format, and use cases. Every sentence earns its place 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, the description clearly explains the return structure (per-model fields + combined view). It also addresses the optional Anthropic key and its billing impact, making the tool self-contained.

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

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

With 100% schema coverage, baseline is 3. The description significantly adds meaning: default model behavior, _apiKey usage context, and context parameter for disambiguation, plus return structure. This exceeds mere schema explanation.

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

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

The description clearly states the tool's function: probing LLMs for entity visibility and scoring 0-100 per model. It specifies the default model (Workers AI) and optional Anthropic, distinguishing 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?

Explicit use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) are provided. However, it does not explicitly exclude scenarios or compare to alternatives like deep_research, missing some guidance on 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 establish read-only, open-world, and idempotent behavior. The description adds valuable non-obvious behavior: it routes to one of 5,767 tools, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. This goes well beyond the annotation hints and gives the agent an accurate mental model of the call.

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

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

The description is longer than average but densely informative, with the most important routing guidance front-loaded. The examples are useful, though slightly redundant with the schema examples, and the closing alternatives paragraph is a bit convoluted in its phrasing.

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 of this complexity, the description covers the core question, the kinds of queries to send, example phrasing, the routing behavior, and the shape of the returned answer including citation URIs. No output schema exists, but the description adequately explains what the agent should expect in response.

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 six parameters are aliases for the same question string and the schema already documents them at 100% coverage. The description reinforces natural-language usage with examples, but it does not add meaning beyond what the input schema already communicates.

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 ask_pipeworx as a question-routing tool that selects among thousands of verified sources and returns structured answers with stable citation URIs. It is sharply differentiated from generic web search and from sibling tools like ask_pipeworx_grounded and deep_research by emphasizing authoritative structured data with citations.

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 'PREFER OVER WEB SEARCH' for a broad list of factual domains and gives concrete trigger phrases such as 'what is', 'look up', and 'get the latest'. It also names sibling alternatives—ask_pipeworx_grounded for grounded-only answers and deep_research for broad multi-part questions—so an agent knows when not to use this tool.

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

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

Beyond the read-only/idempotent annotations, the description discloses the live experimental behavior: candidate routing improvements are enabled whenever under test, no candidate is active right now, and it currently matches ask_pipeworx exactly. It also clarifies there is no fallback and that this is a full working router, not a wrapper.

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 compact and front-loaded with the beta relationship and current status before usage guidance. It is slightly redundant in saying the tool is identical, currently matches, and is a full working router, but each sentence still contributes useful context.

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

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

The description covers what the tool is, its current experimental state, how to invoke it, and references the same response shape as ask_pipeworx. While there is no output schema, the 'same response shape' reference is sufficient for an agent that can compare against the sibling, though it stops short of describing the actual response contents.

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 tool description does not add parameter-level semantics beyond saying the arguments are the same as ask_pipeworx. The input schema already handles aliases such as q, text, input, prompt, and question, so the description adds no meaningful parameter detail.

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

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

The description states that this is a 'Beta version of ask_pipeworx' and a 'universal router' covering the same 5,767 tools, and it distinguishes the tool by the 'candidate routing improvements' experimental edge. This gives a specific resource and behavior and clearly separates it from the stable ask_pipeworx sibling.

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

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

It explicitly instructs to 'Use it exactly like ask_pipeworx when you want the newest routing' and frames results as being compared against the stable router. This tells the agent when to select this beta tool and which sibling is the non-beta alternative.

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

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

The description discloses important behaviors beyond the annotations: it returns evidence, confidence, source, fetched_at, and structured refusal_reason values; it only uses information contained in the tool result; and it avoids fabrication by refusing when data is insufficient. These details exceed what readOnlyHint/openWorldHint/idempotentHint communicate.

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

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

The description is dense but every sentence earns its place: purpose, success/refusal behavior, use cases, and cost trade-off against the sibling tool are all covered without repetition. The most important distinction is front-loaded.

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

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

For a question-answering tool with no output schema, the description provides the full return shape, refusal categories, use-case constraints, and a comparison with the alternate tool. An agent has enough context to select and 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 description coverage is 100%, with the question parameter and all five aliases fully documented in the schema. The description itself does not add parameter-level meaning, which is acceptable because the schema already carries the burden.

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

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

The description clearly identifies this as a hallucination-resistant, grounded answer mode that extracts answers strictly from tool results and returns explicit refusals when evidence is insufficient. It also distinguishes itself from the sibling ask_pipeworx by naming the same routing but a stricter extraction behavior.

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

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

The description explicitly states when to use this tool—when an answer will be quoted, cited, or acted on and facts must not be invented—and when not to use it, saying to prefer ask_pipeworx for casual lookups because this costs an extra LLM call. This is strong, actionable 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?

The description goes far beyond the provided annotations by detailing low-confidence match handling, market closed/inactive status, wide-spread illiquidity warnings, resolution-rule risk parsing, parent event extraction, and news fallback behavior. All non-obvious behaviors are documented.

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 comprehensive but lengthy, containing multiple paragraphs with dense technical details. It could be more concise by grouping related concerns or abbreviating edge-case examples, but each part serves a purpose given the tool's complexity.

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

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

Despite having no output schema, the description thoroughly explains the response structure including market fields, analysis block with model probability, evidence keys, resolver contract with match confidence, parent event extraction, news fields with fallback logic, and safety checks. An agent has sufficient information to use the tool correctly.

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

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

The input schema describes all three parameters with default values. The description adds practical context like examples of market inputs, the effect of depth on evidence sources, and the size impact of include_raw. This adds value 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's purpose: researching a Polymarket bet by pulling Pipeworx data. It uses specific verbs and resources, and distinguishes itself from sibling tools like polymarket_edges and polymarket_arbitrage which focus on different aspects of betting.

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 recommends the tool for use cases like 'should I bet on X' and provides extensive examples of how it fans out to category-specific data packs. While it doesn't list alternative tools to use instead, the context of siblings makes it clear this is for single bet research.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds substantial behavioral context: it states the tool pulls latest 10-K financials from SEC EDGAR/XBRL with correct handling of off-calendar fiscal years, and for drugs pulls FAERS adverse-event counts, FDA approvals, and trial counts. It also explains results sorting by primary metric and return of citation URIs. No contradiction with annotations.

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

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

The description is well-structured, beginning with common trigger phrases, then providing usage guidance, then type-specific details, and finally output format. Every sentence adds value without redundancy. It is front-loaded with the core functionality.

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 (two entity types, multiple data sources, sorting, citations) and no output schema, the description covers key aspects: purpose, when to use, data sources, sorting behavior, and return format (paired data + citations). It mentions edge cases like off-calendar fiscal years. A slight gap is the exact structure of 'paired data', but overall it is sufficiently complete.

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

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

Schema coverage is 100% with both parameters described. The description enhances understanding by explaining what data each type retrieves (company yields financials, drug yields adverse events, etc.) and gives examples. This adds meaning beyond the schema's basic descriptions.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs. It uses specific trigger phrases like 'compare', 'rank', 'head to head' and distinguishes from siblings by emphasizing 'ALWAYS PREFER over sequential single-pack lookups' and 'Replaces 8–15 sequential lookups', which differentiates it from tools like entity_profile or ask_pipeworx.

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

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

The description provides explicit when-to-use guidance: when user asks for 'X vs Y', 'which is bigger', etc. It also instructs to prefer this over sequential single-pack lookups. However, it lacks explicit when-not-to-use scenarios (e.g., for a single entity or historical trends), though these are implied. Overall, clear and helpful.

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

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

Annotations already signal read-only, open-world, and idempotent behavior, but the description goes well beyond that by explaining the output packet contents (verbatim evidence, confidence, source, fetched_at, stable pipeworx:// citations), the explicit gaps[] for unanswered facets, and the 'never invented' guarantee. It also discloses depth-dependent behaviors like gap recovery, contradictions[], hop/citation_uri fields, semantic excerpting, and expected latency ranges—none of which are inferable from 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 account requirements, the fallback tool, and the core behavior, and its longer passages are information-dense and useful. However, the instruction 'For a single lookup use ask_pipeworx instead' is repeated multiple times nearly verbatim, creating redundancy that weakens conciseness.

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

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

With no output schema present, the description carries the full burden of explaining return values, and it does so thoroughly: findings packet fields, gaps[], contradictions[], citation_uri semantics, excerpting behavior, latency, and authentication/paid-tier prerequisites. An agent has enough context to decide when and how to invoke this tool correctly.

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

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

The input schema already covers both parameters with 100% description coverage, so the baseline is high. The description adds value by noting that depth 'thorough' requires a paid plan and by framing the question parameter as naturally broad/multi-part, but most parameter-level meaning is already present in 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 specifies a concrete verb and resource ('Grounded multi-source research across Pipeworx's 1506 STRUCTURED data sources') and explicitly contrasts itself with open-web search and the ask_pipeworx sibling. It also includes example queries and a direct 'For a single lookup use ask_pipeworx instead' instruction, making the tool's distinct role immediately clear.

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

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

The description provides explicit when-to-use guidance: best for broad/multi-part questions over structured data, while single lookups should use ask_pipeworx. It also gives an account-based fallback rule ('If you are not signed in, use ask_pipeworx instead') and example queries, so an agent can select this tool versus siblings without ambiguity.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds that it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly'. No contradictions.

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

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

The description is front-loaded with the core purpose, uses bullet points for examples, and every sentence adds value. It is appropriately sized and 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?

Given the absence of an output schema, the description explains what is returned (top-N tools with schemas). It lacks details on pagination or the exact structure of results, but for a discovery tool this is sufficient. Contextual completeness is high but not exhaustive.

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

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

Schema coverage is 100% so baseline is 3. The description adds context for the 'query' parameter (e.g., 'Natural language description of what you want to do') and mentions limit defaults. This extra information raises the score to 4.

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

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

The description clearly states 'Find tools by describing the data or task' with a specific verb and resource. It distinguishes itself from sibling tools as a discovery/browsing tool rather than a specific action 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 advises 'Call this FIRST when you have many tools available and want to see the option set', providing clear context for when to use. It lists many example domains but does not explicitly exclude scenarios, which keeps it from a 5.

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

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

Annotations already mark this as read-only, open-world, and idempotent. The description adds substantial behavior beyond those hints: fan-out across multiple sources, soft-failure of patents, expected empty fda_products for non-biologic companies, real 'no data' semantics via sources_used/sources_failed, and resolved:false behavior for private companies. It also details return sections and URI schemes.

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

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

The description is long but densely packed; every sentence and clause carries operational detail needed for a complex multi-source tool. It is front-loaded with trigger phrases and the central preference directive. Structure could be improved with bullet lists instead of one long semicolon-heavy paragraph, but there is no filler.

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

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

With no output schema, the description carries full responsibility for explaining return shape and edge cases. It covers all major output sections, data-source behavior, error/empty-result semantics, accepted input forms, and the private-company case. This is unusually complete for a tool with this much 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% and the schema itself already explains that 'company' and 'ticker' behave identically and that value can be a ticker, CIK, or company name. The description reinforces this with examples and edge-case notes, but adds little meaning beyond what the schema already provides; the baseline of 3 is appropriate.

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

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

The description opens with concrete trigger phrases and states the exact scope: 'full cross-source profile of a US public company in ONE parallel call.' It differentiates from the alternative of chaining single-pack SEC/XBRL/news lookups, making the tool's purpose and boundaries clear.

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

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

The description explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and offers representative user queries. It does not name sibling tools as alternatives or explicitly state when not to use this tool, but the preference directive and example queries provide strong 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 indicate destructiveHint=true and idempotentHint=true. The description adds context about why deletion is performed (stale context, sensitive data), which provides additional behavioral insight 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?

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

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

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

Given a simple single-parameter tool with no output schema, the description covers usage guidance and pairs with siblings. It could mention what happens if the key doesn't exist, but that's not a major gap. Annotations already cover behavior.

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

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

Schema coverage is 100% with a clear description for the key parameter. The description does not add extra details about key format or behavior when key is missing, but the baseline of 3 is appropriate since the schema already informs the agent well.

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

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

The description clearly states the verb 'Delete' and the resource 'a previously stored memory by key', and distinguishes itself from siblings by mentioning pairing with 'remember' and 'recall'.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier'. Also mentions pairing with siblings for 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 declare readOnlyHint, openWorldHint, idempotentHint, and no destruction. Beyond that, the description adds that it fetches the page, extracts metadata, and outputs the standard format. This provides useful behavioral context not covered by annotations.

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

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

The description is highly concise: two sentences plus a bulleted list of use cases. Every sentence adds value, and the purpose is front-loaded. No redundant or filler content.

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

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

With no output schema, the description explains the return value as a text blob ready to deploy. It covers the workflow and use cases. It could be improved by noting error handling (e.g., if the URL is unreachable) or limitations, but overall it is adequate.

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

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

Schema coverage is 100%, so the schema already documents both parameters (url and max_links). The description does not add extra meaning beyond stating it fetches the page and emits output, so baseline score of 3 is appropriate.

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

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

The description clearly states it generates a production-ready llms.txt file for any URL, extracting title/description/key links and emitting standard markdown. It distinguishes from sibling tools like scan_competitor_ai_presence by focusing on file generation for AI crawler indexing.

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

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

The description provides explicit use cases: getting a client's site indexed, drafting llms.txt for your own project, or auditing competitor visibility. However, it does not explicitly exclude scenarios or mention alternative tools within the sibling list.

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, so the description adds value by specifying default scope (active subscriptions) and the fields returned. This goes beyond the annotations without contradicting them.

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

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

The description is two concise sentences with no wasted words. The first sentence front-loads the action and output details, the second provides usage guidance.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the return fields and usage context. Annotations cover safety, making the description 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% and the description does not add any extra meaning beyond what the schema provides for the optional 'include_inactive' parameter. 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 the verb 'List' and the resource 'the caller's active subscriptions', and specifies the return fields (id, type, params, etc.). It distinguishes from sibling tools like 'subscribe' and 'unsubscribe' which have different purposes.

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

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

The description explicitly says 'Use this to review what you're monitoring before adding more or to find an id to cancel', providing clear context for when to use this tool and implicitly advising when not to (for adding or canceling, use 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?

Beyond the annotations (which only indicate readOnly=false), the description discloses important behavioral traits: filing without an account returns a claim_token for later follow-up, the tool is rate-limited to 5 per identifier per day, it's free and doesn't count against quota, and feedback is read daily with direct roadmap impact. This gives the agent realistic expectations about side effects, limits, and outcomes.

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

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

The description is dense but every sentence serves a purpose: purpose, usage triggers, exclusions, identifier guidance, message content rules, token flow, roadmap impact, and rate limits. It is front-loaded with the core purpose and immediately scopes applicability, making it easy for an agent to parse quickly.

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 (4 params, nested context object, no output schema), the description covers all needed behavioral context: what to report, what not to report, how to structure message, token follow-up mechanism, and constraints. The schema fills in parameter syntax while the description supplies the operational workflow, making the tool fully self-contained for an agent.

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

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

Schema coverage is 100% and each parameter already has a clear description, so the baseline is 3. The description adds cross-parameter insight by explaining that filing (message/type/context) returns a claim_token which can later be passed back to read resolution status, and it warns not to paste the end-user's prompt into message—valuable guidance not present in the schema.

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

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

The description opens with a specific verb+resource ('Tell the Pipeworx team something is broken, missing, or needs to exist') and immediately enumerates concrete use cases: wrong/stale data (bug), missing catalog tool (feature/data_gap), and praise. It clearly distinguishes itself from sibling research/query tools by scoping feedback exclusively to Pipeworx-served tools, so the agent knows exactly what this tool does and why it differs.

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 triggers tied to feedback types and an explicit when-not-to-use exclusion: if a tool came from a different MCP server, file it there instead. It also advises identifying Pipeworx tools by the connection's listed names and clarifies how to follow up on a filed report via claim_token, providing complete selection and invocation guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds important context: data is 'derived from CF analytics-engine', 'no PII', and 'cached 5min-1h depending on window'. 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 (three paragraphs) and well-structured: first sentence states the purpose, next lists use cases, final paragraph adds transparency details. 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?

With one optional parameter and no output schema, the description fully covers what the tool returns (top tools, top packs, call volume), its caching behavior, and data origin. No gaps remain for an agent to use 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% for the single parameter 'window'. The description reinforces its meaning and adds nuance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.'

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' over a configurable window. It explicitly distinguishes itself from siblings like 'discover_tools' by focusing on trending usage data rather than tool discovery.

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 three specific use cases (discovering hot data sources, confirming canonical tools, checking alignment with agent needs). However, it doesn't explicitly state when not to use this tool or name direct alternatives among 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds extensive behavioral context: details of scanning logic (monotonicity, partition checks), filtering mechanisms (semantic anchor, partition filter, fill check), and rules for interpreting results. No contradiction with annotations.

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

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

The description is well-structured with clear sections (modes, semantic anchor, partition filter, response, fill check). It is front-loaded with the core purpose. While it is somewhat lengthy, every sentence adds necessary detail for correct tool usage. A minor trim 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?

Without an output schema, the description fully explains the return structure (opportunities array, partition check fields, fill check). It also mentions related tool 'polymarket_fill_risk' for custom sizing. Given the tool's complexity and no output schema, the description is complete and actionable.

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

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

Schema coverage is 100% with descriptions for both 'event' and 'topic'. The description adds significant meaning: examples of valid inputs (slugs, URLs, seed questions), behavior differences between modes, and cross-event catching patterns. This goes beyond schema documentation.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between three modes: no-args trending scan, event-specific single-event scan, and topic cross-event scan, each with clear behavior.

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 explains when to use each mode (e.g., 'pass `event` for the strongest per-event partition_check', 'pass a seed question for cross-event scanning'). It also provides guidance on not trading when realizable_edge_pp ≤ 0. However, it does not explicitly compare to sibling tools like polymarket_edges or polymarket_fill_risk, though it mentions the latter for custom sizing.

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. The description goes beyond by detailing caching behavior (cached 1h at KV level), the diagnostic output (_diagnostics) for understanding why segments are empty, and the algorithmic methodology (including placeholder-slug filters and Kelly calculations). No contradictions with annotations.

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

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

The description is very long and includes extensive technical detail (e.g., exact algorithm parameters, placeholder-slug lists, diagnostic funnel counters) that could be condensed or moved to an optional documentation. However, it is well-structured with clear sections for purpose, segments, knobs, and response, and front-loads the core use case.

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

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

Despite no output schema, the description fully explains the response structure (by_segment, diagnostic fields, Fed bets note) and covers edge calculation, knobs, filtering logic, caching, and limitations. All 9 parameters are explained, and the tool's complexity is addressed comprehensively.

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

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

All 9 parameters are fully described in the input schema (100% coverage). The description adds functional context by explaining the purpose of key knobs (e.g., 'min_liquidity / max_spread_pp drop opportunities where edge isn't realizable') and how they interact with tradeability, which enhances understanding beyond the schema alone.

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

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

The description clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price' and explicitly identifies the target use case as 'what should I bet on today'. It differentiates from sibling tools by detailing the specific algorithmic segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) and the response structure, making the purpose highly specific and actionable.

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

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

The description provides implicit context ('Built for...discover opportunities') but lacks explicit guidance on when to use this tool versus its siblings (e.g., polymarket_arbitrage, polymarket_edge_tracker). No direct alternatives or exclusion criteria are mentioned, leaving an agent to infer usage from the detailed output structure.

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

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

Annotations declare idempotent and read-only; description aligns and adds specifics: uses daily closes of edge_pp_net (not intraday), bounded by 60-day snapshot TTL, snapshots written on cache-miss. 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?

Well-organized with RESPONSE and LIMITS sections, but somewhat verbose. Could tighten wording while retaining key details.

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

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

No output schema, yet description thoroughly explains all three return fields (tracked, expired, snapshot_dates) with sufficient detail for an agent to understand the response.

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 already fully describes both parameters (days, window) with defaults and clamps. Description repeats these details without adding new semantic meaning 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?

Description clearly states it provides edge persistence and decay telemetry from daily snapshots, answering 'how long has this edge existed and is it shrinking?'. This distinguishes it from sibling tools like polymarket_edges (snapshot source) and other Polymarket 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?

Describes context: fresh vs aged edges are different trades. Implies usage for historical analysis, but does not explicitly exclude scenarios or mention 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 declare readOnlyHint, openWorldHint, idempotentHint, no destructive hint. Description adds extensive behavioral context: read-only check of order book, detailed output fields for both modes, and critical warnings about partial basket fills converting arb to unhedged directional positions. No contradiction with annotations.

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

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

Well-structured with front-loaded summary, then requirements, mode details, output fields, and usage guidance. Slightly verbose but every sentence earns its place given the complexity of the tool. Could be compressed slightly but remains clear.

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

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

No output schema, so description fully compensates by listing all returned fields for both modes (top_of_book, vwap_fill_price, slippage, capture_ratio, profit_usd, per-leg detail, thin_legs, etc.). Also explains when to use and risks, making it complete for a 4-parameter tool with rich behavior.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema: explains the difference between single-market and basket modes for the side parameter, defines size_usd contextually (max spend vs target proceeds, settlement notional), and clarifies default behaviors.

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

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

The description opens with a clear, specific verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes and is distinct 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.' Provides exclusion criteria (thin books, partial fills) and warns about 'the dominant loss mode in real arb-bot P&L.'

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 substantial behavior beyond the readOnly/openWorld/idempotent annotations: it discloses the token-overlap matching method, the requirement to read compatibility_warning/compatibility_codes even when pairs exist, the precise meaning of temporal_alignment null, the gross-vs-net fee limitation, and ignored 'unknown' legs. No statement contradicts the annotations.

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

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

The first sentence fronts the core purpose and the rest is organized under clear headings (TWO MODES, RESPONSE, SAFETY FIELDS) with deliberate repetition only where safety matters. It is long, but most lines carry unique operational information that no output schema is there to provide.

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 3-parameter tool with no output schema, this is unusually complete: it documents modes, response structure, safety codes, per-leg flags, skipped comparison counters, fees, and the false-positive caveat. An agent can invoke either mode and interpret the return correctly without external docs.

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 all three parameters, so baseline is 3; the description adds real value by defining the 10 topic values, clarifying that both modes run the same matcher, and explaining that explicit ticker/slug override the topic-mapped side. It does not add new parameter syntax, but it gives decision-relevant semantics 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?

Opens with a specific verb phrase ('Cross-venue spread between Kalshi and Polymarket...') that names the exact resource and analytic task, and immediately sets it apart from single-venue Polymarket sibling tools by fixing the comparison to the 'same resolving question.' The two modes are also stated up front, so an agent can tell what the tool operates on without opening the schema.

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 two-mode explanation gives concrete decision criteria: use topic for the 10 listed shortcuts, use explicit kalshi_event_ticker + polymarket_event_slug for custom pairings, and the caution that pre-mapped topics often return compatibility warnings sets expectations. It does not explicitly name what to use instead when a different kind of cross-venue analysis is wanted, so it stops short of a full when/when-not guide.

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 idempotentHint=true. The description adds context about scoping to an identifier and the ability to list all keys, which is beyond what annotations provide. No contradiction.

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

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

The description is two sentences, front-loaded with the primary action, and every sentence adds value. No wasted words.

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

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

For a simple retrieval tool with full schema coverage and clear annotations, the description covers scope, behavior, and pairing with siblings. No gaps.

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

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

Schema coverage is 100% with a clear description for the optional 'key' parameter. The description adds value by specifying that omitting the key lists all saved keys, which is not in 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 retrieves a value saved via 'remember' or lists all keys when omitted. It distinguishes itself from sibling tools 'remember' and 'forget' by focusing on retrieval and listing.

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

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

The description explains when to use (look up stored context) and implies when not (not for fresh data). It mentions pairing with 'remember' and 'forget' but does not explicitly exclude other scenarios.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extra behavioral context: that mark_read:true flags events as read affecting subsequent calls, that the feed is persisted, and that the same feed is available via GET. No contradictions.

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

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

The description is very concise – three sentences that front-load the main purpose and key details. Every sentence earns its place: purpose, return fields and filtering, mark_read effect, and alternative access. No unnecessary words.

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

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

Despite no output schema, the description specifies that each alert carries source, citation_uri, and raw payload – adequate for a read-retrieval tool. It covers polling suitability, alternative GET access, and optional parameters. With annotations covering safety and idempotency, the description is fully complete for tool invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining that 'type' filters subscription type, 'since' uses ISO timestamp, 'mark_read' flags events read in the same call, and implies 'unread_only' behavior. It also mentions the return payload structure, adding 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 starts with 'Pull fired events from your subscription feed' – a specific verb+resource that clearly defines the tool's purpose. It mentions the return content (source, citation_uri, payload) and filtering options, distinguishing it from siblings like 'list_subscriptions' which manage subscriptions themselves, not alerts.

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 states 'Polls work fine', implying polling is appropriate, and mentions an alternative access method (GET registry.pipeworx.io/alerts.json) for scripts/dashboards. It gives clear context for when to use but doesn't explicitly list when not to use or compare with specific sibling tools for alerts.

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

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

Beyond annotations (readOnlyHint, idempotentHint), description details fan-out behavior, fallback logic (GDELT→GNews), API sunset issues for patents, and return structure (changes[] grouped by source, total_changes, citation URIs).

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

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

Single paragraph, dense but efficient. All sentences add value. Slightly lacks visual structure but remains clear.

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

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

Given no output schema, description covers return structure. Addresses multiple sources, fallbacks, and limitations (PatentsView sunset). 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?

Adds meaning beyond schema: explains type enum (only 'company'), value examples (ticker or CIK), since format (ISO or relative) with recommended default '30d'. Schema coverage is 100%.

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

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

Description clearly states it provides a change feed for a company over a time window, listing multiple data sources (SEC EDGAR, GDELT/GNews, USPTO). Explicitly distinguishes itself from sibling entity_profile.

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

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

Provides concrete query examples and explicitly tells when to use entity_profile instead ('Use entity_profile instead when you want the static 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. Description adds useful details: times in UTC ISO 8601, depth in km, and an example call. No contradiction with annotations. Does not mention rate limits or data freshness, but sufficient for a read-only tool.

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 waste. Front-loaded with action and key details. Every sentence adds value: source, parameters, example, geographic scope, output format.

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

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

Given no output schema, description explains output format (UTC ISO 8601, depth in km). Covers parameter defaults (days=7, minmag=4, limit=50 from schema), geographic coverage, and example. Sufficient for agent to understand and use tool correctly.

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

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

All three parameters are described in the input schema with default values (schema coverage 100%). Description restates 'last N days above a minimum magnitude' and provides an example, but does not add significant meaning beyond schema. Baseline 3 is appropriate.

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

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

Clearly states it gets recent earthquakes from EMSC with parameters days and minmag, newest first. Distinguishes from sibling 'search_earthquakes' by being a convenience wrapper for recent events. Specifies verb 'get', resource 'earthquakes from EMSC', and scope 'last N days above minimum magnitude'.

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?

Indicates when to use (get recent earthquakes) and provides context on geographic coverage (global but strong in Europe/Mediterranean). However, does not explicitly state when not to use or how it differs from sibling 'search_earthquakes'. Lacks direct alternative 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?

Adds context beyond annotations: persistence details (authenticated vs anonymous, 24-hour retention), scoping by identifier, and mutation 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?

Three sentences: core action, usage guidance, and supplementary details. Front-loaded and concise with no wasted words.

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

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

For a simple key-value store with 2 mandatory params and no output schema, the description covers purpose, usage, persistence, and relation to sibling tools. No gaps.

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

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

Schema coverage is 100%, baseline is 3. Description does not add further parameter semantics beyond what the schema provides (key and value are well-defined in 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 the tool saves data for reuse. Mentions specific resources (key-value pair, memory) and provides examples like resolved ticker, address. Distinguishes from siblings recall and forget.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and lists typical scenarios. Also pairs with recall and forget, giving clear context for when to use these 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 adds substantial behavioral context beyond the annotations: graceful degradation when GLEIF/OpenFIGI are unavailable, the ambiguous-match behavior returning figi_candidates without asserting a single result, explicit unresolved identifiers, and the ISIN-to-LEI resolution path. This is exactly the kind of non-obvious behavior an agent needs to predict outcomes correctly.

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 quite long and dense, with several deeply nested parentheticals, so it is not maximally scannable. However, it is front-loaded with example queries and the primary instruction, and nearly every clause delivers useful information about behavior or supported inputs rather than padding.

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

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

Given there is no output schema, the description does a strong job of covering the important return behavior: what identifiers are returned, how ambiguity is handled, how unresolved items are represented, and how enrichment failures degrade. For an agent deciding whether and how to call this tool, the key outcomes and edge cases are covered.

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?

Even though schema description coverage is 100%, the description enriches parameter meaning significantly. It explains which input forms are accepted for company and drug types, and it provides a crucial formatting warning: pass the entity name only, never the full noun phrase, because trailing security-class words break FIGI matching. This goes well beyond the schema's parameter descriptions.

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

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

The description clearly states the verb and resource: it resolves a user-spoken name to canonical/official identifiers, and opens with concrete query examples that make the purpose immediately recognizable. It does not explicitly differentiate from sibling tools like entity_profile or compare_entities, but the scope (name-to-ID resolution) is distinct enough to understand its role.

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

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

The description gives an explicit when-to-use rule: 'Use FIRST whenever you have a name but need an ID.' It also explains that the tool replaces multiple manual lookups, which helps the agent decide to invoke it. It does not spell out when not to use it or name alternative sibling tools, so it falls just short of a 5.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds that it probes each entity using 'ai_visibility_check', ranks by score, and surfaces most/least recognized, which are useful behavioral details 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 concise (3-4 sentences), front-loaded with the main purpose, and every sentence adds value. No unnecessary words.

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

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

Given the tool's complexity (comparing multiple entities) and the absence of an output schema, the description provides sufficient information about the ranked list (score, confidence, signal density). It covers the essential aspects for correct usage.

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

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

Schema coverage is 100%, but the description adds meaning: it explains that the first entity in the array is treated as the 'subject', that models default to 'workers-ai' if omitted, and that context is shared across probes. This significantly aids 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?

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using the verb 'compare' and specifying the resource (AI visibility). It distinguishes itself from the sibling 'ai_visibility_check' by focusing on multiple entities and ranking.

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

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

The description provides clear context for competitive AI-marketing audits and implies use when comparing multiple entities. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond annotations: partial failures (bundlephobia can take 5-30s, sources_failed will list if timeout), NPM-only scope, and graceful degradation behavior.

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

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

The description is well-structured with the composite purpose front-loaded. While slightly long, every sentence adds meaningful information. Could be slightly more concise but still effective.

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

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

Given no output schema, the description thoroughly explains the return value structure (summary block, advisories, links, alternatives). It covers edge cases like partial failures and ecosystem limitations, making it 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?

Input schema provides 100% coverage with clear descriptions for both parameters. The description adds value by noting that default version is latest and that scoped packages are accepted, which goes beyond schema descriptions.

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

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

The description clearly states it is a composite check for adding an npm package, covering license, advisories, version history, and bundle size. It specifies the return summary block, which effectively distinguishes it from sibling tools that serve other purposes.

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: 'whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'. Also notes NPM ecosystem only and suggests alternatives for other ecosystems via deps.dev.

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 false, so safety profile is clear. The description adds valuable context about the data source (EMSC, FDSN API), regional strengths, and parameter interactions (bounding box vs circle), but does not contradict 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: purpose in first sentence, then clear bullet-like enumeration of filter types, followed by examples. Every sentence adds value without redundancy.

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

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

Given 14 parameters, no required ones, and no output schema, the description provides sufficient context for correct invocation: it explains the two location search modes, time range format, magnitude limits, ordering options, and provides examples. It also mentions the API source and regional coverage.

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

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

Schema coverage is 100%, and the description adds meaningful context beyond parameter names and types: it explains the coordinate system (Flynn-Engdahl region), units (depth in km, radius in degrees), and provides two concrete usage examples showing different parameter combinations.

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 searches seismic events from EMSC via FDSN-standard API, with global coverage but special emphasis on Europe/Mediterranean. It distinguishes itself from sibling 'recent_earthquakes' by mentioning complements USGS and providing extensive filtering options.

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 (for historical or filtered earthquake data) and includes explicit examples. However, it does not explicitly contrast with sibling 'recent_earthquakes' or provide 'when not to use' guidance.

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

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

Annotations already declare read-only, idempotent, safe behavior. The description adds significant context: uses BGE-base-en embeddings, cosine similarity, 500-char windows, 200K char cap with truncation flag. It also discloses return format (offsets, scores). 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?

Every sentence adds value: purpose, usage, pairing, technical details. Front-loaded with main action. No redundant or irrelevant information. Efficient and clear.

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

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

Though no output schema, the description explicitly states return format (top-N passages with offsets and scores). Covers key aspects: embedding model, window size, character limit, truncation behavior, and usage pairing. 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 coverage is 100% with detailed descriptions for all 3 parameters. The description adds usage context (e.g., 'text you already pulled', example queries) but does not provide substantial new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it performs semantic search inside a provided text, using specific examples like SEC 10-K and articles. It distinguishes from sibling tools by explicitly mentioning pairing with ask_pipeworx_grounded, 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?

Explicitly describes when to use: when the record is too large for the prompt. Provides clear instructions (pass text and query) and explains outputs (passages with offsets). Also notes it pairs with ask_pipeworx_grounded for grounding, giving comprehensive 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. Description adds behavioral details: requires authentication, persists subscriptions, returns a new id, sms rate limit (10/day), webhook auto-disabled after 10 failures. 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?

Dense with information but slightly long. Could be more concise by separating type and delivery details, but the structure is logical and sentences are efficient.

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

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

No output schema, but description explicitly states it returns a subscription id. Covers authentication, supported types, delivery channels, rate limits, and error handling (auto-disable). Complete for a creation 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%. Description amplifies each parameter with concrete examples and constraints (e.g., phone must be verified, webhook signing secret returned once). Adds meaning 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 creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. It distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation.

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

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

Provides explicit prerequisites (Pipeworx OAuth account), supported subscription types with examples, and delivery channel options with limits. It does not explicitly contrast with alternatives like list_subscriptions or alert polling, but covers when to use this tool well.

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 document read-only, idempotent, and non-destructive behavior. The description adds return structure (category-bucketed examples) and invocation details (call with no args or topic), which are beyond what annotations provide.

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

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

The description is comprehensive but slightly verbose, including multiple example questions. However, it is well-organized and front-loaded with the key use case and output type.

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

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

For a tool with no output schema and one optional parameter, the description fully covers what it does, how to use it, and what to expect. It explains both argument modes and the nature of the results, leaving no ambiguity.

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

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

Schema coverage is 100% with a single parameter. The description adds concrete examples of valid topic values and clarifies that omitting the topic yields a full spread, enhancing understanding beyond the schema's minimal description.

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

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

The description clearly identifies the tool as the onboarding entry point, specifying it returns category-bucketed example questions with tool and argument shapes. It distinguishes from siblings by targeting the initial 'what can I ask?' scenario.

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 this FIRST' when unaware of capabilities or to learn meta-tools. Provides examples of queries that trigger it, but does not explicitly list when to avoid this tool in favor of specific 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 provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context: ownership is enforced, the row is deactivated not deleted, and historical events remain accessible via recent_alerts. This clarifies the tool's actual behavior beyond the annotations, though it does not expand on potential side effects hinted by openWorldHint.

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 three sentences, each serving a purpose: stating the action, specifying ownership constraints, and clarifying the result. It is front-loaded with the core purpose and avoids unnecessary details.

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

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

Given the tool's simplicity (single parameter, no output schema), the description covers the action, side effects, ownership rules, and relation to recent_alerts. It could optionally mention the return value or confirmation behavior, but the current content is largely complete for effective usage.

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

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

The schema provides 100% coverage with a detailed description for the required 'id' parameter. The tool description only mentions 'by id' which adds no new meaning. Baseline score of 3 is appropriate as the schema already handles parameter semantics adequately.

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

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

The description clearly states the verb 'Cancel' and the resource 'subscription by id', providing a specific and unambiguous purpose. It also hints at differentiation from sibling tools like 'subscribe' (creation) and 'recent_alerts' (historical events), making the tool's role distinct.

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

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

The description mentions ownership enforcement ('you can only cancel your own subscriptions') and the non-destructive nature (deactivation not deletion), directing users to 'recent_alerts' for history. While it gives clear context for when to use the tool, it lacks explicit exclusions or alternatives beyond the sibling reference.

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, but the description adds crucial behavioral context: it explains that 'could_not_verify' means the check did not happen and must not be used as evidence, and that 'unsupported' means no source was found. 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 front-loaded with trigger phrases, then states usage, return values, and critical caveats. Every sentence adds unique value, such as the warning about could_not_verify and the explanation of the fast path vs grounded pipeline. It is long but efficiently structured with no filler.

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

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

With no output schema, the description compensates fully by detailing the verdict values, the included actual value with citation, reasoning, and error semantics. It also covers both processing paths and the tool's role in replacing multiple sequential calls, giving callers a complete picture.

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

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

The input schema already provides 100% coverage for both parameters with detailed descriptions. The description adds helpful examples for the 'claim' parameter and notes tolerance_pct overrides implied tolerance with suggested ranges for hallucination detection, but these are supplementary rather than necessary for understanding the parameters.

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

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

The description starts with explicit trigger phrases ('Is it true that…', 'fact check', 'verify the claim that…') and defines the tool as 'natural-language claim verification against authoritative sources.' It clearly distinguishes its scope from siblings by focusing on factual claim verification and mentions it replaces 4–6 sequential calls, making the purpose unmistakable.

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

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

The description explicitly states when to use it: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also provides valuable routing guidance for company-financial claims vs other factual claims. However, it does not explicitly mention when not to use it or name alternative tools, so it misses the top score.

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