Take The Meeting

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

Annotations already indicate safe, non-destructive, and idempotent behavior. Description adds valuable beyond annotations: default model (Workers AI Llama-3.3-70b), optional Anthropic probe with BYO key, and return structure (per-model {score, confidence, signals, raw_response} + combined view). No contradictions.

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

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

Two sentences that efficiently convey purpose, default behavior, optional key usage, and return format. No wasted words. Front-loaded with main functionality.

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

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

No output schema, but description succinctly describes return fields. Parameter count is 4 with no nested objects, so the description is adequate. Could mention asymptotic behavior or limits, but not critical for functional understanding.

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% (4 parameters fully described). Description adds meaning: explains default model, clarifies _apiKey is only needed for Anthropic, and highlights context field for disambiguation. This provides useful nuance beyond raw schema.

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

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

Description clearly states the tool probes LLMs for knowledge about a business/brand/product/topic and returns a visibility score. The verb 'probe' and resource 'LLMs' are specific. Distinguished from siblings by focusing on AI visibility scoring rather than general factoid queries or research.

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

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

Provides explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' However, it does not mention when not to use or directly compare to siblings like scan_competitor_ai_presence, so slightly lacking in exclusion 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 cover read-only, open-world, and idempotent behavior. The description adds valuable mechanism-level context: it routes to one of 5,767 tools across 1,506 sources, auto-fills arguments, and returns stable pipeworx:// citation URIs. It does not discuss latency, failure modes, or coverage limits, but given annotation coverage this is still strong behavioral disclosure.

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

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

The opening is strong and front-loaded with a clear imperative, and the examples are useful. However, the description repeats 'even if web search could also answer it' and ends with a truncated routing instruction ('For ... use ask_pipeworx_grounded'), which makes the structure feel less polished and slightly fragmented.

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?

Although there is no output schema, the description tells the agent what to expect: a structured answer with stable pipeworx:// citation URIs. It covers broad domains, trigger phrases, examples, and sibling-tool routing. The main gap is that the condition for ask_pipeworx_grounded is incomplete, leaving one alternative under-specified.

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

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

All six parameters are aliases for the same natural-language question and schema coverage is 100%, so the input schema already fully documents the parameter. The description provides helpful example queries and trigger phrases, but it does not add substantive meaning beyond the schema's own description and examples. A baseline of 3 is appropriate.

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

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

The description clearly states what the tool does: it routes factual questions to the right tool among 5,767 options across verified sources and returns a structured answer with stable pipeworx:// citation URIs. It explicitly positions itself as preferred over web search and gives concrete domain examples, which distinguishes it from broader search or research siblings.

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', trigger phrases like 'what is', 'look up', 'find', and examples such as 'current US unemployment rate'. It also names alternatives: ask_pipeworx_grounded for grounded answers and deep_research for broad multi-part questions, plus notes that breaking-news queries route to 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 cover read-only, open-world, idempotent, and non-destructive hints. The description adds valuable behavioral context: it is a live beta, candidate improvements may be active, nothing is active right now, and it is a full working router with no fallback. This goes well beyond the annotations without contradicting them.

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

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

The description is four sentences and reasonably compact. It front-loads the identity and relationship to ask_pipeworx, then covers current state, usage, and no-fallback behavior. There is slight redundancy between 'identical' and 'currently matches ask_pipeworx exactly,' but it is not bloated.

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 alias-based tool with one required concept and full schema coverage, the description covers what it is, when to use it, its current state, and its relationship to the stable router. It is complete enough for an agent to safely select and invoke it, though more detail about what 'routing' produces would help.

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 all six parameters described as aliases for 'question'. The description adds only that the arguments are the same as ask_pipeworx, which is marginally useful but not parameter-specific. The schema is doing the heavy lifting here.

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

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

The description states this is a beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape. It differentiates itself from the stable sibling by being the experimental edge with candidate routing improvements. The purpose is clear, though it relies on the reader knowing what ask_pipeworx is.

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

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

It explicitly says to use it exactly like ask_pipeworx when you want the newest routing, and mentions results are compared against the stable router. This gives a clear usage condition, though it does not spell out an explicit 'use the stable version when you need proven behavior' exclusion.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, but the description adds significant behavioral context: it only extracts from tool result content, returns verbatim evidence and confidence, can refuse with specific refusal_reason values, and costs an extra LLM call. This goes well beyond the annotations and no contradiction exists.

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

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

The description is dense but every sentence earns its place: purpose is front-loaded, then the exact output and refusal contract, then usage guidance and cost comparison. There is no filler or repetition of schema 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?

Despite having no output schema, the description fully specifies the success return shape and all refusal_reason values, plus evidence behavior and cost implications. Combined with the complete input schema and annotations, an agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema fully documents the question parameter and its aliases. The description does not add parameter-level detail, but it does not need to; baseline 3 is appropriate since the schema carries the parameter semantics.

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

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

The description states a specific purpose: a hallucination-resistant answer mode for high-stakes reads, with exact behavior (extracts answers using only tool results) and explicit differentiation from ask_pipeworx. It identifies the resource and the distinctive grounded extraction mode, so an agent can distinguish it from siblings.

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

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

The description explicitly says when to use this tool ('whenever an answer will be quoted, cited, or acted on... must not invent facts'), when not to prefer it ('prefer ask_pipeworx for casual lookups'), and names the alternative directly. It also explains the cost tradeoff of one extra LLM call, giving clear routing guidance.

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

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

The description goes far beyond the annotations (readOnlyHint, etc.) by detailing internal behavior: market resolution, classification, parallel fan-out to data packs, response shapes, resolver contract, parent event extraction, news fallback handling, and safety mechanisms. It explains blocking paths and the behavior of closed markets. No contradictions with annotations.

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

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

The description is very long (multiple paragraphs) and includes extensive details, which is informative but not concise. It is front-loaded with a clear first sentence, but the length could be reduced for quicker comprehension. It is adequately structured with sections but verbose.

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 (no output schema, 3 parameters), the description is thorough. It covers all return shapes, edge cases, safety checks, blocking conditions, and even includes resolution-rule risk. The agent has enough information to use the tool 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 description coverage is 100%, so the schema already describes all parameters. The description does not add new semantic information about parameters beyond what the schema provides, though it reinforces the examples for the 'market' parameter. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: research a Polymarket bet by pulling Pipeworx data. It specifies input formats (slug, URL, question text) and output (evidence packet + market-vs-model comparison). The use cases are given explicitly: 'should I bet on X', 'what does the data say about Y', etc. This distinguishes it from sibling tools by being a comprehensive research tool.

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

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

The description provides clear context for when to use (researching bets for edge detection) and includes safety warnings about inspecting market_match_confidence and cancellation rules before acting. It mentions blocking conditions like low_confidence_match and market_closed_or_inactive. However, it does not explicitly state when not to use the tool or mention alternatives among sibling tools, though the use cases are well-defined.

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. The description adds significant behavioral detail: for companies it pulls latest 10-K financials with correct fiscal-year handling; for drugs it pulls FAERS counts, FDA approvals, trial counts. It notes results are sorted by primary metric and returns paired data with citation URIs. No contradictions.

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

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

The description is comprehensive but slightly long. However, it is front-loaded with common natural-language triggers and every sentence provides unique value. Could be trimmed slightly but remains 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?

The tool is moderately complex (2 entity types, multiple data sources, sorting, citation URIs). The description covers the core functionality, input examples, output structure, and when to use. It does not detail error cases or edge limitations, but given the clear schema and annotations, this is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the enum labels: for 'type' it explains what data each enum value retrieves; for 'values' it gives concrete examples for both company (tickers/CIKs) and drug (names) and confirms min/max counts. This adds real-world context.

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

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

The description clearly states the action (side-by-side comparison) and the resources (companies or drugs). It distinguishes from sibling tools like entity_profile by emphasizing it replaces 8–15 sequential lookups and always prefers this tool over sequential single-pack lookups.

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

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

Explicitly provides natural language triggers ('Compare X and Y', 'X vs Y', 'which is bigger', 'rank these companies', 'head to head') and states 'ALWAYS PREFER over sequential single-pack lookups'. It also explains the entity types and what data each pulls, giving clear guidance on 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 already mark the tool read-only, open-world, and idempotent. The description adds valuable non-obvious behavior: account gating and paid tier requirements, 15–90s latency, gap recovery, contradictions[], and the guarantee that findings are never invented. It also explains the semantics of citations and semantic excerpting, which go well beyond the annotations.

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

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

The description is long but dense; nearly every sentence carries operational value, including preconditions, alternatives, output format, and latency. However, it is not cleanly sectioned, and depth details appear in the middle, so an agent scanning quickly might miss constraints like the paid requirement for thorough.

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

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

With no output schema, the description thoroughly covers return values: verbatim evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], and hop. It also covers prerequisites, alternatives, latency, and scale, making it self-sufficient for a complex tool.

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

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

Schema coverage is 100%, so a baseline of 3 is warranted. The description adds meaning to the question parameter by noting that broad/multi-part questions are fine and decomposition is the point, and it reinforces depth's hop behavior. Since the schema already describes both parameters in detail, the marginal value is modest but still present.

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

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

The description states a specific verb and resource: it researches broad/multi-part questions across structured data sources and returns a findings packet. It explicitly distinguishes this from open-web search and names sibling ask_pipeworx as the alternative for single lookups, giving the tool a distinct identity.

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 it (broad/multi-part questions over structured data) and when not (single lookups should use ask_pipeworx; if not signed in, use ask_pipeworx). It also gives guidance on depth selection, with quick/standard/thorough described in terms of hops and gap recovery, so an agent can route correctly.

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

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

Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns top-N tools with full schemas and examples, ready to call directly, which is useful behavioral context beyond annotations.

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

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

Concise and front-loaded with purpose. Uses bullet-like listing of domains efficiently. Could be slightly tighter but overall good structure.

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

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

No output schema, but description clearly explains what is returned (tool names, descriptions, schemas with examples). For a search/discovery tool, this is complete enough given 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%, so baseline is 3. Description mentions result format but adds minimal parameter-specific meaning beyond the schema. Aliases are already in schema.

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

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

The description clearly states the tool finds tools by describing data or task, listing many domains. It uses specific verb 'find' and resource 'tools', distinguishing it from sibling tools which are more specific (e.g., deep_research, entity_profile).

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

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

Explicitly says 'Call this FIRST when you have many tools available' and to see the option set, giving clear context. Does not mention exclusions or alternatives, but the guidance is strong for 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 already provide readOnly, openWorld, idempotent, and non-destructive hints, but the description adds substantial behavioral detail: USPTO PatentsView soft-fails after sunset, empty fda_products can be expected for non-biologic companies, sources_used/sources_failed distinguish real 'no data' from bugs, and names resolve via SEC EDGAR. This goes far beyond what annotations alone convey.

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

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

The description is long but every sentence earns its place: trigger examples, routing instruction, source list, return-field expectations, failure semantics, and input edge cases. It is front-loaded with the most critical routing information before enumerating details, and the structure is logically organized.

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 must explain return values and edge behavior itself; it does so thoroughly, covering each data source, the composition of the return object, sources_used/sources_failed, and private-company resolution failure. An agent has everything needed to invoke this tool correctly without additional inference.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's parameter-related content mostly restates the schema: both type values behave identically and value can be a ticker, CIK, or company name. It adds examples but no new semantic constraints, so it does not elevate the score above baseline.

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

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

The description opens with concrete user-phrase examples and defines the tool as a 'full cross-source profile of a US public company in ONE parallel call.' It clearly names the resource, verb, and scope, and implicitly differentiates from sibling tools like resolve_entity and compare_entities by emphasizing the holistic multi-source profile behavior.

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

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

It explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' giving a direct decision rule and naming the alternative approach. It also covers the private-company edge case, telling the agent to expect resolved:false with notes rather than a bare failure, which is important routing context.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds behavioral context by stating 'Delete' and implying safety (idempotent deletion by key). 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 sentences with zero waste. The first sentence states purpose, the second provides usage guidance. Fully front-loaded.

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

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

Given low complexity (one required parameter, no output schema, no nested objects), the description fully covers what the tool does and when to use it.

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

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

Schema description coverage is 100% for the single 'key' parameter. The description does not add extra detail beyond 'by key', so baseline 3 applies.

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

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

The description clearly states 'Delete a previously stored memory by key' with a specific verb and resource. It distinguishes from sibling tools 'remember' and 'recall' by name.

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 when to use: 'when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also pairs with remember and recall, though no explicit 'when not to use' is 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 readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. Description adds process details (fetches page, extracts metadata, emits markdown) and output format, which enhance transparency beyond annotations.

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

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

Description is succinct, front-loaded with the main action, and includes a bullet list of use cases. 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?

Given the tool's simplicity (2 params, no output schema), the description effectively explains the process, output, and use cases. It lacks details on error handling or edge cases, but overall is sufficient for agent selection and 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 (url and max_links) with descriptions, achieving 100% coverage. Description does not add extra semantics beyond schema, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool generates a production-ready llms.txt file for a given URL, specifying verb 'generate' and resource 'llms.txt file'. It distinguishes from sibling tools (e.g., ai_visibility_check) by listing specific use cases like drafting llms.txt for projects or auditing competitor AI visibility.

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

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

Description provides explicit use cases (client site indexing, personal project drafting, competitor auditing) helping the agent decide when to use. However, it does not mention when not to use or list alternative tools explicitly, so slightly below a perfect score.

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?

Descriptions adds return fields and optional parameter behavior, complementing annotations (readOnlyHint, idempotentHint). Does not contradict annotations. Minor lack of pagination/limits info but acceptable for simple tool.

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

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

Three concise, front-loaded sentences covering purpose, return fields, and usage recommendation without any 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?

Fully adequate for a simple tool with one optional parameter and no output schema. Lists all returned fields and provides usage guidance.

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

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

Schema covers 100% of parameters with description; description does not add significant meaning beyond stating 'active subscriptions' which aligns with default schema value.

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

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

Clearly states 'List the caller's active subscriptions' with a specific verb and resource. Distinguishes itself from siblings 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?

Explicitly advises when to use: 'review what you're monitoring before adding more or to find an id to cancel.' Provides clear context for invocation.

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 rate limits ('Rate-limited to 5 per identifier per day'), the claim_token flow ('Filing without an account returns a claim_token; pass it back later'), the fact that it is free and doesn't count against tool-call quota, and how the team processes feedback ('reads digests daily and signal directly affects roadmap'). This goes well beyond the sparse annotations (all false) and leaves no ambiguity about side effects or expectations.

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

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

The description is longer than average but every sentence adds critical operational detail (scope, token flow, rate limit, quota). It is front-loaded with purpose and usage, then flows logically into mechanics and constraints. It earns the length, but could be tightened by moving the 'Not sure?' clause earlier—still highly structured.

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

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

For a 4-parameter, no-output-schema tool, the description covers all essential context: what to report, what not to report, scope exclusions, token-based follow-up, team workflow, and rate limits. No output schema exists, but the description explains the claim_token return behavior sufficiently. This is complete enough for an agent to invoke the tool correctly and follow up appropriately.

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 meaningful semantics beyond schema: it explains the claim_token round-trip pattern in detail, instructs on message content ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), and contextualizes the 'type' enum via the usage examples. Slight deduction because it doesn't directly walk through the nested 'context' object, but the schema already covers that.

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

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

The description opens with a clear verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It also lists concrete categories (bug, feature/data_gap, praise) and distinct scope (only for tools served by this Pipeworx connection), which clearly distinguishes it from sibling research/subscription tools.

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

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

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

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

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

Annotations already provide read only, idempotent, non-destructive hints. The description adds valuable context: self-aggregating from CF analytics, no PII, caching behavior (5min-1h), and data structure (pack, tool, count). No contradictions.

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

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

The description is two well-structured paragraphs: first sentence states output, then bullet list of use cases, then technical notes. No fluff, every sentence adds value. Front-loaded with the core 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?

Despite having no output schema, the description explains exactly what is returned (top tools, packs, call volume), caching, and data source. With one optional parameter and no required fields, this is fully complete for an agent to understand the tool's 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% and the schema description already explains the enum values and their interpretation. The tool description does not add additional parameter details beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states it returns top tools, packs, and call volume, using a specific verb ('Returns') and resource. It distinguishes from siblings like discover_tools by emphasizing it shows what other AI agents are calling right now.

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: discovering hot data sources, confirming canonical tool choice, and aligning use cases. It does not explicitly state when not to use or mention alternative tools, which would elevate it to a 5.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description goes far beyond by explaining the internal algorithms (monotonicity, partition-sum checks, Jaccard similarity filter, placeholder filter) and the fill check process. It discloses behavioral traits like response structure and trade signals, adding significant context beyond annotations.

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

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

The description is lengthy (4 paragraphs) but well-structured and front-loaded with the main purpose. It contains dense, valuable information. Some redundancy could be trimmed, but every sentence contributes to explaining the tool's complex behavior.

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

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

Despite no output schema, the description adequately covers return values (opportunities array with fields like gap_pp, suggested_trade, reasoning) and mentions fill check behavior. It provides sufficient completeness for an AI to understand usage and output, though exact field types are not detailed.

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 parameters having clear descriptions. The tool description adds extra semantics (e.g., that event accepts full URLs, topic uses seed questions, and how each mode works), enhancing understanding beyond the schema alone.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. It specifies three modes (no args, event, topic) and what each does. While it doesn't explicitly differentiate from sibling 'polymarket_edges', the purpose is distinct and clearly articulated.

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 for each mode, including recommendations (e.g., 'event (recommended for a specific market)') and explanations of when cross-event mode is beneficial. It also warns when not to trade (realizable_edge_pp <= 0) and references polymarket_fill_risk for custom sizing, offering comprehensive when-to-use and when-not-to-use information.

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

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

The description discloses significant behavioral traits beyond annotations: it explains the three response segments with model details, caching behavior (Cached 1h at the KV level), and the diagnostic section. It does not contradict annotations; all align with readOnlyHint and idempotentHint.

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 verbose but well-structured, with clear segmentation and bullet points. It front-loads the main purpose and uses formatting for readability. While some details could be trimmed, the complexity of the tool justifies the 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?

Despite no output schema, the description thoroughly explains the response structure (by_segment, fed_candidates, _diagnostics) and the meaning of each field. It also covers parameter usage and behavioral notes fully, making the tool complete for an agent.

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

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

With 100% schema coverage, every parameter has a description. The tool description enriches parameter meaning by explaining tradeable-edge knobs (min_liquidity, max_spread_pp) and providing context like slippage_pp defaults and recommendations. This adds significant value beyond the schema alone.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It further specifies its use case as 'what should I bet on today' and distinguishes itself from siblings like 'polymarket_arbitrage' by focusing on disagreement-based edges.

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

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

The description provides extensive usage context, including when to use this tool for opportunity discovery, how to adjust tradeable-edge knobs, and a note on Fed markets being excluded from ranking. However, it does not explicitly name alternatives or state when not to use this tool, so it misses the top score.

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

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

The description adds extensive behavioral context beyond annotations: explains data sources, time-series structure, trend computation, decay handling, and limitations like 60-day TTL and snapshot gaps. No contradictions with annotations.

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

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

The description is front-loaded with purpose and structured with clear sections (args, response format, limits). It is somewhat long but every sentence adds value, making it efficient.

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

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

Despite no output schema, the description fully explains response structure, trend classification, decay formula, and limitations. It covers all necessary information for correct usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minor context (e.g., 'snapshot family' for window) but mostly repeats schema info. Slight discrepancy in max vs. clamp is minor.

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: tracking edge persistence and decay from daily snapshots. It answers specific questions and distinguishes itself from siblings like polymarket_edges by focusing on time-series analysis.

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

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

The description provides clear context on when to use (to differentiate fresh vs. old edges) and implies alternatives by noting limitations like daily close data and history depth. It does not explicitly list when not to use, but the context is sufficient.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds behavioral details: live CLOB check, verdict output, forced directional risk, and effects of partial fills. Does not contradict annotations.

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

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

Description is dense but well-organized with clear sections for single-market and basket modes, and a usage guideline at the end. Every sentence adds value, though length could be slightly reduced with bullets.

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

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

Despite no output schema, description comprehensively explains return values for both modes, covers edge cases (thin legs, directional risk), and provides usage context. Sufficient for an agent to understand and invoke the tool correctly.

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

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

Each of the 4 parameters has schema descriptions (100% coverage). The tool description adds context: required one of market/event, default values, interpretation of size_usd for buys vs sells, and side auto-detection in basket mode. Adds significant value beyond schema.

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

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

Description clearly states the tool performs a realizable-vs-theoretical edge check against live order-book depth. It distinguishes single-market and basket modes, lists specific outputs, and differentiates from sibling tools (polymarket_arbitrage, polymarket_edges).

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why partial fills convert arb into directional position. Provides clear when-to-use and rationale.

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?

This description goes far beyond the annotations, which already mark the tool as read-only, idempotent, and open-world. It exposes the full safety model: compatibility codes, unverified pairing, skipped legs, temporal alignment uncertainty, gross-vs-net fee caveats, and the fact that warnings can be non-empty even when matched_pairs > 0. This is exemplary behavioral disclosure.

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

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

The description is long, but the tool is genuinely complex and the length is largely earned by the dense caveats and return-field explanations. It is front-loaded with the core purpose and modes before diving into safety details. Some repetition and block-cap-heavy presentation could be tightened, but no sentence feels gratuitous.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: venue prices, top_spreads_pp, compatibility fields, skipped categories, low-confidence pairs, temporal alignment, fees, and cross-type/cross-subtype counters. An agent has enough information to correctly invoke the tool and interpret its 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 input schema already documents all three parameters, so the baseline is 3. The description adds real semantic value by explaining that topic auto-fetches a matching event, that the explicit ticker and slug override the topic-mapped sides, and that both modes execute the identical token-overlap matcher with the same disclosures. This meaningfully exceeds schema-only 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 states the tool's core function precisely: computing the cross-venue probability spread between Kalshi and Polymarket for the same resolving question, and it clearly differentiates the two invocation modes. It is unambiguous and rich, though it does not explicitly name a sibling tool it is not, relying instead on the reader to infer the distinction from "not a net tradeable edge."

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

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

The two modes are clearly explained: topic shortcuts for pre-mapped macros and explicit ticker/slug for custom pairings, with the note that both run the same matcher. It also gives important when-not-to-trust guidance ("pre-mapped ≠ tradeable", "most pre-mapped topics return compatibility_warning today"), but it does not explicitly discuss alternatives among sibling tools.

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

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

Adds scoping detail (identifier-based) beyond annotations (readOnlyHint, idempotentHint). Discloses listing behavior when key is omitted. No contradiction with annotations.

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

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

Three sentences, all essential. No fluff. Core action in first sentence, supplementary details follow logically.

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 purpose, usage, scoping, and pairing. Lacks explicit mention of return format, but simplicity of tool and lack of output schema make this acceptable.

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 semantic context about omitting key for listing and gives real-world usage examples. Slightly elevates beyond baseline of 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?

Clearly states it retrieves a value saved via 'remember' or lists all keys. Distinguishes from sibling tools 'remember' and 'forget' 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?

Provides explicit examples of contexts to use (target ticker, address, research notes) and pairs with 'remember' and 'forget' for complementary actions. Implicitly tells when not to use.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, but the description explicitly says setting mark_read:true will mark events as read, indicating a state change. This contradicts the readOnlyHint annotation. The description also mentions mark_read as a parameter but does not resolve the inconsistency.

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 efficient and front-loaded with the core purpose. Each sentence adds meaningful information (e.g., what events carry, filtering options, mark_read behavior, alternative endpoint). It is not overly verbose, but could be slightly tighter.

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

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

Given no output schema, the description tells the agent what fields to expect (source, citation_uri, raw event payload). It explains filtering, mark_read behavior, and even provides an alternative REST endpoint. This is comprehensive for a read-focused 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?

All parameters have schema descriptions, and the tool description adds extra context for 'type' (example value 'sec_8k'), 'since' (ISO timestamp format), and 'mark_read' (explains its effect). The explanation of 'mark_read' and 'since' goes beyond the schema. However, 'limit' and 'unread_only' are not elaborated further.

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 begins with a specific verb and resource: 'Pull fired events from your subscription feed.' It clearly states the tool retrieves recent alerts and explains what each event carries (source, citation_uri, payload). This differentiates it from sibling tools like list_subscriptions.

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

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

The description mentions polling works fine and points to an external alternative endpoint for scripts and dashboards. However, it does not explicitly state when to use this tool versus other PipeWorx tools or 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?

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description discloses parallel fan-out to multiple sources, fallback logic, USPTO API status, and output format (grouped changes, total count, citation URIs). No contradictions with annotations.

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

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

The description is a single paragraph that is slightly long but every sentence adds value. It is front-loaded with examples and well-organized, though minor restructuring could improve scanability.

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

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

Despite lacking an output schema, the description adequately explains the output format and sources. For a tool with 3 parameters and no output schema, the description provides sufficient completeness for agent understanding.

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 value: clarifies `type` as only 'company', provides examples for `since` (ISO date or relative shorthand), and explains `value` as ticker or CIK. Adds monitoring recommendation.

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

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

The description clearly defines the tool as a change feed for a company aggregating SEC filings, news, and patents. It provides example queries and explicitly distinguishes from sibling entity_profile, ensuring the agent can differentiate.

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 usage patterns, fallback behavior (GDELT→GNews), soft-fail for USPTO, and directs to use entity_profile for static profiles. It also advises on typical `since` values like '30d' or '1m'.

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

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

Adds valuable behavioral context beyond annotations: scoping by identifier, persistence details (persistent for authenticated, 24-hour for anonymous). Annotations already show idempotentHint=true and destructiveHint=false, which the description supports.

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?

Extremely concise and well-structured: first sentence states purpose, second gives usage context, third explains behavior. No wasted words, front-loaded with most important information.

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

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

Despite no output schema, the description covers purpose, usage, and behavioral details adequately for a simple store operation. It does not describe return values, but for a save tool this is acceptable. Lacks mention of error cases or overwrite behavior, but still complete enough.

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

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

Schema coverage is 100%, so the description adds marginal extra meaning. It provides example key formats and clarifies that value can be any text, but the schema already conveys this. No new parameter semantics beyond examples.

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'), uses a specific verb ('save') and resource ('data'), and distinguishes from sibling tools like recall and forget by mentioning pairing.

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

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

Explicitly states when to use ('when you discover something worth carrying forward'), provides examples of appropriate data types, and mentions scope differences (authenticated vs anonymous) without contradicting 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?

The annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already establish a safe, read-only operation. The description adds substantial behavioral detail: graceful degradation when GLEIF/OpenFIGI are down, cascade through multiple endpoints, labeling of identifier sources, explicit `unresolved` field for failures, ambiguity handling via `figi_candidates`, and the ISIN-to-LEI mapping for non-US issuers. This goes far beyond the annotations.

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

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

The description is long but every sentence adds value—examples, usage directive, supported types, behavioral caveats, and parameter nuance. It is front-loaded with the purpose and 'Use FIRST' guidance, then systematically covers company details and drug details. While it could be tightened, the structure is logical and the verbosity is justified given the tool's complexity.

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

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

For a tool with two entity types, multiple data sources, ambiguity handling, and no output schema, the description covers the key contextual points: input formats, source fallback, unresolved identifier disclosure, and the exact matching behavior for bonds. It also explains the ISIN-to-LEI path, which is a non-obvious use case. Nothing an agent needs to call it 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 both parameters have descriptions. The description enriches the 'value' parameter significantly with critical guidance: for bonds, pass the exact issuer name as printed, never the full noun phrase, because trailing security-class words match nothing. It also explains the accepted input formats for company (ticker, CIK, name) and drug (brand or generic). This is essential meaning not present in the schema.

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

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

The description clearly states the tool resolves user-spoken names into canonical/official identifiers, listing specific examples ('ticker for…', 'CIK for…'), and explicitly differentiates it from siblings by saying 'Use FIRST whenever you have a name but need an ID'. It covers multiple entity types and explains its cross-source nature, making the purpose unambiguous and distinct.

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

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

The description gives a strong directive: 'Use FIRST whenever you have a name but need an ID' and explains when it applies for company and drug resolution. It also clarifies that it replaces 2-3 manual lookups. However, it does not explicitly mention when NOT to use it or name alternative tools (e.g., if you already have an ID, use entity_profile) beyond implying it's the first stop. This is a minor gap, but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint as true. The description adds critical context: internal use of ai_visibility_check, ranking logic, return fields (score, confidence, signal density), and narrative treatment of first entity. No contradiction with annotations.

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

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

Three sentences, each packed with information: purpose, mechanism, use case, and return details. Front-loaded with the core action. No filler or repetition.

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

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

Despite lacking an output schema, the description explains the return format (ranked list with score, confidence, signal density). It covers the workflow and dependencies. Minor gaps like error handling or size limits are already addressed in the schema.

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

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

Schema coverage is 100% so baseline 3. Description adds value beyond schema: clarifies that the first entity in 'entities' is the 'subject' for narrative, and provides real-world examples for 'context' parameter. This extra detail informs proper usage.

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 clarifies the resource ('AI visibility across multiple entities'). It distinguishes from siblings by explicitly referencing ai_visibility_check and comparing multiple entities, contrasting with single-entity tools like ai_visibility_check itself.

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

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

The description provides a concrete use case ('competitive AI-marketing audits') and implies when to use the tool. It hints at alternatives by mentioning it uses ai_visibility_check, but does not explicitly state exclusions or when to opt for a different tool.

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

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

Annotations already declare safe, open-world, idempotent, and non-destructive behavior. The description adds valuable context about partial failures, timeout for bundlephobia's first measurement, and graceful degradation, which exceeds annotation coverage.

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

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

The description is front-loaded with the core purpose and structured logically, covering summary, usage, and edge cases without unnecessary verbosity. 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 lacking an output schema, the description lists all return fields and explains ecosystem limitations, fallback, and error handling. It is complete given 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%, so the schema already documents both parameters. The description adds operational context (e.g., scoped packages accepted, default to latest version), which provides additional 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 defines the tool as a composite check for evaluating npm packages, covering license, advisories, version history, and bundle size. It distinguishes itself from siblings by specifying the NPM ecosystem and referencing fallback methods.

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

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

Explicitly states when to use the tool (e.g., 'is X safe/popular/small') and provides context for when not to use it, noting that PyPI/Maven fall under a different endpoint. This guides the agent effectively.

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 embedding model (BGE-base-en), similarity metric (cosine), windowing (500-char overlapping), and character limit (200K with truncation flag). These go beyond the annotations which only state readOnly, openWorld, idempotent, not destructive.

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?

Concise at ~100 words, front-loaded with purpose, followed by usage guidance, then technical details. Every sentence serves a purpose 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 explains return values (passages with offsets and scores), error handling (truncation flag), and tool relationships. Complete for a retrieval 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%, so baseline is 3. The description adds value by giving natural-language query examples and reinforcing the text limit, but doesn't introduce critical new parameter info. A 4 reflects the slight improvement over baseline.

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

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

The description clearly states it performs semantic search inside a fetched record, with specific examples and contrast to sibling tools like ask_pipeworx_grounded. It uses a strong verb-resource pair and clarifies the scope.

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

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

Explicitly states when to use ('record too big to cram into the prompt') and mentions an alternative pairing (ask_pipeworx_grounded). Provides clear context for when this 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 indicate write, idempotent, non-destructive. Description adds: returns subscription id, account requirement, delivery details (webhook signing secret, auto-disable after 10 failures). No contradiction. Mentions rate limit for SMS but not idempotency explicitly.

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

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

Long but efficient, front-loaded with main purpose. Each sentence adds value. Could be slightly tighter, 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?

Covers multiple subscription types, delivery channels, auth requirements, and references related endpoints. No output schema but mentions return value. Feels complete for agent use.

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

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

Schema coverage is 100%, so baseline 3. Description adds significant value by explaining type-specific params (e.g., sec_8k item codes, webhook signature) and delivery options beyond schema descriptions.

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

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

The description clearly specifies the action ('Create a proactive monitoring subscription') and the resource ('live-data event stream'). It distinguishes from siblings like 'list_subscriptions' and 'unsubscribe' by focusing on creation and monitoring.

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 detailed context: requires Pipeworx OAuth account, lists supported types with examples, and explains delivery channels with constraints. Lacks explicit 'when not to use', but the specificity makes usage 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, idempotentHint, and destructiveHint false. The description adds valuable context: the output is category-bucketed example questions from a live catalog, and it's the onboarding entry point. This complements the annotations without contradiction.

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

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

The description is fairly long but well-organized, front-loading the core purpose and usage. Each sentence adds value, though it could be slightly more concise. The structure is clear with examples and usage instructions.

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 format (category-bucketed example questions with tool/argument shapes). It covers the single parameter, usage scenarios, and fits the tool's role as an onboarding entry point. Complete for its purpose.

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 optional parameter 'topic' has schema description (100% coverage). The description explains valid values like 'finance' or 'pharma' and says 'Omit for a cross-category spread,' adding 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 the tool's purpose: it returns category-bucketed example questions and the exact tool/argument shapes. It specifies it's an onboarding entry point, distinguishing it from related tools like 'ask_pipeworx' or 'discover_tools'. The verb 'suggest' and resource 'questions' are well-defined.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and provides when to omit or pass the 'topic' argument. It also mentions learning meta-tools, giving clear context on when to use this tool vs 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 indicate read-only, non-destructive, idempotent behavior. The description adds useful context: heavy bias toward no and output includes a decline template. No contradiction.

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

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

Two efficient sentences with no filler. First sentence states purpose; second adds key behavioral and output details. Front-loaded and complete.

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 output schema exists and all parameters are optional, the description adequately covers purpose and output, though it could hint at defaults. Overall sufficient for agents with access to output schema.

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

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

Schema covers all 5 parameters with 100% description coverage. The description does not add new parameter-level meaning but connects parameters to the overall evaluation logic. Baseline 3 is appropriate.

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

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

The description clearly states the tool evaluates meeting worth based on parameters, specifies bias toward no, and lists return values. It is distinct from sibling tools, none of which perform meeting evaluation.

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 purpose is clear, but the description does not explicitly state when not to use the tool or mention alternatives. However, given the unique function among siblings, 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?

Description adds key context beyond annotations: row is deactivated not deleted, preserving history via recent_alerts. Also notes ownership enforcement. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).

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

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

Two sentences, front-loaded with action and then behavioral detail. No unnecessary words.

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

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

Tool is simple with one parameter and no output schema. Description covers purpose, ownership constraint, and side effects (deactivation). Annotations cover safety. Complete for effective usage.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minimal extra meaning: 'by id' and clarifies it's the subscription id returned by subscribe, which is helpful but not extensive.

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 'Cancel a subscription by id', using specific verb and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by specifying the action is cancellation.

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 ownership enforcement ('you can only cancel your own subscriptions'), guiding when the tool is applicable. Implicitly suggests when not to use (for others' subscriptions), but does not name alternative tools directly.

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 the description does not contradict them. It adds valuable behavioral detail: verdict taxonomy, the distinction between could_not_verify (check did not happen) and unsupported (no source), citation behavior, and the error payload. This goes well beyond the annotations.

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

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

The description is long but every sentence earns its place. It opens with search-like examples, then states the trigger condition, explains the two routing paths, lists the verdict output, and ends with an important caveat and the efficiency benefit. No filler or redundancy.

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

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

Despite no output schema, the description fully explains what the tool returns (verdicts, value with citation, reasoning) and clarifies ambiguous verdict states. It also covers the underlying routing and the error case, making the tool self-sufficient for an agent.

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

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

Schema covers both parameters, but the description adds meaningful usage guidance: it explains tolerance_pct overrides the implied tolerance, suggests setting 1–2 for hallucination detection, and clarifies the default (capped at 5). This is exactly the extra semantic value expected.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with concrete example queries. It distinguishes itself from sibling search/ask tools by stating it replaces a 4-6 step pipeline and returns a verdict, making the purpose unmistakable.

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

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

Explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the division of labor: company-financial claims use the SEC EDGAR path, all other claims fall through to a grounded pipeline. This gives clear when-to-use context and implies when not to use (non-claim queries).

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