The Graph

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds context: default model is free, BYO key for Anthropic, response structure includes score/confidence/signals/raw_response. No contradiction and adds value beyond annotations.

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

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

Single paragraph with clear front-loading: main action, default, options, return structure, use cases. Every sentence is informative with no redundancy.

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

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

Despite no output schema, description adequately describes return format (per-model score, confidence, signals, raw_response + combined view). Covers purpose, usage, parameters, and behavioral traits for a moderately complex tool with 4 parameters and no nested objects.

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. Description adds meaning: default model is Workers AI Llama-3.3-70b (free), _apiKey is for Anthropic only, context helps disambiguate. This enriches understanding beyond schema.

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

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

Description uses a specific verb 'probe' and resource 'LLMs', with clear output 'score visibility (0-100) per model'. It distinguishes from siblings like compare_entities or scan_competitor_ai_presence by detailing the exact probing mechanism and models used.

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

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

Explicitly states use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to use optional parameters (models, _apiKey). However, lacks explicit exclusions or comparison to sibling tools for 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?

Beyond the annotations (read-only, open-world, idempotent), the description reveals the routing behavior across 5,798 tools / 1,517 sources, automatic argument filling, and the stable pipeworx:// citation URI return format. This meaningfully tells an agent what happens when the tool is invoked, and nothing 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 content is front-loaded with the most important usage rule and covers purpose, alternatives, examples, and return behavior in compact prose. It is slightly redundant ('even if web search could also answer it' appears twice), preventing a perfect 5.

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 routing tool with one free-text question parameter and no output schema, the description is complete: it explains what data domains are covered, how the question is handled, what the response looks like (structured answer with citations), and how to choose between this and adjacent tools.

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

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

Schema coverage is 100% and the schema already documents the single question parameter and its aliases, so the baseline is 3. The description earns a 4 by providing domain-rich example questions and clarifying what kinds of natural-language queries are acceptable, which supplements but does not replace 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 directive ('PREFER OVER WEB SEARCH') and an explicit resource/action pairing: answer factual questions about current or historical data by routing to verified sources and returning cited structured answers. It clearly distinguishes the tool from web search and sibling research tools by naming what it routes to and what it returns.

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 states exactly when to prefer this tool ('Use whenever the user asks ...'), gives concrete example questions, and names an alternative (deep_research) for broad multi-part queries while explaining ask_pipeworx's coverage for breaking news. This is explicit when-to-use and when-not-to-use guidance.

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

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

The description adds substantial behavioral context beyond annotations: it discloses live candidate routing, the absence of an active candidate as of 2026-07-26, exact current parity with ask_pipeworx, and that it is a full working router rather than a fallback. This is transparent about its experimental nature.

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 essential identity and immediately clarifies beta status. Every sentence adds distinct value: identity, current state, usage, and experimental nature. No filler or redundancy.

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

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

Given the lack of an output schema, the description compensates by explicitly stating that the response shape is identical to ask_pipeworx. It covers current behavior, usage instructions, and the experimental caveat, so an agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, with the schema already documenting the question parameter and its aliases. The description mentions 'same arguments' but does not need to repeat parameter details; therefore 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 states a specific verb and resource: it is a beta version of ask_pipeworx, an identical universal router with the same 5,798 tools, arguments, and response shape. It clearly distinguishes itself from the stable ask_pipeworx by labeling itself the experimental edge.

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 it exactly like ask_pipeworx when you want the newest routing.' It also explains the current state (no candidate active) and that results are compared against the stable router, giving clear context for when this variant is appropriate.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses key behavioral traits: refusal mechanics with specific refusal_reason values, the requirement that answers use only tool-result content, source/evidence/confidence in the return shape, and the extra LLM call cost. It also describes both success and refusal return structures despite no output schema.

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

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

The description is dense but every sentence earns its place: purpose, routing behavior, return/refusal shape, use cases, cost comparison, and alternative preference. It is front-loaded with the core differentiation and keeps the most important decision-relevant information early.

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

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

Given no output schema, the description fully compensates by specifying the success return fields, the refusal variants, the grounded extraction rule, and the high-stakes usage conditions. The tool is complex, but the description provides everything an agent needs 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 schema already documenting the question parameter and its aliases clearly. The tool description adds no additional parameter semantics, but it does not need to because the schema fully carries the burden. Baseline 3 is appropriate.

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

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

The description uses a specific verb-resource-mode combination: 'Hallucination-resistant answer mode for high-stakes reads' and explicitly distinguishes itself from ask_pipeworx by stating it extracts answers only from tool results. It clearly defines what the tool does and how it diverges from its sibling, leaving no ambiguity about 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 explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and names alternatives with 'prefer ask_pipeworx for casual lookups.' It also mentions the cost tradeoff, which helps an agent decide between this and the sibling.

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

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

Annotations indicate read-only, idempotent, open-world. Description adds extensive behavioral details: fan-out examples, resolver contract (market_match_confidence, alternatives, suggestions), parent event extraction, news fallback fields, safety short-circuits, closed market handling, cancellation rules. Far exceeds annotation scope.

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 extremely verbose and presented as a single large paragraph. While it includes many details, it lacks clear sectioning or bullet points. It could be restructured with headings for readability without losing 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?

Given the tool's complexity (multiple fan-outs, resolver logic, cancellation rules, safety mechanisms), the description covers all key aspects. No output schema exists, but response shapes are explained. It is thoroughly complete for effective agent use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how parameters affect behavior (e.g., depth quick vs thorough, include_raw for full payloads) and example inputs, going 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 the tool researches Polymarket bets by pulling Pipeworx data in one call. It specifies input types (slug, URL, question text) and distinguishes from siblings like ask_pipeworx by focusing on betting edge analysis.

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

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

Provides explicit use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. While siblings are not named, the context of Polymarket betting is distinct. Implicit guidance on when not to trust (low confidence, closed markets) is included.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds significant context: it makes one parallel call, handles off-calendar fiscal years, sorts results by primary metric, and returns paired data with citation URIs. This enriches behavioral understanding beyond annotations.

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

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

The description is slightly long but every sentence adds value. Key information is front-loaded (use cases, preference instruction). Could be trimmed very slightly, but overall it is efficient 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 tool's complexity (two types, specific data sources, sorting, efficiency), and with annotations and schema covering basics, the description fully explains behavior, output, and when to use. No gaps remain for an agent to function correctly.

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

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

Schema coverage is 100% and the description adds meaning by explaining what each enum value does ('company' pulls 10-K data, 'drug' pulls FAERS counts) and what formats the values parameter accepts (tickers/CIKs for companies, names for drugs). This is highly useful.

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 entities (companies or drugs). It provides specific verb phrases like 'Compare X and Y' and explicitly distinguishes itself from sequential lookups, which differentiates it from siblings like 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?

Explicit use cases are given ('Compare X and Y', 'X vs Y', etc.) and it advises preferring this tool over sequential single-pack lookups. It details what data is fetched for each type, helping the agent decide when to use the tool based on entity type.

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

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

Even though annotations already mark the tool read-only and non-destructive, the description adds substantial behavioral context: auth requirements, paid tier for thorough depth, parallel facet decomposition, gapped output, no fabrication, contradiction scanning, semantic excerpting, latency expectations, and fetchable citation URIs. Nothing contradicts the annotations.

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

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

The description is long but densely packed with operational detail and starts with the most important gate: account required. A few ideas are repeated from the schema and the flow could be more structured, but each sentence generally earns its place 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?

Given there is no output schema, the description does a strong job explaining return values: findings with verbatim evidence, confidence, source, fetched_at, citation URI, gaps array, and contradictions array. It also covers timing, depth tiers, auth, and when to choose another tool, leaving no critical calling context missing.

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

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

Schema coverage is 100%, with the depth parameter already fully describing quick/standard/thorough behaviors, hop counts, paid status, and contradiction scans. The description mostly restates what the schema already provides, so it adds limited new parameter-level meaning.

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 a specific verb and resource: grounded multi-source research over Pipeworx's 1517 structured data sources, returning a findings packet. It also explicitly distinguishes itself from open-web search and from ask_pipeworx for single lookups, so an agent can tell what this tool uniquely does.

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

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

It gives explicit when-to-use guidance: best for broad/multi-part questions over structured data, and for single lookups it says 'use ask_pipeworx instead.' It also names a hard precondition: account required, with an explicit fallback for unsigned-in users.

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

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

Annotations indicate read-only, non-destructive, idempotent behavior. Description adds valuable context: results include full schemas with examples and are ready to call directly, no second lookup needed. 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?

Three to four sentences, front-loaded with purpose, includes concrete examples and domains, no wasted words.

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

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

Given no output schema, description explains what is returned (top-N tools with schemas and examples) and the tool's role as first step. Could mention it indexes available tools, but sufficient.

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 provides examples and explains the 'query' parameter accepts natural language, but doesn't add significant detail beyond schema for individual 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 clearly states the verb 'Find tools' and specifies the resources (SEC filings, FDA drugs, etc.) and the task ('browse, search, look up'). It distinguishes itself from siblings by being the meta-discovery tool, explicitly saying 'Call this FIRST'.

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

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

Provides explicit guidance on when to use ('when you need to browse, search, look up, or discover what tools exist') and a strong recommendation ('Call this FIRST'). Does not explicitly state when not to use, but context is clear.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar for the description is to add context beyond those flags — and it does extensively: fan-out across nine sources, soft-fail behavior for the USPTO PatentsView sunset, the nuanced 'a company with only small-molecule drugs shows none — expected, not a failure' clarification, sources_used/sources_failed semantics ('an empty section is a real no data'), and resolved:false with notes for private companies. 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 front is strong — the query-pattern opener earns its place — and nearly every sentence carries real information. But the body is a dense single wall of text with no line breaks or visual structure, mixing return payload details, expected-empty semantics, and edge cases into one long flow. It is comprehensive but not concise; the content is valuable enough to avoid a 2, yet the lack of formatting hurts scannability for an agent.

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 that fans out to over nine external sources with no output schema to lean on, the description is exceptionally complete. It documents every section of the return payload (cik, recent_filings with URIs, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), covers expected-empty and soft-fail edge cases, and clarifies sources_used/sources_failed. An agent has everything needed to call it correctly and interpret results, with no structured output schema to compensate for 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% — both `type` and `value` are fully described in the schema, including the interchangeable behavior of 'company'/'ticker' and the three accepted value shapes. The description largely restates what the schema already says (EDGAR name resolution appears in both) and adds only minor flavor ('person/place coming soon'). With high schema coverage, baseline 3 is correct; the description adds no meaningful parameter information beyond the schema.

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

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

The description opens with concrete user phrasings ("Tell me about X" / "research Acme") followed by a crisp statement: 'full cross-source profile of a US public company in ONE parallel call.' Verb, resource, and scope are all explicit, and the 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' line differentiates it from the many sibling tools that would otherwise seem overlapping (deep_research, compare_entities, resolve_entity).

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 'ALWAYS PREFER over chaining single-pack... when the user asks for a holistic view' instruction is an explicit routing rule that tells the agent exactly when to invoke this tool. It also states the exclusion condition (private companies return resolved:false). However, it never names sibling alternatives like compare_entities or resolve_entity and says when to use those instead, so the when-not guidance is incomplete.

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 destructiveHint=true and idempotentHint=true. The description's 'Delete' aligns with destructive behavior, but adds no new behavioral traits beyond the annotation context. It mentions clearing sensitive data, which provides some additional context, but overall does not significantly enhance transparency beyond annotations.

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

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

The description is two sentences long, concise, and front-loaded with the core action. Every sentence adds value, and there is no extraneous information.

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

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

Given the tool's simplicity (one required param, no output schema, annotations present), the description adequately covers the purpose and usage context. It lacks explicit mention of the return value or success/failure indicators, but that is not required per evaluation rules. Annotations fill in the safety profile, making it fairly complete.

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

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

The input schema has 100% coverage for the single parameter 'key', with a description 'Memory key to delete'. The tool description does not add any further semantics about the parameter (e.g., format, constraints). Since schema coverage is high, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Delete a previously stored memory by key.' It specifies the verb (delete) and resource (memory by key), and distinguishes from sibling tools like remember and recall.

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

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

The description provides explicit guidance on when to use the tool: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also mentions pairing with remember and recall. Although it doesn't explicitly state when not to use it, the guidance is 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?

Beyond annotations (readOnly, idempotent, destructive=false), description adds how the tool fetches the page, extracts title/description/links, and outputs standard markdown. This provides essential behavioral context for an agent.

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

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

Two concise sentences followed by a bullet list of use cases. No redundant information, logically structured, and front-loaded with the primary purpose.

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

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

Description covers purpose, behavior, output format, and usage scenarios. Given simple input schema and no output schema, this is adequate. Minor gap: no mention of error handling or network requirements, but acceptable for a read-only tool.

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

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

Schema already covers both parameters with descriptions (100% coverage). The tool description does not add new semantic information beyond what the schema provides, so baseline score of 3 applies.

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

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

Description explicitly states verb 'Generate', resource 'llms.txt file', and context 'for any URL'. It clearly distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on file generation rather than analysis.

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

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

Description lists three concrete use cases (client indexing, personal drafting, competitor auditing) but does not explicitly state when NOT to use the tool or name alternative tools for similar tasks.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: the tool uses standard GraphQL introspection, returns types/fields/arguments, and requires the user to supply their own The Graph API key. No contradictions with the annotations.

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

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

Three tightly scoped sentences, front-loaded with the action and result, followed by the only operational caveat. No filler or repetition.

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

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

With full parameter coverage, an output schema, and safety annotations, the description supplies the missing operational context (external API key, purpose, output contents) and is sufficient for an agent to invoke the tool correctly. It could add an explicit sibling contrast, but nothing critical is missing.

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

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

Schema description coverage is 100%, so both subgraph_id and _apiKey are already fully documented in the schema. The description only reinforces the _apiKey requirement without adding new parameter-level 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?

States a specific verb and resource: 'Fetch a subgraph's GraphQL schema via standard introspection.' This clearly identifies the operation as schema discovery rather than query execution, though it never explicitly contrasts it with siblings such as query_subgraph.

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 phrase 'so an agent can build queries without external docs' implies when to use it, and the API-key requirement establishes a precondition. However, there is no explicit when-to-use guidance, no exclusion criteria, and no mention that query_subgraph should be used for actually running queries.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by confirming it returns only active subscriptions by default, specifying return fields, and implying no side effects. No contradictions.

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

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

The description is two sentences with no wasted words. The first sentence states purpose and return fields; the second gives usage guidance. Front-loaded and efficiently structured.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the main aspects: purpose, return fields, default behavior, and usage. It could mention potential pagination or limits, but given the low complexity, it is adequately 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?

The input schema already fully describes the only parameter 'include_inactive' with a description. The tool description does not add new semantic meaning beyond what is in the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it lists the caller's active subscriptions, specifying the verb 'list', the resource 'subscriptions', and the scope 'caller's active'. It also lists the returned fields, making the purpose unambiguous. Sibling differentiation is implicit through the list operation vs. subscribe/unsubscribe.

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

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

The description explicitly advises using this tool to review what you're monitoring before adding more or to find an id to cancel. This directly guides the agent on appropriate contexts, aligning with sibling tools for subscription management.

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

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

The annotations provide no safety signals (all false), so the description carries the full burden. It discloses the token-based return mechanism ('Filing without an account returns a claim_token'), the ability to check status later, rate limiting ('5 per identifier per day'), and the human review process ('digests daily'). This goes well beyond what structured annotations alone would convey.

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

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

The description is front-loaded with the core purpose and is organized logically: what it does, when to use, exclusions, how to provide feedback, token behavior, and rate limits. It's longer than the TDQS 4.3 example but each sentence contributes necessary information; no filler or redundancy.

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

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

Given no output schema, the description explains the return value (claim_token) and its later use. It also covers edge cases (different MCP servers), required content (don't paste user prompts), and quotas. For a tool with 4 params and a nested context object, this is fully sufficient.

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

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

The schema already describes all four parameters (100% coverage), so the baseline is 3. The description adds value by demonstrating the claim_token call syntax (`pipeworx_feedback({claim_token:"pwfb_…"})`) and clarifying the tool's dual mode: filing new feedback vs. checking an existing report. This provides practical 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.' It clearly distinguishes from siblings by stating 'ONLY for tools served by this Pipeworx connection' and asking to describe issues in terms of Pipeworx tools/packs, so an agent won't confuse it with ask_pipeworx or discover_tools.

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

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

Explicitly tells when to use: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives exclusions and alternatives: 'if the tool came from a different MCP server... file it with that server instead,' and offers a heuristic for disambiguation ('Pipeworx tool names are the ones this connection lists').

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds caching behavior (5min-1h), sourcing from CF analytics-engine, no PII, and self-aggregating nature, providing value beyond annotations.

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

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

The description is informative but slightly verbose. It uses bullet points for use cases, which aids readability. Every sentence adds value, though it could be slightly shortened.

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

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

Given the tool's simplicity (one optional param, no output schema), the description fully covers purpose, usage, behavior, and caching. No gaps are evident.

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 parameter 'window' has a description. The tool description adds context on how shorter vs longer windows behave, enhancing the schema's 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 returns 'top tools, top packs, and total call volume' over a recent window. It uses specific verbs ('returns') and resource ('Pipeworx trending data'), and distinguishes from siblings by focusing on trending/aggregate usage rather than direct querying or 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 enumerates three explicit use cases (discovering hot data sources, confirming canonical tool, seeing alignment). While it doesn't explicitly state when not to use it, the context is clear and actionable for an agent.

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

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

Annotations already declare readOnlyHint=true and non-destructive. The description adds rich behavioral context: algorithms (monotonicity, partition checks), filters (semantic anchor, partition filter), and fill check logic. It explains return format and failure modes (skipped_low_similarity, placeholder filtering). 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 thorough and well-structured but somewhat verbose. Each sentence adds value, but it could be slightly more concise without losing clarity. Still, excellent organization with clear sections.

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

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

Given no output schema, the description fully documents the response format with fields like gap_pp, suggested_trade, reasoning, and partition_check details. It also covers edge cases (fill check, placeholder filtering) and refers to a sibling tool for further needs. Complete for a complex tool.

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

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

Schema description coverage is 100% with brief descriptions. The tool description goes far beyond: explains parameter types (slug, URL, seed question), how each mode behaves, and details about semantic anchor and partition filter. Adds significant value beyond schema.

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

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

The description clearly states it finds arbitrage opportunities via monotonicity violations and partition-sum checks, and distinguishes three modes: trending_scan (no args), event (single event slug), and topic (cross-event seed question). It differentiates from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicitly tells when to use each mode: 'Call with NO args for a `trending_scan`... pass `event`... or `topic`...' and provides recommendations: 'event (recommended for a specific market)'. It also warns against trading when realizable_edge_pp ≤ 0 and refers to polymarket_fill_risk 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds extensive behavioral context: caching at KV level (1h), three response segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT), edge calculation details (edge_pp_net, kelly_fraction), and diagnostic info (funnel counters, filter_skips). 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 long but well-structured with clear sections (model families, tradeable-edge knobs, response top-level). It front-loads the purpose and uses capitalization for emphasis. Some sentences are dense but carry necessary detail; a slight trim could improve readability.

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

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

Given 9 parameters, no output schema, and complex logic, the description fully covers output structure (by_segment, fed_candidates, _diagnostics) and explains why segments could be empty. It also describes edge calculation methodology and knob effects, leaving no major informational gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema details; e.g., for slippage_pp it notes 'Polymarket has zero trading fees as of 2024 but bid/ask + thin depth typically eats 20-50bp per trade.' It also explains how min_kelly and min_partition_leg_kelly interact.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, distinguishing it from siblings like polymarket_arbitrage and polymarket_edge_tracker. It specifies the purpose is for agents to discover opportunities without paging hundreds of markets.

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 it is built for 'what should I bet on today' and mentions tradeable-edge knobs (min_liquidity, max_spread_pp) for filtering. However, it does not provide explicit when-not-to-use or compare directly with siblings like polymarket_arbitrage or polymarket_edge_tracker.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description details snapshot lifecycle (cache-miss gaps, 60-day TTL), return structure (tracked/expired/snapshot_dates), and computation details (daily closes, not intraday), with no contradictions to annotations.

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

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

Front-loads purpose and includes structured response details, but is verbose with lengthy inline explanations of return fields (tracked, expired, snapshot_dates) that could be more compact.

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?

Completely compensates for lack of output schema by fully describing all return fields and edge cases (gaps, TTL limits, computational basis), making the tool fully understandable for 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?

Adds value beyond schema by specifying default values (days=14, window='1wk') and constraints (days max 30, clamp 2-30), enriching the agent's understanding of parameter behavior.

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 uses specific verbs ('edge persistence and decay telemetry') and resources ('daily polymarket_edges snapshots'), clearly distinguishing this tool from the sibling 'polymarket_edges' by focusing on time-series behavior rather than current values.

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 clear context for when to use (to understand edge longevity and decay), but does not explicitly state when to avoid or list alternatives, though the purpose implies differentiation from 'polymarket_edges'.

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, destructiveHint=false. The description goes beyond by detailing the walk-the-ladder algorithm, return fields (top_of_book, vwap_fill_price, slippage_pp, verdict), and risks (thin books, forced directional risk). No contradiction with annotations.

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

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

The description is somewhat verbose but well-structured with subheadings (SINGLE-MARKET, BASKET) and clear field lists. Every sentence adds value; minor redundancy (e.g., 'capture overround by selling every leg' could be tighter) but overall efficient for the complexity.

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

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

Given no output schema and 4 parameters with nested logic, the description fully explains return values (theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk), mode behavior, and usage context (prerequisite for arb trades). Nothing missing for an agent to invoke correctly.

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

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

With 100% schema coverage, baseline is 3, but the description adds substantial meaning beyond the schema: it explains mode selection ('market' vs 'event'), default side logic, and how size_usd is interpreted differently for buys vs sells and basket mode (settlement notional). This significantly enhances agent 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's verb ('check realizable-vs-theoretical edge') and resource ('live CLOB order-book depth'). It distinguishes between single-market and basket modes, and explicitly names sibling tools ('polymarket_arbitrage', 'polymarket_edges') as triggers for using this tool, achieving strong differentiation.

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

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

The description provides explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains consequences of not using it (partial basket fills convert arb to unhedged directional position) and specifies when not to use it implicitly via the threshold.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds substantial behavioral depth beyond those: compatibility_warning and compatibility_codes can be non-empty even with matched pairs, unknown metric/match types are never paired, temporal_alignment null does not mean aligned, and Kalshi fees are not modeled. This gives the agent a realistic model of what the tool returns and where its output can mislead.

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 it is front-loaded with the core purpose and then organized into modes, response shape, safety fields, and caveats. Nearly every sentence earns its place given the tool's complexity and lack of an output schema. It would be slightly easier to parse with distinct sections or line breaks, but it is dense rather than padded.

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

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

With no output schema, the description carries the full burden of explaining return semantics, and it covers leg-by-leg prices, spread entries, top_spreads_pp, flags, compatibility codes, temporal alignment, skipped counters, fees, and unclassified leg handling. Given the tool's complexity, this is a comprehensively complete definition.

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

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

Although the schema already documents all three parameters at 100% coverage, the description adds meaning beyond that by explaining topic as a pre-mapped shortcut set, clarifying that kalshi_event_ticker and polymarket_event_slug override the topic-mapped side, and stating that both modes run the identical matcher. This materially improves an agent's ability to choose and combine parameters correctly.

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

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

The description opens with 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' which clearly identifies the resource and the comparison being made. It does not explicitly name sibling tools such as polymarket_arbitrage, so some differentiation is left implicit, but the Kalshi-vs-Polymarket focus is 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 explains two distinct modes — the pre-mapped topic shortcuts and explicit event pairing — and tells the agent when each is appropriate. It also warns that pre-mapped topics often return compatibility warnings and that spreads are gross, not net tradeable, giving useful when-not context. It does not explicitly enumerate alternative tools to use instead.

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=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it states the API key requirement ('Requires your own The Graph API key'), clarifies the subgraph_id format, and explains the return value ('Returns the GraphQL data block plus any errors'). This is solid transparency for a networked read operation.

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, each earning its place: the first states the action, the second clarifies the critical identifier format, and the third covers return behavior and the prerequisite. Information is front-loaded and there is 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?

The tool has 4 parameters with 100% schema coverage, a rich output schema, and annotations covering read-only, idempotent, open-world, and non-destructive behavior. The description adds the operational context an agent needs: API key ownership, subgraph ID format, and return shape. Nothing essential for selecting and invoking the tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that subgraph_id is a deployment hash with two possible formats (Qm... or 0x...) and by reinforcing that _apiKey is user-supplied and not provisioned by Pipeworx. These details help the agent form correct calls beyond what the schema already states.

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

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

The description opens with a specific verb and resource: 'Run a GraphQL query against a subgraph on The Graph network.' It also clarifies the return shape (data block plus errors) and the required API key. This is clearly distinct from the sibling tools, none of which describe GraphQL subgraph querying.

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

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

The description gives clear context for when the tool applies: querying a subgraph on The Graph with a specific deployment ID and a user-supplied API key. It does not explicitly name alternatives or exclusions, but the uniqueness of the tool among siblings makes the intended use unambiguous. A prerequisite is clearly stated, which is useful 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=true and idempotentHint=true. The description adds context about scoping to an identifier and pairing with siblings, but does not elaborate on auth or side effects beyond annotations. 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 concise, front-loaded with the action, and uses minimal sentences to cover all necessary information without excess.

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 one optional parameter and no output schema, the description fully covers behavior, usage, scoping, and relationships to 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?

Input schema covers the 'key' parameter with 100% description coverage. The description adds nuance: omitting key lists all keys, and key should correspond to a saved value, adding 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 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument)', using a specific verb+resource structure. It distinguishes from siblings like 'remember' and 'forget'.

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

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

The description explains when to use ('to look up context the agent stored earlier... without re-deriving it from scratch') and provides pairing guidance with 'remember' and 'forget'. It does not explicitly state when not to use, but the context is clear.

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

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

Annotations already mark readOnly/idempotent/non-destructive. Description adds valuable details: return fields (source, citation_uri, raw payload), mark_read behavior (flags read for next call), and that polling is fine. 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?

Three efficient sentences: first states purpose, second describes return content and filtering, third gives usage tips. Front-loaded with key action, 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?

No output schema, but description explains return fields (source, citation_uri, raw payload). Covers all parameters with usage context, includes alternative access method, adequate for a read-only feed 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 has 100% description coverage, so baseline is 3. Description adds context: 'type' filters subscription type, 'since' is ISO timestamp, mark_read affects subsequent calls, default limit 50. Adds extra nuance beyond schema.

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

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

Clearly states 'Pull fired events from your subscription feed' with specific verb 'Pull' and resource 'fired events'. Distinguishes from siblings like list_subscriptions by focusing on alert content rather than subscription configuration.

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

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

Provides context on filtering by type/since, mark_read effect, and polling suitability. Mentions alternative HTTP endpoint for scripting. Lacks explicit when-not-to-use but covers main usage 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?

The description adds significant behavioral context beyond annotations: it notes the parallel call, the soft-fail for USPTO due to API sunset, and the return structure (changes[] grouped by source, total_changes, citation URIs). No contradictions with annotations.

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

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

The description is front-loaded with user query examples and is information-dense. While slightly long, every sentence adds necessary detail. It is well-structured and concise for the complexity of the tool.

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

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

Given the tool's complexity (aggregating from multiple sources), the description is highly complete: it covers sources, fallback, parameter formats, output structure, and sibling tool differentiation. No output schema exists, but the description adequately explains returns. This is exceptionally thorough.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing examples for `since` ('7d', '30d', '3m', '1y') and recommending '30d' or '1m' for typical monitoring. It also clarifies `value` accepts ticker or CIK. This extra guidance justifies a 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 explicitly states the tool provides a change feed for a company over a time window, with examples like 'What's new with X' and 'latest on Y'. It details the sources (SEC, GDELT/GNews, USPTO) and distinguishes from sibling entity_profile, making the purpose very clear.

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

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

The description provides concrete usage examples and explicitly tells when not to use it ('Use entity_profile instead when you want the static profile'). It also explains fallback behavior (GDELT preferred, GNews on error) and the `since` parameter shorthand, offering clear 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?

Describes persistence beyond annotations: authenticated users get persistent memory, anonymous sessions retain memory for 24 hours. Also mentions scoping by identifier. No contradictions with annotations (idempotentHint, destructiveHint).

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

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

Description is four sentences, each adding value: purpose, usage, storage mechanics, persistence, and companion tools. No redundant or 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 two string parameters, no output schema, and comprehensive annotations, the description fully covers behavior (idempotent, non-destructive), retention policies, and pairing with sibling tools. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond schema—only mentions 'key-value pair', which schema already details. No additional parameter nuances.

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 'save' and resource 'data', explaining it stores key-value pairs for reuse across conversations. It distinguishes from sibling tools like recall and forget by specifying storing vs retrieving/deleting.

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

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

Explicitly advises use 'when you discover something worth carrying forward' and mentions pairing with recall to retrieve and forget to delete, providing clear context for when to use this tool versus alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds substantial behavioral context: internal cascading through multiple endpoints, graceful degradation when LEI/FIGI sources are down, explicit `figi_candidates` on ambiguity, source-labelled identifiers, and explicit `unresolved` reporting. This goes well beyond what annotations convey.

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 examples and the core usage directive, and the density is justified by the tool's complexity. However, the prose is long and run-on in places, with nested parentheticals that could be structured more cleanly while saying the same things.

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

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

Given the tool has two parameters, no output schema, and a complex resolution pipeline, the description covers everything an agent needs: supported entity types, input forms, failure behavior, ambiguity handling, third-party dependencies, and cross-reference to other tools. Nothing important is left unstated.

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 rich meaning beyond the schema, especially for `value`: exact formatting guidance, the bond-issuer caveat about matching names exactly and not including security-class words, and examples for both company and drug types. This is far above the baseline.

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

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

The description names a precise action — resolving a spoken name to canonical identifiers — and scopes it with concrete example queries and supported types. It clearly positions the tool as the identifier-lookup step for other tools, which sets it apart from siblings like compare_entities or 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?

It gives an explicit trigger condition: "Use FIRST whenever you have a name but need an ID," plus recognizable user-phrase examples. It does not name siblings to avoid or give when-not-to-use guidance, so it falls just short of a full 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it explains the probe workflow (using ai_visibility_check), the ranking process, and the output fields (score, confidence, signal density). 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 only two sentences but packs essential information: action, workflow, use case, and output. It is front-loaded with the core purpose and avoids redundancy. Every sentence adds value.

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

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

Given the tool complexity (4 params, no output schema), the description adequately covers purpose, usage, workflow, and output. It mentions return fields but not exact structure; however, for a comparative audit tool, this is sufficient. A slightly more detailed output example would raise it to 5.

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

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

Despite 100% schema coverage, the description adds significant semantics: it notes that the first entity is treated as 'subject' for narrative, specifies entity count range (2-8), and explains the role of the models and context parameters in the comparison. This goes well 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 verb 'compare' and resource 'AI visibility across multiple entities'. It distinguishes itself from sibling 'ai_visibility_check' by emphasizing side-by-side comparison and ranking, making the purpose specific and unambiguous.

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

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

The description provides a clear usage scenario ('competitive AI-marketing audits') with a concrete example question. While it does not explicitly state when not to use or name alternatives, the context is sufficiently clear for an AI agent to infer appropriate use.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds significant behavioral details: composite call structure, fan-out to two services, partial failure handling, timeout specifics (5-30s), and return field list. No contradictions.

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

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

Description is long but every sentence adds value. Front-loaded with main purpose. Could be slightly more concise but highly efficient given the complexity.

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

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

Despite lacking an output schema, the description fully enumerates the return fields, handles edge cases (partial failures, timeout), and covers all important aspects. Highly complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds that scoped packages are accepted and version defaults to latest, which adds helpful context 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 it's a composite check for npm packages covering license, advisories, version history, and bundlephobia info. It distinguishes itself from siblings by specifying the exact use case and ecosystem scope.

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

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

Explicitly states when to use ('is X safe / popular / small' or 'what does adding lodash cost me'), specifies NPM-only scope, and mentions graceful degradation for partial failures. Provides clear guidance on context.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds substantial context: embedding model (BGE-base-en), similarity metric (cosine), windowing (500-char overlapping windows), and limits (200K chars, truncation flag). This goes well 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 front-loaded with the main purpose and includes necessary details in a logical flow. It is slightly long but every sentence adds value, making it efficient overall.

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 return values ('passages with character offsets and similarity scores'), limitations (200K char cap with truncation), and integration with sibling tools. No output schema exists, so this completeness is essential and well-handled.

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

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

Schema coverage is 100% with parameter descriptions. The description adds meaning by providing concrete examples (e.g., 'SEC 10-K body', 'supply-chain risk') and clarifies the purpose of the 'text' and 'query' parameters. The 'limit' parameter is implied but not explicitly detailed in the description beyond 'top-N'.

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

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

The description clearly states the action ('semantic search') and the resource ('inside a fetched record'), with a specific verb and resource. It distinguishes from sibling tools like ask_pipeworx_grounded by explaining the focused use case.

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 the record is too big to cram into the prompt' and suggests pairing with ask_pipeworx_grounded for grounding, providing clear context for when to use this tool over 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 rich behavioral context beyond annotations: OAuth requirement, subscription types with examples, delivery channels, email/SMS constraints, webhook HMAC signing details, and auto-disable after 10 consecutive failures. Annotations already indicate idempotent and non-destructive, and description aligns.

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

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

Reasonably concise given the complexity; front-loaded with purpose. Could be slightly more terse in delivery descriptions, but each sentence adds necessary detail.

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

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

Given the tool's complexity (multiple subscription types, delivery options, OAuth requirement, rate limits), the description covers all critical aspects: return value, prerequisites, types, delivery channels, limits, webhook signing. No output schema, but description sufficiently explains what is returned.

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 description adds significant meaning with examples and constraints for each parameter (e.g., type enum descriptions, params field with full examples, delivery field with detailed webhook signing process, phone verification, rate limits). Exceeds baseline expectation.

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 creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. The verb 'create' and noun 'subscription' are specific, and the resource is live-data event stream. Distinguishes from siblings like list_subscriptions and unsubscribe by nature.

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 context on when to use (creating a subscription) and prerequisites (requires Pipeworx OAuth account). Mentions limitations for anonymous/BYO users and delivery channel restrictions. Does not explicitly state when not to use, but the purpose is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds behavioral context: it is nondestructive, returns static example questions, and can be called with no arguments. No contradictions.

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

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

Description is front-loaded with common query patterns and is information-dense without being verbose. Every sentence adds value. Could be slightly more concise but structure is clear.

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

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

For a simple tool with one optional parameter and no output schema, the description covers all necessary context: what it returns (category-bucketed questions with tool info), when to use it (first step), and how to vary its behavior. Complete and self-contained.

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

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

Parameter schema has 100% coverage with a description. Description adds value by explaining the purpose of omitting vs. specifying topic and listing the possible values in a readable format (e.g., 'finance', 'pharma'). Goes beyond the schema's terse enum list.

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 returns category-bucketed example questions with exact tool and argument shape. Identifies itself as the onboarding entry point for a new agent, distinguishing it from siblings like ask_pipeworx or 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?

Explicitly advises 'Use this FIRST when you do not yet know what Pipeworx can do for you'. Provides context on when to use (initial onboarding, learning meta-tools) and mentions the topic parameter to narrow scope. Does not explicitly list when-not scenarios, but the guidance is clear enough.

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

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

Description adds value beyond annotations: deactivation vs deletion, historical events retained. Aligns with idempotentHint and destructiveHint. Clearly states ownership enforcement.

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

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

Two sentences, no waste. Front-loaded with action and key constraints.

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 one-param tool with annotations, the description covers purpose, constraints, side effects, and retention policy. No output schema needed; 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 already documents 'id' as uuid returned by subscribe (100% coverage). Description only says 'by id', adding no new meaning beyond schema.

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

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

Clearly states 'Cancel a subscription by id' and distinguishes from siblings like subscribe and list_subscriptions by specifying effect (deactivate) and ownership enforcement.

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

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

Gives clear context: ownership enforcement and that the subscription is deactivated not deleted. Does not explicitly state when not to use or alternatives, but the constraint is 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?

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by explaining critical behavioral nuances: the distinction between 'could_not_verify' (a failed check, not evidence) and 'unsupported' (no source covers it), the routing logic, and the return structure with citations. It also discloses limits like percent-delta math and the cap on tolerance, providing significant transparency.

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

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

The description is lengthy but appropriately so for a complex tool. It is front-loaded with example phrasings, then explains purpose, pipeline routing, return values, and a crucial caller warning. Every sentence adds value, and the 'IMPORTANT for callers' section is clearly structured for practical use.

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

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

Despite having no output schema, the description fully specifies the return format (verdict types, actual value with citation, reasoning) and explains the meaning of each verdict, including the error field for 'could_not_verify'. It covers both pipeline paths and the tool's role as a replacement for multiple steps, making it complete for an agent to invoke and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the claim parameter with examples and mentions tolerance_pct indirectly (percent-delta math, implied tolerance), but it does not add substantial semantic detail beyond what the schema already provides. The schema's own descriptions are already thorough, so the description adds marginal value here.

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

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

The description clearly identifies the tool as a natural-language claim verification tool, with explicit example phrasings and a specific verb+resource ('verify the claim'). It distinguishes itself from siblings by detailing the two pipeline paths (SEC EDGAR/XBRL for company financial claims, grounded pipeline for everything else) and noting it replaces 4–6 sequential calls, making its unique role 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?

It explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct,' which is clear when-to-use guidance. It also explains the division between financial and non-financial claims. However, it does not provide explicit when-not-to-use guidance or name alternative tools, which would elevate it to a 5.

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