Itis

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it probes LLMs, returns per-model data, and that passing _apiKey probes Anthropic with direct payment. 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 sentences, front-loaded with verb and resource, no fluff. 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?

All parameters are covered in schema with descriptions, annotations cover safety, and the description explains the return structure despite no output schema. Complete for the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. The description adds context: entity is what to ask about, models list with defaults, _apiKey for Anthropic, context for disambiguation. This enhances 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 probes LLMs for knowledge about an entity and scores visibility (0-100). It specifies the default model and optional Anthropic probing, distinguishing it from sibling tools like deep_research or compare_entities.

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

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

The description mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It does not explicitly state when not to use or compare to siblings, 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 indicate readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context: it routes to sub-tools, fills arguments, and returns structured answers with stable pipeworx:// citation URIs, which goes beyond the annotations and helps the agent set expectations. It does not discuss error cases or latency, but the core behavior is clearly disclosed.

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 front-loads the most important guidance, starting with 'PREFER OVER WEB SEARCH' and then covering mechanism, trigger phrases, examples, and escalation rules. The final instructions are slightly awkward ('Step up only when needed', '*news-feeds packs'), which prevents a 5, but nearly every sentence earns its place given the tool's routing 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 this is a high-complexity router tool with no output schema and only minimal annotation context, the description is remarkably complete. It specifies input expectations, data domains, trigger phrases, example queries, routing behavior, output form with citation URIs, and when to escalate to deep_research. An agent has enough information to decide when to call it and what to expect.

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

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

Schema coverage is 100%, so the description does not need to duplicate parameter documentation; the 'question' parameter and its aliases are already well described in the schema. The description's example questions illustrate natural-language phrasing but do not add technical parameter constraints. This matches the baseline 3 for high schema coverage.

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

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

The description opens with 'PREFER OVER WEB SEARCH' and clearly states that this tool answers factual questions by routing them to one of 5,798 tools across 1,517 verified sources, filling arguments, and returning structured answers with citation URIs. It lists concrete domains and example questions, and differentiates itself from web search and deep_research, making its purpose unmistakable.

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

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

The description gives explicit when-to-use guidance: prefer over web search, use for trigger phrases like 'what is', 'look up', 'find', 'get the latest', and even when web search could answer. It also names alternatives and escalation conditions, such as using deep_research for broad/multi-part questions requiring fan-out, and clarifies that breaking-news is already handled by this tool via live-news packs.

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 important context: it is fully functional, has no fallback, currently matches ask_pipeworx exactly, and exists as the experimental edge of the router.

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 long but every sentence earns its place: it explains what the tool is, its current active state, when to use it, and how it relates to the stable router. The key experimental nature is front-loaded.

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

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

For a router tool with no output schema, the description covers the essential context: full functionality, identical behavior to ask_pipeworx, experimental routing, and the comparison process. It does not describe expected answer content in detail, but the schema and annotations already cover aliases and safety.

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 schema fully documents all 6 parameters and their alias relationships. The description adds no parameter-level detail, which is acceptable given the high schema coverage.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, an identical universal router with the same 5,798 tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx and from ask_pipeworx_grounded by the experimental routing candidate aspect.

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

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

The description explicitly says to use it exactly like ask_pipeworx when you want the newest routing, and notes results are compared against the stable router. It provides clear usage context, though it could more explicitly state when to prefer ask_pipeworx or ask_pipeworx_grounded 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?

The description goes well beyond the annotations (readOnlyHint=true, idempotentHint=true): it fully discloses the success return contract {answer, evidence (verbatim quote), confidence, source, fetched_at, refusal_reason:null} and enumerates every refusal_reason value (not_in_source, no_tool_match, tool_error, data_truncated, llm_error). This tells the agent exactly what failure looks like and why. No contradiction with annotations — 'reads' aligns with readOnlyHint.

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?

Five dense sentences, each carrying distinct weight: mode identity, routing behavior, success/refusal contract, use cases, and cost tradeoff. The defining phrase is front-loaded. At roughly 120 words for a tool with this much behavioral complexity, the length is fully earned — nothing is redundant or decorative.

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 (routing across 5,798 tools, grounding, refusal modes) and absence of an output schema, the description supplies the complete return contract — the single most critical missing piece — and enumerates all failure reasons. Annotations already cover safety; the schema covers the parameter; usage and alternatives are explicit. An agent has everything needed to call it correctly and interpret results.

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

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

Schema coverage is 100% — the schema fully documents the single effective parameter 'question' and lists all aliases (query, q, prompt, text, input). Per the high-coverage baseline, the description need not add parameter detail, and it doesn't. The description does implicitly enrich the semantics by clarifying the question is routed across 5,798 tools rather than a simple lookup, but it adds no format or constraint information beyond the schema, so a 3 is appropriate.

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

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

The description opens with a specific, differentiated claim — 'Hallucination-resistant answer mode for high-stakes reads' — naming the verb (answers), resource (Pipeworx sources via routed tools), and distinguishing trait (grounded extraction). It explicitly contrasts with ask_pipeworx ('Same routing... then EXTRACTS the answer using ONLY what the tool result contains'), which lets an agent separate this from the closest sibling without opening any schema.

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

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

Use conditions are explicit and concrete: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with named domains (financial verdicts, legal claims, medical lookups, public statements). The exclusion is equally explicit: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups,' naming the alternative tool directly. Nothing is left to inference.

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 provides extensive behavioral detail beyond annotations: fan-out patterns, resolver contract, parent event extraction, news fallback behavior, safety short-circuits, spread liquidity warnings, and cancellation rule risk. Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are all consistent and supplemented.

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 essential information. It is front-loaded with the core purpose and uses examples. While it could be trimmed, every sentence adds necessary context for such a complex tool.

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

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

The description covers all aspects: input formats, fan-out examples, response shapes, resolver confidence, parent event extraction, news fallback, safety mechanisms, illiquid spreads, and cancellation rule risk. No gaps are apparent.

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 significant value: examples for the 'market' parameter, usage guidance for 'depth' (quick vs thorough), and 'include_raw' (default false, when to use true). It explains parameter behavior 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 uses specific verbs and resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data'. It clearly distinguishes inputs (slug, URL, question) and outputs (evidence packet, market-vs-model comparison). The purpose is explicit and non-tautological.

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 for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It also covers when to avoid (low-confidence matches, closed markets) and safety checks, making it clear when the tool 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?

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by explaining that results are sorted by primary metric ('largest' reads off top), that off-calendar fiscal years are handled correctly, and that pipeworx:// citation URIs are returned. It could further clarify data freshness or potential latency.

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 information-dense but well-organized, starting with trigger phrases and then detailing behavior per type. It avoids unnecessary fluff, though some example queries could be trimmed without loss of clarity. The structure is front-loaded with the key use-case cues.

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

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

Given the absence of an output schema, the description adequately explains what is returned (paired data, sorted results, citation URIs) and covers both entity types. It provides sufficient context for an agent to understand the tool's capabilities without external documentation.

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

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

The input schema has 100% coverage with descriptions for both 'type' and 'values'. The description enriches these by providing concrete examples (tickers/CIKs for company, drug names for drug), specifying the 2-5 range, and explaining how each type affects the data pulled. This adds significant 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 it performs side-by-side comparison of 2-5 companies or drugs, provides trigger phrases, and distinguishes from sequential lookups. It specifies the data pulled for each type (SEC filings for companies, FAERS/FDA/trials for drugs), making the purpose unambiguous.

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

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

The description explicitly advises preferring this tool over sequential single-pack lookups and gives example queries ('X vs Y', 'rank these companies'). It explains when to use type='company' vs type='drug' based on entity type. However, it does not mention cases where the tool should not be used (e.g., needing more than 5 entities or data beyond what is provided).

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

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

Annotations only cover read-only/open-world/idempotent safety, so the description adds substantial behavioral context: account/paid-tier requirements, parallel decomposition, gap reporting with 'never invented', fetchable citation_uri semantics, semantic excerpting of large records, contradiction detection, and latency expectations. None of this contradicts the annotations.

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

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

The description is long but densely packed with necessary information, and it front-loads the critical account/alternative message. There is mild redundancy around ask_pipeworx and depth behavior, but every major section earns its place for a tool this complex.

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

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

There is no output schema, so the description compensates thoroughly by describing the findings packet, evidence/confidence/source fields, gaps[], contradictions[], citation URIs, and latency. It also covers prerequisites, depth semantics, and the sibling alternative, leaving little missing for an agent to call 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% and the depth parameter is already well documented. The description adds value beyond the schema by explaining the paid requirement for thorough, the gap-recovery/contradiction behavior at different depths, and the overall research flow, though the question parameter itself gains little additional 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 states a specific verb and resource: grounded multi-source research across 1,517 structured data sources, with decomposition into facets and parallel routing to tools. It also explicitly distinguishes itself from open-web search and from ask_pipeworx, so an agent can tell it apart from siblings without inspecting schemas.

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, with concrete examples. It also names the alternative for single lookups (ask_pipeworx) and the condition for using that alternative (not signed in / single lookup), which is exactly the kind of routing guidance an agent needs.

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 and idempotent. Description adds useful context: returns schemas with curated examples ready for direct invocation, 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?

Well-structured: front-loads purpose, lists domains compactly, explains output format in one sentence, and ends with actionable usage tip. Every sentence adds value.

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

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

Despite no output schema, description fully explains return values (names, descriptions, schemas, examples) and how to use them. Sufficient for agent decision-making given tool complexity and annotations.

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

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

Schema coverage is 100% with thorough descriptions. Description mentions aliases (already in schema) and provides examples, but does not add significant new parameter-level meaning beyond what the schema gives. Baseline 3 is appropriate.

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

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

Description clearly states the tool discovers tools by describing data/task, lists many domain examples (SEC, FDA, etc.), and specifies returns top-N relevant tools with schemas ready to call. It distinguishes itself from sibling tools like ask_pipeworx or deep_research which are specific-purpose.

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

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

Explicitly advises 'Call this FIRST when you have many tools available and want to see the option set'. Does not include when-not-to-use cases, but the context implies alternative when target tool is already known.

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

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

Even with readOnlyHint, openWorldHint, and idempotentHint already declared, the description adds substantial behavioral context: the GDELT→GNews news fallback, the crucial 'empty section is a real no-data, not a bug' semantics via sources_used/sources_failed, name resolution via SEC EDGAR, and resolved_from/resolved_to behavior. This genuinely shapes how an agent interprets results and avoids false failure reports.

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 well with trigger phrases and the core value proposition, and every sentence carries information. However, it is one dense run-on paragraph where return-field details, fallback logic, and failure semantics are crammed together with parentheticals and dashes, making it hard to scan. A bulleted structure would dramatically improve parseability 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?

For a tool this complex with no output schema, the description carries the full burden — and it delivers. It covers all three input shapes, the full set of return fields (including the meaningful clarification that fda_products only covers biologics and 'none' is expected for small-molecule companies), sources_used/sources_failed interpretation, fallback behavior, and the resolved:false private-company case. An agent has what it needs to invoke and interpret this tool correctly.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description's parameter guidance ('Pass a ticker, zero-padded CIK, OR a company name', 'type accepts company or ticker interchangeably') largely restates the schema rather than adding new meaning. It adds only marginal color like the zero-padding example, which the schema already includes.

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 precise verb+resource+scope: 'full cross-source profile of a US public company in ONE parallel call.' The trigger-phrase examples ('Tell me about X', 'research Acme', 'brief me on Tesla') make the purpose unmistakable, and it distinguishes itself from sibling single-pack lookups by naming the fan-out strategy that defines it.

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

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

Gives explicit when-to-use guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Trigger examples clarify when an agent should route to it, and the private-company resolved:false behavior describes a boundary case. It does not explicitly contrast with close siblings like deep_research, compare_entities, or resolve_entity, so the routing picture is not complete.

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 confirms destructive nature (matches destructiveHint=true) and adds context about clearing sensitive data. Annotations already cover destructive hint; description adds moderate extra context but no detail on side effects or errors.

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

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

Two sentences plus a pairing note, front-loaded with action and resource. No wasted words, highly efficient.

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

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

For a simple single-parameter deletion tool with no output schema, description covers use cases and pairing. Lacks details on post-deletion behavior or error handling 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% with parameter 'key' described as 'Memory key to delete.' Description adds no additional meaning beyond what schema provides, baseline 3.

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 'Delete a previously stored memory by key,' specifying verb, resource, and scope. Distinguishes from siblings 'remember' and 'recall' by naming them explicitly.

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

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

Explicitly says when to use (stale context, task done, clear sensitive data) and pairs with remember and recall. No explicit when-not or alternatives, but clear context provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details: it fetches the page, extracts title/description/key links, emits standard llms.txt format, and outputs a single text blob. No contradictions with annotations.

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

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

The description is a single focused paragraph with no fluff. It front-loads the main purpose, then explains the process, and ends with use cases. Every sentence earns its place.

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

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

For a simple generation tool with only 2 parameters and no output schema, the description covers the essential flow (fetch, extract, emit). It explains the output format and deployment location. The lack of output schema is compensated by the clear description of what is produced.

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 description adds little beyond what the schema provides. The mention of default (25) and max (50) for max_links is implicit but not explicitly stated. Baseline 3 is appropriate since the schema already documents parameters well.

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

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

The description uses a specific verb ('Generate'), resource ('llms.txt file'), and target ('any URL'), clearly distinguishing it from sibling tools like 'ai_visibility_check' or 'scan_competitor_ai_presence'. It states the exact output and intended audience.

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 lists three use cases (client indexing, personal project drafting, competitor auditing), which guides when to use the tool. However, it does not state when not to use it or mention alternatives among the siblings.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, which cover safety and behavior. The description adds that it returns names 'in all languages' and gives examples. This adds mild context but does not contradict annotations. The description's contribution is adequate given the rich 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: the first states the core functionality and includes concrete examples; the second provides usage guidance and a keyless note. Every sentence is informative and front-loaded, with zero wasted words.

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

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

For a simple lookup tool with one parameter, no output schema, and no nested objects, the description is complete. It explains the tool's purpose, input source (TSN from search_taxa), and scope (all languages). No additional details are needed for correct usage.

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

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

The single parameter 'tsn' is fully described in the input schema with type, description, and examples. The description reiterates 'Taxonomic Serial Number, e.g. 180582', adding no new semantics beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get', the resource 'vernacular (common) names', and the input 'TSN'. It provides concrete examples like 'Bobcat' and 'lynx roux', and distinguishes from sibling tools like search_taxa and get_hierarchy by focusing specifically on common names.

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

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

The description explicitly tells users to 'Pass a TSN from search_taxa', establishing a clear prerequisite and usage context. The note 'Keyless' implies no authentication is needed. However, it does not explicitly state when not to use this tool or mention alternatives, but the direct link to search_taxa is sufficient guidance.

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

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

Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds that it returns each rank with tsn, name, rank, and parent_tsn, and mentions it is keyless. This transparently describes the output and access requirements.

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

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

The description is concise: three sentences covering purpose, return data, and prerequisites/cost. Every sentence adds value without unnecessary 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 simplicity (1 parameter, no output schema), the description covers the main aspects: purpose, output structure, and usage context. Lacks error handling details, but overall sufficiently complete.

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

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

The schema has 100% coverage for the single parameter tsn, describing it as 'Taxonomic Serial Number, e.g. 180582.' The description adds value by stating the TSN should come from search_taxa, providing additional 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 the tool walks the full taxonomic hierarchy from kingdom down to the taxon and its children for a given TSN. This distinguishes it from sibling tools like search_taxa and get_common_names, which serve different purposes.

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

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

The description specifies that the TSN should come from search_taxa and that the tool is keyless (free). While it doesn't explicitly state when not to use it, the context of sibling tools and the explicit prerequisite provide good usage guidance.

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

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

Annotations indicate readOnly, idempotent, non-destructive. The description adds that it returns specific fields and that the default is active subscriptions. No contradictions.

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

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

Two concise sentences: purpose, return fields, and usage guidance. No redundant information.

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

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

For a simple list tool with one optional parameter and rich annotations, the description is sufficient. No output schema needed.

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%. The description does not add meaning beyond the schema's parameter description. The mention of 'active' aligns with the default, but no new depth.

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

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

The description clearly states the tool lists the caller's active subscriptions and specifies the returned fields (id, type, params, etc.). This distinguishes it from sibling tools like subscribe and unsubscribe.

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

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

The description advises using this before adding more subscriptions or to find an id to cancel. This provides clear context, though it does not explicitly mention when not to use it.

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

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

Annotations are all false, offering no safety or behavior hints, so the description carries the burden. It discloses the claim_token workflow, daily rate limit (5 per identifier per day), that feedback is free and doesn't count against quota, and that the team reads digests daily. These are material behavioral details an agent needs before calling.

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

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

The description is long but information-dense: every sentence contributes (when, when-not, token flow, limits, cost). It is front-loaded with the core purpose and structured logically, though slightly longer than necessary for a simple feedback 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 no output schema and simple return value (a claim_token on filing), the description fully covers what an agent needs: how to file, how to check status, rate-limits, and scope. It even mentions that filing without an account still returns a claim_token, covering the edge case.

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

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

Schema already covers all 4 parameters with 100% description coverage, so baseline is 3. The description adds practical context: claim_token is for reading a previous report and should be passed alone, message should be specific with 1-2 sentences typical, and type examples tie to the reported scenarios. This extra guidance nudges the score to 4.

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

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

The description opens with a specific verb+resource ('Tell the Pipeworx team something is broken, missing, or needs to exist'), enumerates the message types (bug, feature/data_gap, praise), and explicitly scopes to 'tools served by this Pipeworx connection,' distinguishing it from sibling research tools like ask_pipeworx and entity_profile. This leaves no ambiguity about what the tool 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?

Explicitly states when to use (bug, feature/data_gap, praise) and when not to ('if the tool came from a different MCP server... file it with that server instead'), plus instructions on how to describe the issue (in terms of Pipeworx tools/packs, don't paste the end-user's prompt). This goes far beyond typical tool descriptions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: data source (CF analytics-engine), no PII, and caching policy (5min-1h). This exceeds annotation coverage without contradiction.

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

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

The description is efficiently structured: main purpose in first sentence, then bullet-like use cases, then data provenance and caching. Every sentence adds unique value, no redundancy. Front-loaded with essential info.

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

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

Given the tool's simplicity (1 optional parameter, no output schema), the description fully covers what the tool does, what it returns, use cases, and behavioral details. Annotations already handle safety, so completeness is high.

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 covers the single parameter (window) with enum and description. The description adds semantic guidance: shorter windows for hot trends, longer windows for steady-state demand. This provides extra interpretative value beyond the schema.

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

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

The description clearly states it returns trending data from other AI agents (top tools, packs, call volume) over specified time windows. It uses specific verbs like 'returns' and distinguishes from sibling tools by focusing on aggregate usage signals rather than individual queries or entity lookups.

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

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

The description lists three explicit use cases (discovering hot data sources, confirming canonical choice, aligning with agent needs). It does not explicitly mention when NOT to use or name alternative sibling tools, but the provided contexts are sufficiently clear for selection.

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

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

The description adds significant behavioral context beyond the annotations (which indicate read-only, idempotent, open-world). It explains the fill check against live CLOB depth, the semantic anchor (Jaccard similarity threshold), the partition filter (placeholder slugs), and the resulting trade signals. No contradiction with annotations.

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

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

The description is well-structured with clear sections and front-loaded purpose, but it is lengthy (multiple paragraphs) and contains some technical jargon that could be condensed. Every sentence is justified, but brevity could improve clarity.

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

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

Given the complexity of the tool and lack of output schema, the description is exceptionally complete. It explains monotonicity, partition checks, semantic anchor, fill checks, response format (opportunities array), and directs to associated tools for further use. No gaps identified.

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

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

With 100% schema description coverage, baseline is 3. The description goes far beyond, explaining the difference between event and topic modes, providing example values (e.g., 'fed-decision-may-2026'), noting that full Polymarket URLs are accepted for event, and describing the detailed behavior of each mode.

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

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

The description clearly states the tool's purpose: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes itself from sibling tools by specifying the exact methodology and modes (trending_scan, event, topic), and references a sibling tool (polymarket_fill_risk) for custom sizing.

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 each mode: no args for trending_scan, 'event' for specific event slug, 'topic' for cross-event scanning. It also specifies when not to trade (realizable_edge_pp <= 0) and directs to polymarket_fill_risk for custom sizing. Examples of event slugs and topic questions are given.

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, not destructive. Description adds extensive behavioral context: model families, edge calculation, response structure with by_segment, diagnostics, caching at KV level, Fed bets exclusion. 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?

Fairly long (~300 words) but every sentence adds unique value. Front-loaded with purpose and segmentation. Could be slightly more terse, but dense information justifies length.

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

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

For a complex tool with 9 params and no output schema, the description covers input knobs, response structure (by_segment, fed_candidates, diagnostics), edge computation details, and caching. Agent has everything to understand inputs, outputs, and behavior.

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

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

Schema coverage is 100%, but description adds operational meaning beyond schema descriptions. For example, explains that slippage_pp is subtracted from raw edge before ranking, min_kelly suppresses small opportunities, and min_partition_leg_kelly applies to per-leg Kelly. Very helpful.

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 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price', with a specific verb+resource and a use case sentence. Distinguishes from siblings by naming specific segments and hinting at unique capabilities.

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 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets'. Does not directly contrast with siblings like polymarket_arbitrage, but purpose is clear enough to decide when to use.

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

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

Annotations indicate safe, read-only, idempotent, non-destructive behavior. The description adds significant detail: explains response fields (tracked, expired, snapshot_dates), computation of trend and decay, data gaps, TTL limits, and that decay is based on daily closes. 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 well-structured: starts with a high-level purpose, then details response fields and limitations. It is somewhat lengthy but every sentence provides useful information. Could be slightly more streamlined but still effective.

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

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

For a tool with 2 optional parameters and no output schema, the description is remarkably complete. It explains the response format thoroughly, covers edge cases (expired opportunities, data gaps), and notes limitations (TTL, snapshot start). The agent has enough information to use the tool correctly.

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

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

Schema covers both parameters with descriptions. The tool description adds default values (14 for days, '1wk' for window), clarifies the max for days (30), and explains the window parameter as snapshot family. This adds value beyond the schema.

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

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

The description clearly states it provides edge persistence and decay telemetry from daily snapshots. It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools like polymarket_edges by focusing on historical tracking.

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 this tool: to understand edge history and distinguish between new and old wide edges. It does not explicitly mention when not to use it or alternatives, but the context implies it is for historical analysis rather than current snapshots.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds that it walks the ladder, returns verdicts (clean|degraded|cannot_fill), clamps size, and names forced directional risk legs. No contradiction.

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

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

Well-structured with bold headers and bullet-like phrasing. Slightly verbose in explaining return fields but front-loaded with critical usage guidance. Each 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?

No output schema, so description fully details return values: top_of_book, vwap_fill_price, slippage, shares_filled, verdict, and for basket: theoretical vs realizable sum, capture_ratio, profit, thin legs, max clean notional, forced directional risk. Complete for complexity.

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

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

Schema coverage 100% with descriptions. Description adds context: default side for basket is auto (based on partition sum), size_usd interpretation for basket (settlement notional), and clamp range 10-1,000,000. Adds value beyond schema.

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

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

Description clearly states 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It explains single-market and basket modes, distinguishes from siblings like polymarket_arbitrage and polymarket_edges by naming them as consumers of this check.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Explains why: theoretical overround on thin books not capturable and partial fills cause directional risk.

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

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

Even with readOnly/idempotent annotations, the description adds substantial behavioral disclosure: compatibility warnings can be non-empty even when pairs are returned, unknown legs are never paired, temporal_alignment null semantics are defined, and all spreads are gross because Kalshi fees are not modeled. This goes far 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 long and dense, but internal headings and code-formatted tokens make it navigable, and nearly every sentence carries a domain-specific caveat. It is slightly repetitive around temporal alignment and the pre-mapped ≠ tradeable warning, so it earns a 4 rather than 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 tool with no output schema, this description is nearly complete: it covers response shape, safety fields, compatibility codes, skipped/unclassified leg behavior, fee handling, and temporal alignment semantics. An agent has enough information to call the tool correctly and interpret unusual or warning-laden results.

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

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

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds genuine value by explaining the two modes, the override relationship between explicit parameters and topic mappings, and the fact that both modes run the identical token-overlap matcher.

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 the exact function: calculating a cross-venue spread between Kalshi and Polymarket for the same resolving question, with direction Kalshi − Polymarket. It separates this tool from generic research siblings by naming both venues, the matching mechanism, and the two input modes.

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 clearly explains when to use topic-mode shortcuts versus explicit custom ticker/slug pairings, and warns that pre-mapped topics are not automatically tradeable. It does not name sibling alternatives such as polymarket_arbitrage, but the tool's usage context is otherwise unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds scoping to identifier (anonymous IP, BYO key hash, account ID) and the list-all behavior when key omitted. 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 sentences: first gives core function, second provides use cases, third explains scoping and pairing. No redundant text, front-loaded, every sentence serves a 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?

Given simple one-param optional tool with rich annotations, description fully covers purpose, usage, scoping, and relationships. No missing elements for effective 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 covers the single optional parameter with description 'Memory key to retrieve (omit to list all keys)'. Description reiterates that but adds no new semantic detail beyond what schema already provides. Baseline 3 for 100% coverage.

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

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

Clearly states it retrieves a value saved via remember or lists all keys. Distinguishes from siblings like remember and forget by explicitly pairing with them and stating opposite actions.

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

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

Provides explicit when-to-use examples (look up stored context) and mentions pairing with remember/forget. Advises omitting key to list all, giving concrete usage pattern.

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 a safe, read-only, idempotent operation. The description adds significant behavioral context: it specifies that each alert carries source, citation_uri, and raw event payload, explains the effect of mark_read (flagging as read), and confirms polling is safe. No contradictions with annotations.

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

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

The description is a compact paragraph of 4-5 sentences. It front-loads the core purpose, then efficiently covers return values, filters, mark_read behavior, and polling advice. Every sentence adds value without redundancy.

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

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

Despite having no output schema, the description details key return fields (source, citation_uri, raw event payload). It explains the effects of optional parameters and confirms polling safety. For a tool with moderate complexity and no required parameters, this is fully adequate and leaves no important 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 extra context beyond the schema, particularly for the mark_read parameter, by explaining its side effect of making subsequent calls return only newer events. This deeper explanation aids understanding.

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

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

The first sentence clearly states the verb ('Pull') and resource ('fired events from your subscription feed'). It implies the tool retrieves recent alerts. However, among many sibling tools, there is no explicit differentiation from similar tools like 'recent_changes' or 'subscribe', which would help an agent choose this tool over others.

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 notes that polling is acceptable and provides an alternative REST endpoint for scripts/dashboards, giving useful context for when to use this tool vs. another access method. It does not explicitly state when not to use it or contrast with sibling tools, but the provided context is sufficient for an agent to decide.

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 safe, idempotent read behavior. The description adds significant behavioral context: parallel fan-out, GDELT→GNews fallback, USPTO soft-fail, relative date shorthand, and return structure. No contradictions.

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

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

The description is a single paragraph but packs essential information efficiently. Minor improvement could be structuring with bullet points, but no redundancy.

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

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

Given the complexity (multiple sources, fallback, window handling) and no output schema, the description covers return structure, source grouping, and citation URIs, making it complete for agent invocation.

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

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

Schema coverage is 100% with parameter descriptions. The description enhances by explaining `since` relative shorthand and `value` accepting ticker or CIK, adding value beyond schema.

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

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

The description clearly states the tool provides a change feed for a company over a time window, listing specific sources (SEC EDGAR, GDELT→GNews, USPTO) and distinguishes from sibling `entity_profile` which offers a static profile.

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

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

The description includes explicit natural language query examples and directs users to `entity_profile` for static profile needs, providing clear when-to-use and when-not-to-use guidance.

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

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

Discloses scoping by identifier, 24-hour retention for anonymous sessions, and persistence for authenticated users. Annotations (idempotentHint=true, destructiveHint=false) are consistent. 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?

Three sentences, each earning its place: purpose, usage condition, storage details. No fluff or repetition. Front-loaded with the key action verb 'Save'.

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 2-param tool with no output schema and rich annotations, the description covers all essential aspects: what, when, how stored, and lifecycle. No gaps.

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

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

Schema coverage is 100% with clear parameter descriptions (key naming convention, value as text). The description adds 'key-value pair' context but offers minimal additional semantics beyond the schema. Baseline score applies.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later.' It includes specific examples (resolved ticker, target address, etc.) and distinguishes itself from sibling tools like recall and forget.

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

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

Explicit guidance on when to use ('when you discover something worth carrying forward') and pairing with recall/forget. Context signals show 2 siblings are directly related (recall, forget), making differentiation 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 establish read-only, open-world, idempotent, non-destructive behavior. The description goes well beyond that by disclosing graceful degradation of LEI/FIGI enrichment, the cascading internal lookups, the explicit `unresolved` field behavior, source labeling, and the `figi_candidates` ambiguity handling. This gives an agent realistic expectations for fallback behavior.

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

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

The description is long, but nearly every sentence carries operational detail: examples, successor guidance, supported types, edge-case behavior, and fallback semantics. It is front-loaded with the usage trigger. The density is high enough that it is slightly overwhelming, but no part is filler.

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

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

For a tool with no output schema, the description explains the return contract well: identifiers, source labels, unresolved entries, candidate lists for ambiguity, and degraded modes. It also covers all input forms and entity domains. Nothing critical to selecting or invoking the tool correctly appears 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%, and the description still adds substantial meaning beyond it: exact input examples for ticker/CIK/ISIN/name, drug brand/generic examples, the instruction to pass only the entity name, and the bond-specific caveat about trailing security-class words. This materially reduces misparameterization.

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-phrase examples and a precise verb: 'resolve a user-spoken NAME to the canonical/official identifiers.' It clearly distinguishes itself from siblings like entity_profile or compare_entities by framing itself as the identity-resolution front door, and it enumerates exactly which entity types it covers.

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 guidance: 'Use FIRST whenever you have a name but need an ID,' and it specifies supported types (company, drug) and acceptable inputs. It does not name sibling tools as alternatives or state when not to use it, but the examples and supported-type list make the intended invocation context 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it probes each entity with ai_visibility_check, ranks by score, and surfaces most/least recognized. It also notes the optional API key requirement for anthropic model. 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?

Two efficient sentences that front-load the core action ('Compare AI visibility across multiple entities side-by-side') and immediately follow with detail. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description clearly states the return format ('ranked list with score, confidence, signal density per entity'). Given the tool's moderate complexity (4 params, all described in schema) and the descriptive output summary, the description is complete for an agent to understand what the tool does and what it returns.

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

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

Schema description coverage is 100% so baseline is 3. The description adds extra semantics: entity[0] is treated as 'subject' for narrative, context disambiguates common names, and models array has default behavior. This elevates the score above baseline.

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

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

The description uses specific verbs ('Compare', 'Probes', 'ranks', 'surfaces') and clearly identifies the resource (AI visibility across multiple entities). It distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic) by emphasizing competitive side-by-side comparison.

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

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

The description explicitly frames usage for competitive AI-marketing audits and gives a concrete example question. It implies when to use (side-by-side comparison) but does not explicitly state when not to use or list alternatives, though the context of 'your brand + N competitors' provides clear applicability.

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 and idempotentHint. Description adds that partial failures degrade gracefully, bundlephobia first measurement may take 5-30s, and sources_failed will list timeouts. This is useful 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?

Description is detailed but every sentence adds value: composite nature, sources, use cases, ecosystem info, partial failure handling. Slightly long but not wasteful. Could be more structured (e.g., bullet points) but still effective.

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

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

For a read-only composite tool with no output schema, the description thoroughly explains return fields (summary block, per-advisory, links, alternatives) and behavior (partial failures). Completely prepares the agent 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?

Schema covers both parameters with descriptions (100% coverage). Description adds that scoped packages ('@types/node') are accepted for 'package', and 'version' defaults to latest published when omitted. Provides extra context beyond schema.

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

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

Description clearly states it's a composite check for npm package evaluation, covering license, advisories, version history, and bundle size. It distinguishes from sibling tools which are unrelated (e.g., AI agents, polymarket). Verb 'scan' + resource 'dependency' is specific.

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

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

Explicitly states when to use: when agent asks 'is X safe/popular/small' or 'what does adding lodash cost me'. Also notes ecosystem limitations (NPM only in v1) and alternative (deps.dev:version for other ecosystems).

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, etc.), the description adds that the tool is keyless and returns specific fields (tsn, author, kingdom). 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 three sentences, front-loading the core purpose, followed by return fields and usage tip. Every sentence adds value with no wasted words.

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

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

Given the simple single-parameter tool, no output schema, and comprehensive annotations, the description fully covers what the tool does, what it returns, and how to use the result with other 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?

With 100% schema coverage, the description repeats the parameter's purpose but adds no new semantic detail. The example in the schema already illustrates usage, so the description does not significantly enhance parameter 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 searches ITIS by scientific name and resolves to TSNs, listing return fields. It distinguishes from sibling tools like get_hierarchy and get_common_names by suggesting their use after retrieval.

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 notes the tool is keyless and suggests using the result with get_hierarchy or get_common_names. However, it does not specify when not to use it or alternatives for non-taxonomic 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 (readOnlyHint, idempotentHint, etc.) are already clear, but the description adds significant extra behavioral details: uses BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K character cap with truncation and flagging. 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?

Two clear sentences plus a technical note. Front-loaded with purpose and key use case. No wasted words; every sentence adds value.

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

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

For a read-only, idempotent semantic search tool with no output schema, the description adequately describes return values (top-N passages with offsets and similarity scores), constraints (200K char limit), and pairing instructions. Complements annotations well.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds contextual meaning (e.g., 'text' is 'document text', 'query' is 'natural-language'), but does not provide syntax or format details beyond the schema. Adequate given coverage.

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

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

The description clearly states it performs semantic search inside a fetched record, using a specific verb ('search within') and resource ('source'). It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded and the use case for large records.

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 tells when to use it ('when the record is too big to cram into the prompt') and what it pairs with (ask_pipeworx_grounded). It implies when not to use (small records), but does not explicitly list alternatives.

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

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

Annotations indicate idempotent and non-destructive behavior. The description adds that it creates a subscription, requires OAuth, and includes rate limits (10 SMS/day). No contradictions found.

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

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

The description is well-structured with the main purpose first, then types, then delivery. It is somewhat lengthy but each part adds necessary detail. A minor improvement could be even more concise phrasing.

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

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

Despite no output schema, the description explains the return (subscription ID) and covers all aspects: types, parameters, delivery, constraints, and how to pull alerts. It is thoroughly complete for this 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 has 100% coverage, and the description enriches it with detailed examples for each type and delivery option, including parameter constraints and behavior (e.g., webhook signing secret returned once).

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

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

The description clearly states the tool creates a proactive monitoring subscription and returns a subscription ID. It specifies the resource (live-data event stream) and distinguishes itself from sibling tools like list_subscriptions and unsubscribe.

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

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

The description provides explicit usage context: requires Pipeworx OAuth account, lists supported subscription types with examples, and explains delivery channels. It does not explicitly state when to avoid using this tool, but the context is sufficient.

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

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

Beyond annotations (readOnly, idempotent), description adds context that it returns live example questions from a catalog and can be focused via topic. No contradictions with annotations; describes non-destructive, safe behavior.

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

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

Well-structured with front-loaded alternative queries and clear explanation, but slightly verbose with extensive list of categories. Still effective and concise enough.

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

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

Despite no output schema, description fully explains return format (category-bucketed examples with tool+argument shapes). Covers no-arg and with-arg usage, making it complete for onboarding.

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?

Single optional parameter has 100% schema coverage. Description adds examples of valid topic values and explains that omitting gives a cross-category spread, which is more helpful than the schema alone.

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

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

The description clearly states the tool returns category-bucketed example questions and positions it as the onboarding entry point. It distinguishes from sibling tools like ask_pipeworx and discover_tools by emphasizing 'what can I ask' and learning capabilities.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains when to omit or include the topic parameter. Provides clear context for when to use this tool versus others.

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

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

Goes beyond annotations by detailing ownership enforcement and deactivation (not deletion), ensuring historical events remain via recent_alerts. 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?

Two sentences, front-loads purpose, no unnecessary words. Efficient and clear.

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

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

Covers all essential aspects: purpose, ownership, effect on data. No output schema, but return value could be implied. Slightly incomplete but sufficient for simple tool.

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

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

Schema coverage is 100% and description for param 'id' already says it's from subscribe. Description adds no new semantic detail, so baseline 3.

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 cancels a subscription by id, with ownership enforcement and deactivation vs deletion. Distinguishes from sibling tools like subscribe and list_subscriptions.

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

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

Explicitly says only own subscriptions can be canceled, implying context. Could be stronger by explicitly stating when to use, but adequate given sibling tool names.

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 behaviors, so the description adds significant context beyond that: the dual-path routing (SEC EDGAR vs. grounded pipeline), the specific verdict output set, citation requirement, and the crucial caller-facing note distinguishing 'could_not_verify' from 'unsupported' and clarifying that it must not be interpreted as evidence. This is rich, behavior-revealing information.

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 concrete user-phrase examples and a direct usage statement. Although lengthy, every sentence earns its place: two routing paths, output specification, and a clearly structured 'IMPORTANT' caveat. Formatting aids readability without fluff.

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

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

For a two-parameter tool with no output schema, the description is exceptionally complete. It covers input phrasing, routing logic, return value (verdict + value + citation + reasoning), and critical edge-case semantics for 'could_not_verify' and 'unsupported'. The added note about replacing multiple sequential calls contextualizes its role. No operational gaps remain.

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

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

Schema description coverage is 100%, with both 'claim' and 'tolerance_pct' already fully described. The description reinforces the tolerance semantics ('exact percent-delta math', 'capped at 5') but does not add meaning beyond the schema. Baseline 3 is appropriate when the schema carries the parameter detail.

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

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

The description clearly states the tool's purpose with a specific verb and resource: natural-language claim verification against authoritative sources. It distinguishes this tool from siblings by framing it as the designated fact-checking tool for both company-financial claims (via SEC EDGAR/XBRL) and any other factual claims, with examples of user phrasing.

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 whenever the agent needs to check whether something a user said is factually correct,' providing direct guidance. It also differentiates when to use the financial fast path vs. the general grounded pipeline. However, it does not explicitly name sibling alternatives or state when NOT to use the tool, so it stops short of a full with/without comparison.

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