Stratz

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint as true. The description adds important behavioral details: default model is Workers AI Llama-3.3-70b (free), passing _apiKey enables Anthropic probing (BYO key), and it returns per-model {score, confidence, signals, raw_response} plus 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?

The description is concise (4 sentences) and front-loaded with the primary action ('Probe one or more LLMs...'). Every sentence adds useful information without redundancy.

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

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

Given the lack of an output schema, the description explicitly describes the return format (per-model object with score, confidence, signals, raw_response plus combined view). All parameters are covered, and the use cases are stated. The description feels complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema: it specifies the default model and that it is free, explains that _apiKey is only needed for 'anthropic' model, and clarifies the 'context' parameter disambiguates common names. This adds value.

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

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

The description uses a specific verb ('Probe') and clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100). It distinguishes from siblings by focusing on AI visibility scoring, which is unique among listed sibling tools like ask_pipeworx or bet_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?

The description provides clear use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not explicitly state when not to use or list alternatives, but the context given is sufficient for an agent to understand appropriate scenarios.

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

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

Annotations already cover read-only, non-destructive, idempotent behavior, and the description adds valuable context: it routes to the right tool, fills arguments, and returns stable pipeworx:// citation URIs. This is more than a restatement of safety hints, though it doesn't disclose any potential latency, rate limits, or failure modes.

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 section earns its place: priority guidance, domain list, mechanics, trigger phrases, examples, and sibling routing. The directive 'PREFER OVER WEB SEARCH' is front-loaded, and the examples are compact and diverse.

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 free-text query tool with one required parameter and no output schema, the description is remarkably complete. It explains what kinds of questions are appropriate, how the tool behaves internally, what return format to expect, and when to use alternatives.

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

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

The schema already fully describes the aliases as natural-language question strings, so coverage is high. The description adds value beyond the schema by giving concrete example questions, trigger phrases, and the kinds of domains the parameter should cover, which helps the agent formulate the ask correctly.

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

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

The description states the tool routes a natural-language question to one of 5,738 tools across verified sources and returns a structured answer with citations. It names specific domains and concrete examples, so the agent clearly understands what the tool does and how it differs from a general web search.

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 instructs agents to prefer this tool over web search for factual and current/historical data, enumerates trigger phrases like 'what is', 'look up', and 'get the latest', and provides multiple examples. It also names alternatives: ask_pipeworx_grounded for a single authoritative source, deep_research for broad multi-part questions, and live news routing for breaking news.

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 it read-only, idempotent, open-world, and non-destructive. The description adds valuable context beyond those annotations: experimental candidate routing is enabled live when under test, no candidate is currently active, and results are compared against the stable router to inform merges. This is exactly the kind of behavior an agent needs to know before relying on this 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?

The description is front-loaded with the most important identity information and every sentence carries useful guidance. The parenthetical retirement date and the explicit no-fallback statement are helpful, but the date is more detail than an agent strictly needs to select and invoke the tool.

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

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

For a universal router with no output schema, the description covers identity, current state, usage, experimental risk, and no-fallback behavior well. It relies on ask_pipeworx's definition for the exact response shape, which is reasonable given the sibling is visible, but a fully standalone description would need to say a bit more about what kind of answers it returns.

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

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

Schema description coverage is 100%, so the question parameter and its aliases are already documented structurally. The description only says 'same arguments' as ask_pipeworx, which adds no new meaning beyond the schema; therefore the baseline of 3 is appropriate.

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

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

The description clearly identifies this as the beta/experimental version of ask_pipeworx and explains that it is an identical universal router over the same 5,738 tools with the same arguments and response shape. It distinguishes itself from the stable sibling ask_pipeworx without merely restating the title.

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

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

The description explicitly says to use it exactly like ask_pipeworx when the newest routing is desired, and it names the stable router as the comparison point. It also clarifies that this is not a fallback but a full working router, preventing a likely misuse.

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

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

Beyond the read-only/idempotent annotations, the description discloses the extra LLM call, the structured success shape with verbatim evidence, and the named refusal reasons for insufficient data. It also clarifies that answers are grounded strictly in tool results, which is exactly the kind of behavioral context an agent needs.

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

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

Every sentence earns its place: purpose, mechanism, output/refusal contract, usage trigger, and cost trade-off. The most important selection information is front-loaded, and the detail is proportionally distributed.

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 correctly carries the return contract and refusal reasons, while the 100% schema coverage handles parameter semantics. It gives enough context for an agent to decide whether to call it and what to expect from the response.

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

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

The description adds little parameter-specific meaning: it does not discuss grounding_mode, source_filter, max_tool_calls, enable_execution, or timeout_seconds. Schema coverage is 100% with detailed per-parameter descriptions, so the baseline 3 applies rather than a penalty.

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

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

The description opens with a specific purpose: a hallucination-resistant answer mode for high-stakes reads, then explains that it extracts answers only from tool results. This clearly distinguishes it from the sibling ask_pipeworx by emphasizing grounded evidence and explicit refusal rather than a casual lookup.

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

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

It states exactly when to use the tool ('whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts') and when not to use it ('prefer ask_pipeworx for casual lookups') with the cost rationale. This gives an agent explicit positive and negative selection criteria.

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 extensively discloses behavioral traits beyond annotations: fan-out examples (e.g., BTC bet → coingecko + fred + gdelt+gnews), safety behaviors (low-confidence short-circuit, closed market handling), resolution rule risk (cancellation rules), and response shapes (market, analysis, evidence). Annotations already indicate readOnly and idempotent; the description adds critical context for agents.

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, but it is very long and dense. Every sentence adds value, but the structure is a single paragraph without clear sections, making it harder to parse quickly. For a complex tool, this is acceptable but not concise.

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

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

Given the tool's complexity (3 parameters, no output schema), the description is remarkably complete. It covers input formats, fan-out behavior per category, response structure (including resolver confidence, parent events, news fields), safety mechanics, and cancellation rules. An agent can reliably invoke the tool without guessing.

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

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

Input schema coverage is 100%, so baseline is 3. The description adds significant meaning: explains that 'market' accepts slug, URL, or question text; details 'depth' (quick vs thorough) with source counts; and clarifies 'include_raw' for summarized vs full payloads. This goes beyond schema labels.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the verb (research), resource (Polymarket bet), and mechanism (Pipeworx data). The tool is distinct from sibling tools like polymarket_arbitrage or polymarket_edges, which focus on arbitrage or edges, whereas this tool provides comprehensive research via data packs.

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 for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This provides clear context. However, it does not explicitly list when not to use or compare to specific sibling tools, though the use cases are distinctive 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?

Discloses data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and that returns paired data with citation URIs. This adds 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 a single paragraph that front-loads trigger phrases and packs substantial information without redundancy. Every sentence adds value.

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

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

Despite no output schema, the description explains what is returned (paired data, citation URIs) and the data sources. For a tool with two parameters, it provides complete context for correct invocation.

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

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

The description explains the semantic difference between the two enum values (company vs. drug) and what data is fetched for each, including specific financials and trial counts. This adds value beyond the schema descriptions.

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

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

The description clearly states it performs side-by-side comparison of 2–5 companies or drugs, with multiple trigger phrases. It differentiates from siblings by explicitly advising to prefer 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 states when to use this tool (comparing entities, ranking, head-to-head) and when not to (sequential single lookups). Provides concrete query examples and a preference directive.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive; the description adds substantial context beyond them: account/paywall requirement, latency expectations (15-60s, thorough ~90s), the full findings-packet contract (verbatim evidence + confidence + source + fetched_at + stable pipeworw:// citation), the explicit gaps[] never-invented guarantee, contradictions[] on standard/thorough, citation_uri only present when fetchable, and semantic excerpting rather than head-truncation. No contradiction with annotations.

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

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

The description is long but information-dense, with every clause earning its place: auth, sibling fallback, mechanism, output contract, use-case fit, exclusions, depth semantics, citation guarantee, and latency. It is front-loaded with the most operationally critical facts (account requirement and ask_pipeworx fallback) before the mechanics, and uses parentheticals to compress caveats without redundancy.

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

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

There is no output schema, so the description must carry the return-format burden — and it does: findings packet with fields, gaps[], contradictions[], hop, and resolvable citation_uri semantics. Combined with coverage of auth, pricing, latency, failure modes for off-catalog topics, and alternatives, this is complete for a tool of this complexity. The only negligible omission is explicit result-size/pagination behavior.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value beyond the schema by noting the question parameter accepts broad/multi-part phrasing because 'decomposition is the point,' and by attaching pricing and hop-behavior semantics to the depth enum ('depth:"thorough" needs a paid plan', gap-recovery vs lead-chasing passes) that the schema's per-value descriptions only partially convey.

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 boundary: 'Grounded multi-source research across Pipeworx's 1499 STRUCTURED data sources... in ONE call — this is NOT open-web search.' It names the exact mechanism (decomposes into facets, routes to 5,738 tools in parallel) and explicitly differentiates from siblings ('For a single lookup use ask_pipeworx'). An agent can tell exactly what this tool does and what it is not.

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

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

Provides explicit when/when-not with named alternatives: 'If you are not signed in, use ask_pipeworx instead', 'Best for broad/multi-part questions over structured data', 'For a single lookup use ask_pipeworx', and news topics should go to ask_pipeworx because 'deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog.' Depth-tier selection guidance per hop behavior is also given. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral traits: returns top-N relevant tools with full input schemas and curated examples, ready to call directly without second lookup. No contradictions.

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

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

Description is front-loaded with key purpose and usage, but includes a lengthy list of example domains which adds verbosity. However, it is well-structured and each sentence serves a purpose.

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

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

Given the complexity (6 params, no output schema, many siblings), the description covers purpose, usage, output format (top-N with schemas), and example queries. It does not mention rate limits or empty results, but is otherwise complete enough for an AI agent.

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

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

Schema coverage is 100%, so description does not need to add parameter details, but it provides contextual examples (e.g., 'analyze housing market trends') that illustrate usage. The description also notes the alias pattern implicitly through examples, adding value beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Find') and resource ('tools by describing the data or task'). It distinguishes itself from siblings by being the meta-tool for discovering other tools, listing numerous example domains (SEC filings, FDA drugs, etc.).

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 to use when browsing or discovering tools, and to call this FIRST when many tools are available. It also implies not to use when you already know the specific tool. 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?

Beyond the readOnly/idempotent annotations, it discloses parallel fan-out across named sources, a GDELT→GNews fallback, sources_used/sources_failed semantics, that empty sections mean real absence of data, and that private companies resolve to resolved:false with a notes line. This gives the agent valuable behavioral expectations that annotations alone do not.

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 and long, but the purpose and usage rule are front-loaded and every sentence carries a distinct constraint or behavior. It could be tightened with bullets, but the length is justified by the number of data sources and edge cases covered.

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 return-format burden and does so thoroughly: it names each returned section, specifies the 10-K fields, gives URI patterns, explains fallback behavior, and states how to interpret empty sections and failed resolution. This is sufficient for an agent to call the tool correctly for a wide range of inputs.

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

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

Schema coverage is 100% and both parameters are already documented with the same examples and accepted value shapes (ticker, zero-padded CIK, or name), so the description mostly restates the schema. It adds contextual details like resolved_from/resolved_to and private-company behavior, but these are output semantics rather than new 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 opens with concrete user intents and states the deliverable: 'full cross-source profile of a US public company in ONE parallel call.' It also differentiates itself from single-pack SEC/XBRL/news lookups, so an agent can distinguish it from the sibling lookup 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?

It explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and gives example queries. It also clarifies the acceptable inputs and the private-company edge case, so the agent knows when the tool is appropriate and what to expect outside its intended scope.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds context about clearing sensitive data but doesn't elaborate on side effects or recovery.

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 focused sentences: action, usage guidance, and sibling references. 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?

Single-parameter tool fully described with purpose, usage, and annotations. No missing details for agent decision-making.

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 parameter description is minimal ('Memory key to delete'). Description does not add meaning beyond the schema.

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

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

Description uses specific verb 'delete' and resource 'memory', clearly distinguishing from siblings 'remember' and 'recall'.

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

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

Explicitly states when to use (stale context, task done, clear sensitive data) and pairs with alternatives ('remember', 'recall').

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, ensuring safety. The description adds value by explaining the process: fetches the page, extracts title/description/key links, and emits standard llms.txt markdown. This behavioral detail is useful 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 three sentences: purpose, process, use cases. It is front-loaded with the most important information and contains no redundant words. Every sentence earns its place.

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

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

The tool is simple with 2 params and no output schema. The description covers what it does, how, and why. It could mention that the output is plain text (though implied by 'markdown format') or any URL limitations, but overall it is sufficiently complete for this 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 (url and max_links). The description does not add new semantic details about the parameters beyond what the schema provides. 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: generating a production-ready llms.txt file for any URL. It specifies the verb ('Generate'), resource ('llms.txt file for any URL'), and intended use cases (getting sites indexed by AI, drafting for own projects, auditing competitors). This makes it distinct from all 41 sibling tools, none of which relate to llms.txt generation.

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 usage scenarios: getting a client's site indexed, drafting for own project, or auditing competitor visibility. While it doesn't state when not to use, the context is clear and no alternative tool exists in siblings. The guidelines are helpful and direct.

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 it read-only/idempotent/non-destructive, and the description adds substantial behavioral context: it requires the caller's own Bearer token, demands exact camelCase schema names, explains the exact failure mode for unknown fields, and recommends introspection before guessing. There is no contradiction with the annotations.

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

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

The description is front-loaded with the main action, then each subsequent sentence adds a distinct operational constraint or remedy. Nothing is redundant or decorative.

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

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

For an arbitrary GraphQL passthrough with no output schema, the description covers endpoint, authentication, schema matching, failure behavior, and introspection strategy. It also includes worked examples that show the required query and variable shapes, so an agent has enough to invoke it correctly.

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

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

Schema coverage is only 33%, but the description compensates by explaining that 'query' is arbitrary GraphQL, must match the STRATZ schema exactly, and fails with 'Cannot query field' otherwise, while listing examples with variables. The required `_apiKey` parameter is already well documented in the schema, and the `variables` parameter is covered by the example and the phrase 'with optional variables.'

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

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

States a specific verb and resource: 'Send an arbitrary GraphQL query ... to the STRATZ API at api.stratz.com/graphql.' It also establishes the tool's scope as a catch-all, 'Use when no named tool covers the data you need,' which differentiates it from the many named 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?

Gives an explicit selection condition: only use when no named tool covers the needed data. This not only tells when to use it but implicitly when not to use it, so an agent can route around sibling tools without further inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is well covered. The description adds value beyond annotations by specifying the exact content of the response (display name, roles, stats, etc.), which is useful for an agent deciding whether this tool satisfies a query.

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?

A single, well-structured sentence front-loads the core action and resource, then packs the returned fields into a parenthetical list. There is no filler or repetition, and every clause adds useful information.

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

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

For a simple read-only lookup with two parameters and no output schema, the description covers the essential call context: what the resource is, how to identify it, and what the response contains. It could be slightly stronger by pointing to the plural sibling tool for listing all heroes, but it is not necessary for correct invocation.

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

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

Schema coverage is 50%: only '_apiKey' has a description. The tool description compensates for the undocumented 'id' parameter by clarifying it must be a numeric Dota 2 hero ID, and the schema examples (1, 92) reinforce valid values. The '_apiKey' meaning is already fully described 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 states a specific verb ('Fetch'), a precise resource ('a single Dota 2 hero's full detail'), and a key criterion ('by numeric hero id'). It also enumerates exactly what fields are returned, making it easy to distinguish from sibling tools like heroes or hero_stats.

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

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

The description clearly establishes the intended use case: retrieving comprehensive information for one hero identified by its numeric ID. While it does not explicitly name alternatives or exclusions, 'single' vs. the plural sibling tools implies when not to use it, and the examples reinforce expected ID values.

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 this as read-only, open-world, idempotent, and non-destructive, so the description doesn't need to restate safety behavior. It adds return-field details, which is helpful. However, the false claim 'No arguments required' is misleading and slightly undercuts the otherwise adequate transparency.

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

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

The description is short, front-loaded with the core purpose, and the return-field list is efficient. It loses a point because the concise 'No arguments required' sentence is inaccurate and would have been better omitted or corrected.

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 no-output-schema tool, the description covers the basic purpose and return fields. But it denies the existence of the required _apiKey parameter, which is a critical omission/misstatement for invocation. The schema partially compensates, but the description should be internally consistent with 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 coverage is 100% and the schema's _apiKey description is clear about the BYO token requirement. The description, however, explicitly says 'No arguments required', which contradicts the required _apiKey parameter. This is actively harmful: an agent following the description would omit a required field.

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

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

The description names a specific verb ('Fetch'), a specific resource ('the complete list of all Dota 2 heroes'), and the data source ('from STRATZ'). It also lists the returned fields, making the purpose unambiguous. It doesn't explicitly contrast itself with sibling tools like 'hero' or 'hero_stats', but 'complete list of all' inherently differentiates it.

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

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

The description implies this should be used when an agent needs the full hero roster, but it never explicitly says when to prefer this over siblings like 'hero' or 'hero_stats'. There are no exclusion criteria or alternative tool suggestions. The 'No arguments required' statement is closer to parameter guidance than to usage context.

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

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

Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, so the safety profile is covered. The description adds that the result returns matchCount and winCount per day, which is useful, but it does not elaborate on rate limits, data freshness, or the exact meaning of 'daily'.

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

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

The description is two sentences, front-loaded with the primary action and resource, and every phrase adds meaningful information. There is no filler or restating of the tool name.

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

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

For a read-only, idempotent stats-fetching tool with three parameters, the description covers the key inputs, optional filter, and return shape. While there is no output schema, mentioning matchCount and winCount per day gives the agent a concrete idea of the result. It is not exhaustive, but it is sufficient for this tool's complexity.

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

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

Schema description coverage is only 33%, so the description carries most of the parameter meaning. It explains that hero_id is numeric, that rank is optional and provides example values, and the return fields are tied to the stats being fetched. The main gap is a complete rank enum or case-sensitivity note, but the description compensates well for the sparse schema.

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

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

The description uses a specific verb ('Fetch') and resource ('daily win-rate and pick-rate statistics for a Dota 2 hero'), identifies the primary key ('numeric hero_id'), and notes the optional rank filter. This clearly distinguishes it from the sibling 'hero' and 'heroes' tools, which likely cover broader hero data.

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

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

The description implies when to use the tool: when you need daily hero win-rate/pick-rate stats, with an optional rank bracket. However, it does not explicitly state when not to use it or mention alternatives such as 'hero' or 'player_heroes', leaving some routing decisions to the agent.

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

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

Annotations already provide readOnly, idempotent, and non-destructive hints. Description adds output field details and that only active subscriptions are returned by default, 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?

Two concise sentences that front-load the action and return value. Every word adds value.

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

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

Despite no output schema, description lists all returned fields. Provides sufficient context for a simple read-only tool.

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

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

100% schema coverage means baseline is 3. Description does not elaborate on the single parameter, but schema already documents it sufficiently.

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 lists the caller's active subscriptions and specifies the returned fields. Distinguishes from sibling tools like subscribe/unsubscribe.

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

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

Explicitly advises when to use: 'Use this to review what you're monitoring before adding more or to find an id to cancel.'

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, lowering the bar. The description adds no further useful behavior (e.g., rate limits, external API latency) and instead asserts 'No arguments required,' which misrepresents the authentication requirement.

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

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

The first sentence is tight and front-loaded. However, the second sentence 'No arguments required' is not only unnecessary but false, so the description doesn't cleanly earn its place.

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

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

For a simple live-data fetch with a schema-documented API key, the description could be complete if it aligned with the schema. By denying the required parameter and offering no alternative context, it leaves the agent with a contradicted invocation model.

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

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

The schema fully documents _apiKey with a clear description, so the baseline would be 3, but the description directly contradicts the schema by claiming no arguments are required. This undermines the agent's ability to invoke the tool correctly.

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

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

States the specific action ('Fetch all currently live Dota 2 matches from STRATZ') and the exact return fields (matchId, team IDs, game time). This distinguishes it clearly from single-match or player-focused siblings like match and player_matches.

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?

There is no guidance about when to use this tool vs alternatives, and the only usage statement—'No arguments required'—is false because the input schema requires _apiKey. This is actively misleading rather than simply absent.

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=false, so no contradiction exists. The description adds value by stating exactly what is fetched (duration, teams, game mode, per-player stats), which is behaviorally relevant when invoking the 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?

A single well-structured sentence front-loads the action and resource, then lists returned fields in a compact, readable list. No filler or repetition of schema details.

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

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

With no output schema, the description's list of returned fields gives an agent a good sense of the response. It does not mention API-key requirements or error behavior, but those are covered by the schema and the tool's read-only annotations, so the definition is largely complete.

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

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

Schema coverage is only 50%, but the description compensates for the undocumented 'id' parameter by clarifying it is the numeric Dota 2 match identifier. The other parameter, _apiKey, is already fully explained in the schema, so the description meaningfully covers the gap.

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

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

The description names a specific action ('Fetch full details') and a clear resource ('a single Dota 2 match by numeric match id'), then lists the key data returned. This distinguishes it from list-like siblings such as player_matches and live_matches.

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

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

The phrase 'by numeric match id' and 'single match' make the intended invocation context clear: an agent should use this when it already has one numeric Dota 2 match id. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds the source and output content. However, the claim 'No arguments required' is misleading because the schema requires _apiKey, which could cause an agent to omit authentication.

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

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

The description is concise, front-loaded, and easy to parse in a single sentence. The false 'No arguments required' clause prevents a perfect score, but the structure itself is clean and efficient.

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

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

For a simple one-parameter, read-only tool with comprehensive annotations, the description covers the source, the output content, and the general behavior. The contradictory no-arguments statement leaves a correctness gap, and the tool would be stronger with an explicit mention that the API key is required despite the phrase.

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 fully documents _apiKey; the baseline for this dimension is thus 3. The description, however, actively undermines this by saying no arguments are required, directly contradicting the schema's required parameter.

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

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

The description clearly states a specific action—fetching current Dota 2 meta constants from STRATZ—and precisely defines the output as a list of game versions/patches with their id and name. This distinguishes the tool from sibling Dota tools like hero, heroes, match, and tournaments.

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 no guidance about when to use this tool versus alternatives, and it does not mention any exclusions or conditions. An agent has to infer the appropriate usage context from the tool name and sibling list.

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

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

Annotations provide no safety signals (all false), so the description carries the burden. It adds useful behavioral context: 'Rate-limited to 5 per identifier per day' and 'Filing without an account returns a claim_token; pass it back later.' It also mentions 'Free; doesn't count against your tool-call quota,' which is beyond structured data. No contradiction with annotations.

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

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

The description is a single dense paragraph but every sentence adds value: purpose, use cases, exclusions, message guidelines, token mechanics, daily digest, rate limit, and quota note. It is somewhat long but not wasteful; a structured list could improve scannability.

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 feedback tool with no output schema, the description covers essential operational aspects: what to report, what not to report, how to report, token-based follow-up, rate limiting, and impact. It also clarifies that this tool is free and doesn't consume quota. No significant gaps for an AI agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining the claim_token usage pattern ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed') and constraining message content: 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt.' This adds value beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb ('tell') and resource ('Pipeworx team'), and distinguishes from siblings by focusing on feedback submission rather than research/query tools like ask_pipeworx or discover_tools.

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

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

Explicit when-to-use guidance is provided: '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: 'ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server ... file it with that server instead.' This clearly directs when to use this tool versus alternatives.

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

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

Annotations already declare the tool as read-only, idempotent, and open-world. The description adds valuable context: the data source (CF analytics-engine), privacy (no PII), caching behavior (5min-1h), and the nature of the signal (self-aggregating).

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 with clear front-loading: first sentence gives the output, second bullet points use cases, third provides technical context. No redundant information.

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

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

Given the tool's simplicity (one optional parameter, no output schema, rich annotations), the description covers purpose, use cases, behavioral traits, and parameter semantics comprehensively. The agent has enough information to decide when and how 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 coverage is 100% for the single parameter 'window'. The description goes beyond the schema by explaining the semantic difference between short and long windows (hot vs. steady-state demand), which aids correct parameter selection.

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

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

The description clearly states the tool returns top tools, top packs, and total call volume over configurable windows. It uses specific verbs ('returns') and distinguishes itself from sibling tools like ask_pipeworx or discover_tools by focusing on aggregate popularity metrics.

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?

Three explicit use cases are provided, covering discovery, verification, and alignment. While it doesn't explicitly exclude use cases or name alternatives, the guidance is clear and actionable for an AI agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — the tool depends on an external third-party service ('via STRATZ') and, per the schema's _apiKey description, a user-supplied BYO token. However, no failure modes, rate limits, or data-freshness behavior are disclosed.

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

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

A single front-loaded sentence in which every clause earns its place: action, resource, key parameter, decision-relevant return fields, and data source. There is zero filler, and the most important scoping information appears first.

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

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

For a simple 2-parameter read-only fetch with rich annotations, the description covers the essentials: purpose, lookup key, return data fields, and external dependency. With no output schema, the field list effectively serves as the return contract. Minor gaps remain around response shape and failure behavior for an invalid token or unknown player.

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 50%: _apiKey is fully documented in the schema (BYO token, free at stratz.com), but steam_account_id has only a type and no description. The tool description's 'by Steam account id' partially compensates by identifying it as the lookup key, and the schema example shows a concrete value, but this is modest added meaning rather than full compensation.

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 ('Fetch'), a specific resource ('a Dota 2 player's profile'), the lookup key ('by Steam account id'), and the exact data returned (Steam name, profile URL, avatar, total match count, win count) via a named source ('via STRATZ'). The listed return fields clearly distinguish this from sibling tools like player_matches and player_heroes, which cover different data scopes.

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 return-field list implies this is the tool for profile-level overview data (identity plus aggregate counts), so an agent can infer when to use it. However, the description never explicitly names alternatives or states when-not-to-use it, leaving the differentiation from closely related siblings (player_matches, player_heroes) implicit.

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

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

Annotations already establish readOnly/openWorld/idempotent and non-destructive. The description adds useful behavioral detail not in annotations: ordering by match count, returned fields (heroId, matchCount, winCount), and default/limit behavior of take. 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?

One sentence that front-loads the verb, resource, and ranking criteria, then adds return fields and default in a compact clause. No filler.

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

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

For a simple read-only lookup without an output schema, the description names the returned fields and default limit, covering most invocation concerns. It doesn't document alternatives or failure cases, but these are not essential for this low-complexity 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?

Only _apiKey is described in the schema (33% coverage), so the description carries the burden. It adds meaning for take ('up to ... default 20') and steam_account_id ('by Steam account id'), which meaningfully compensates for bare schema entries.

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?

Uses specific verb 'Fetch' and identifies exact resource: top heroes played by a Dota 2 player, keyed by Steam account id and ranked by match count. This distinguishes it from sibling tools like hero/heroes, which address broader hero data, and player, which targets account-level data.

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 implies the intended scenario — get a player's most-played heroes — but provides no explicit when-to-use or exclusions relative to siblings like player_matches or hero_stats. There is no guidance for choosing between this and player/heroes.

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 communicate read-only, open-world, idempotent, and non-destructive behavior. The description adds concrete behavioral detail beyond that: one row per match, a field list, and pagination via take/skip. It does not cover result limits or edge cases, but the annotations lower the burden.

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 no filler: the first states the primary action and resource, the second covers output shape and pagination. Every sentence earns its place and the description avoids repeating schema details.

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

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

For a read-only history tool with no output schema, the description is nearly complete: it specifies the input identifier, optional pagination, and the exact row contents. It only omits secondary details like default page size and the recency window for 'recent' matches.

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 only 25%, since only _apiKey has a description. The description compensates partially by identifying steam_account_id as the lookup key and explaining take/skip as pagination controls, but it leaves numeric ranges, defaults, and maximum page size undocumented.

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

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

The description opens with a specific action and resource: 'Fetch a Dota 2 player's recent match history by Steam account id.' It clearly distinguishes this tool from sibling tools like player_heroes and live_matches by scope, and it enumerates the exact returned fields.

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 implies when to use the tool — whenever a player's recent match history is needed for a Steam account — but it does not explicitly name sibling alternatives or exclusion conditions. The pagination note is a how-to detail rather than guidance on choosing this tool over alternatives.

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

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

Beyond the annotations (readOnly, idempotent), the description details internal logic: Jaccard similarity threshold, placeholder filter, fill check against CLOB depth. It discloses limitations and contexts like 'skipped_low_similarity' and 'thin_legs'.

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?

Despite length, every sentence is informative. Front-loaded with main purpose, then structured by mode. Technical details are logically placed. No redundancy or filler.

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

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

Covers all usage modes, internal algorithms, edge cases, and response structure. Even references a related tool (polymarket_fill_risk). No gaps given the 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 already describes both parameters; description adds concrete examples (event slugs, topic phrases) and explains how each parameter affects behavior (event mode does partition checks, topic mode scans across events). This significantly enriches schema information.

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 distinguishes three modes (no args, event, topic) with specific behaviors, differentiating from siblings by mentioning polymarket_fill_risk for custom sizing.

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

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

Provides explicit guidance: when to use each mode ('event recommended for a specific market', 'topic for cross-event scanning'), and when not to trade (realizable_edge_pp ≤ 0). Also recommends alternative tool for custom sizing.

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

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by detailing the three model families, response structure, caching behavior (1h KV cache), 24h-move warning, diagnostics, and tradeable-edge filters. This provides comprehensive behavioral context an agent needs.

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?

Despite being long, every sentence is informative. The description is well-structured with bold section headings for the three segments, bullet-like lists, and clear separation of response structure and knobs. It front-loads the purpose and efficiently conveys complex 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?

The tool lacks an output schema, but the description compensates by thoroughly explaining the response structure (by_segment, fed_candidates, _diagnostics), including details about each field and caching. It provides all necessary context for an agent to use the tool correctly without needing an 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?

With 100% schema coverage, the description still adds significant value: it explains the nuanced behavior of min_partition_leg_kelly (applies per-leg because parent-level Kelly is zero for partition arbs), gives practical advice for slippage_pp, and clarifies defaults. It enriches understanding beyond the schema descriptions.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('scan', 'return') and resource ('Polymarket markets'), and distinguishes from sibling tools like polymarket_arbitrage by its discovery-oriented purpose.

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

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

The description explicitly states it's built for 'what should I bet on today' and explains how agents can discover opportunities without paging. It provides context for when to use (discovery) and details tradeable-edge knobs. It does not explicitly exclude alternatives, but the context is clear enough for an agent to differentiate.

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 significant behavioral context beyond annotations: explains snapshot gaps, TTL bounds, decay calculation basis (daily closes, not intraday). 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?

Dense but clear; every sentence adds value. Slightly long but justified given the telemetry detail. Front-loaded with 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?

No output schema, but description fully explains response structure (tracked, expired, snapshot_dates fields) and their meanings, making the tool usable without needing to see a sample response.

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

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

Adds defaults, clamps, and valid values for days and window beyond the schema descriptions. Schema coverage is 100%, but description enriches with practical usage constraints.

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

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

Clear verb+resource: 'Edge persistence and decay telemetry' from daily snapshots. Distinguishes from sibling 'polymarket_edges' by focusing on historical tracking rather than current edges.

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

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

Explicitly states when to use: to answer how long an edge has existed and if shrinking. Implicitly contrasts with fresh edges, but doesn't explicitly list alternatives or when-not-to-use.

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

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

Annotations already mark it as read-only and idempotent. The description adds behavioral details: it walks the ladder, checks every leg, returns verdicts (clean|degraded|cannot_fill), and identifies forced directional risk. No contradictions.

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

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

Description is lengthy but well-structured with mode explanations and bullet-like return fields. It front-loads the core purpose. Could be slightly more concise, but the complexity 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?

No output schema, so description carries full burden for return values. It lists all expected fields (top_of_book, vwap_fill_price, slippage_pp, etc.) and explains basket-specific concepts like forced directional risk. Comprehensive for a risk-assessment 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% (all 4 parameters have descriptions). The description adds significant value: explains modes (single-market vs basket), default values, and basket-specific interpretation (size_usd as settlement notional). Goes beyond schema descriptions.

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

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

The description clearly states the tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth', with specific verbs (check) and resource (edge). It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edges by advising to use this tool before acting on their signals.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', and explains why (theoretical overround not capturable, partial fills convert arb to directional). Provides clear context and alternatives.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses important behaviors: compatibility codes can be non-empty even when pairs are returned, pairing is never fully verified, fees are not modeled so spreads are gross, unknown-leg comparisons are skipped, and temporal_alignment null does not mean aligned. This is rich, honest behavioral context.

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

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

The description is long but densely packed and well structured: core purpose, modes, response fields, safety codes, skipped comparisons, fees, and a closing caveat. Every section carries information an agent needs, given there is no output schema, and the most important scoping statement is front-loaded.

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

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

For a complex tool with no output schema, the description covers the response shape, warning fields, flags, skipped categories, fee implications, and mode-specific behavior. It gives an agent enough to call the tool correctly and interpret results, even with zero required parameters and no structured return type.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic value: it explains the meaning of the topic shortcuts, how explicit kalshi_event_ticker and polymarket_event_slug override the mapped sides, and that both modes run the same matcher. This goes beyond the schema's literal descriptions.

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

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

The description states a specific resource and action: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question. It is clear enough to distinguish from siblings like polymarket_arbitrage or polymarket_edges by the Kalshi/Polymarket cross-venue scope, though it does not explicitly name any sibling it is not.

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

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

The description gives clear operational guidance: two modes, when to use the topic shortcuts versus explicit ticker/slug pairing, and a caution that pre-mapped topics are often not tradeable. It does not explicitly contrast this tool with sibling alternatives, so it stops short of full when-to-use-versus-alternatives guidance.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, which are consistent with 'retrieve' and 'list'. The description adds value by explaining that omitting the key lists all saved keys, that the tool is scoped to an identifier, and it mentions pairing with remember/forget. No contradictions.

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

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

The description is concise with four sentences. The first sentence states the core purpose. Subsequent sentences provide usage context, scoping, and pairing. Every sentence adds value without redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description covers all necessary aspects: purpose, usage, scoping, and relationship with sibling tools. No gaps are apparent.

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

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

Schema coverage is 100% (only one parameter 'key' with description). The description adds meaning by explaining that omitting the key lists all keys, which goes beyond the schema. The examples in the input schema further clarify 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 clearly specifies the verb 'Retrieve' and 'list', the resource 'value saved via remember', and distinguishes from siblings like 'remember' and 'forget'. It gives specific examples of what to retrieve (ticker, address, notes), making the purpose unambiguous.

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

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

The description explicitly states when to use the tool: 'to look up context the agent stored earlier' and provides concrete examples. It mentions scoping to the agent's identifier. However, it does not explicitly mention when not to use it or alternatives beyond pairing with remember/forget.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds behavioral details: the effect of mark_read (flags events as read, affecting subsequent calls), the return structure (source, citation_uri, payload), and that the feed persists. 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 four sentences, front-loaded with the main purpose, and each sentence adds necessary information without redundancy. It is efficient and scannable.

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

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

The description covers the tool's purpose, input parameters, return fields, and side effects (mark_read). Despite no output schema, the explanation of return values is sufficient. Annotations cover safety. The tool is straightforward and the description is complete for effective use.

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

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

All 5 parameters are described in the schema with 100% coverage. The description adds examples (e.g., 'sec_8k' for type) and explains the behavior of mark_read and since, providing context beyond the schema definitions.

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 pulls fired events from a subscription feed, returns recent alerts with specific fields (source, citation_uri, payload), and allows filtering. It uses specific verbs and resources, distinguishing it from siblings like list_subscriptions or subscribe.

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 usage context: filter by type/since, mark read, polling works fine, and mentions an alternative endpoint for scripts/dashboards. However, it lacks explicit guidance on when not to use this tool or direct comparisons with 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?

Description adds significant behavioral context beyond annotations: fans out to multiple sources (SEC, GDELT/GNews, USPTO), explains fallback logic, and notes USPTO soft-fail. 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?

Description is slightly lengthy but well-structured, front-loaded with key use cases. Every sentence adds value, but could be streamlined slightly.

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 specifies return structure (changes[], total_changes, URIs). Covers multiple sources, fallbacks, and limitations. Fairly complete for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds examples and explains that 'since' accepts ISO dates or relative shorthand, 'type' only supports 'company', and 'value' can be ticker or CIK. Exceeds 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?

Description clearly states the tool provides a change feed for a company in a recent time window, with specific examples of user queries. It distinguishes from the sibling 'entity_profile' by specifying when to use each.

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., 'what's new' queries) and when to use 'entity_profile' instead. Also mentions fallback behavior and limitations like USPTO soft-fail.

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 important behavioral details beyond annotations: data is scoped by identifier, authenticated users get persistent memory, anonymous sessions retain memory for 24 hours. Annotations already state idempotentHint true and destructiveHint false, which are consistent.

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

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

The description is concise, three sentences, with a clear front-loaded purpose statement, then usage guidance, then technical behavior. No wasted words.

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

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

For a write tool with no output schema, the description adequately explains the operation and persistence behavior. It could be improved by explicitly noting that a success confirmation is returned, but it remains 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%, and the description provides additional context by giving concrete examples (e.g., 'subject_property', 'target_ticker') and explaining that value can be any text. This adds meaning beyond the schema.

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

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

The description clearly states the tool saves data for reuse across conversations or sessions, using key-value pairs. It distinguishes itself from siblings by mentioning pairing with recall and forget.

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

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

The description explicitly tells when to use it (when discovering valuable information to carry forward) and mentions pairing with recall/forget. However, it does not explicitly state when not to use it, which would improve the 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?

Annotations already mark the tool read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: graceful degradation when GLEIF/OpenFIGI are unavailable, ambiguous matches returning `figi_candidates` rather than asserting, explicit `unresolved` reporting, source labels per identifier, and internal cascading through multiple lookup endpoints. No contradiction with annotations.

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

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

The description is long and dense, but nearly every phrase carries operational value for a complex multi-type resolver. It is front-loaded with examples and a routing directive; the main cost is a single sprawling parenthetical structure that could be better 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?

With no output schema, the description carries the burden of explaining return behavior, and it does so thoroughly: CIK/ticker/company_name, LEI ownership fields, FIGI candidates, `unresolved` output, source labeling, RxCUI/ingredient/brand for drugs, and failure-mode behavior. An agent has enough to call and interpret the result correctly.

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

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

Schema coverage is 100%, but the description enriches the `value` parameter with critical format guidance: pass only the entity name, use the issuer exactly as printed for bonds, avoid trailing security-class words. This goes well beyond the schema's brief examples and materially helps correct invocation.

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 utterances ("What's the ticker for…", "find the CIK for…") and states a clear verb-object relationship: resolve a user-spoken NAME into canonical identifiers. It also distinguishes the tool from siblings by noting these identifiers are what "other tools require as input" and by saying "Use FIRST".

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

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

The description gives strong when-to-use guidance: "Use FIRST whenever you have a name but need an ID," backed by representative query patterns. It does not explicitly name alternative sibling tools or state when not to use this tool, so it stops short of full routing contrast.

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 the tool as read-only and idempotent. The description adds value by explaining it probes each entity with ai_visibility_check and returns a ranked list with scores, confidence, and signal density. No contradictions.

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

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

Three sentences covering action, method, output, and use case. Front-loaded with purpose, no wasted words.

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

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

Given no output schema, the description adequately describes return fields (score, confidence, signal density per entity). It covers all parameters. Missing details like error handling or model-specific behavior, but 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 description coverage is 100%. The description adds context: first entity is the 'subject' for narrative, and models parameter includes default 'workers-ai' with note about apiKey. This enhances understanding 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 explicitly states the tool compares AI visibility across multiple entities, uses ai_visibility_check, and ranks results. It clearly differentiates from sibling tools like ai_visibility_check (single entity) and compare_entities (general).

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 an example question. It implies the tool is for multi-entity comparison, but does not explicitly state when not to use it or mention alternatives.

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

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

Annotations already indicate safe, open-world, idempotent behavior. Description adds critical behavioral detail: bundlephobia's first measurement can take 5-30s, partial failures degrade gracefully with sources_failed listed. 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?

Concise yet comprehensive. Single sentence defines purpose, followed by usage guidance, return format, ecosystem scope, and edge cases. No wasted words; information is well 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 no output schema, description provides detailed return structure: summary block fields, per-advisory details, links, alternative versions. Also covers partial failure and latency. Complete for tool selection.

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

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

Schema coverage is 100%. Description adds value by noting scoped packages are accepted and default version behavior, which aids selection beyond the schema descriptions.

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

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

Description clearly states it performs a composite check for npm packages, combining multiple data sources. It distinguishes itself from sibling tools by specifying NPM ecosystem only and directing other ecosystems to deps.dev directly.

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 instructs when to use: when agent asks about safety, popularity, size, or cost of adding an npm package. Also specifies when not to use, providing alternatives for other ecosystems.

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

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

Adds behavioral details beyond annotations: uses BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char limit with truncation flag. No contradiction with readOnlyHint, openWorldHint, 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?

Single concise paragraph with front-loaded key information. Every sentence adds value; no fluff.

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

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

Comprehensive for a semantic search tool: explains algorithm, character cap, output details (offsets, similarity scores), and pairing suggestions. No missing critical info despite no output schema.

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

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

Schema description coverage is 100%, but description adds context: explains limit purpose, gives query examples, mentions 200K char cap for text. Enriches beyond schema basics.

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 'Semantic search INSIDE a fetched record' with specific verb and resource. Distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded.

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 the record is too big to cram into the prompt'. Provides guidance on saving context and returning relevant passages with offsets. Suggests pairing with alternative 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?

Discloses behavioral traits beyond annotations: requires OAuth, phone verification for SMS, SMS daily cap (10/day), webhook HMAC signing and auto-disable. No contradictions with annotations (readOnlyHint=false, idempotentHint=true are consistent).

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

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

Front-loaded with core purpose, but the description is relatively long. Every sentence contributes value, though some redundancy (e.g., delivery details repeated in schema and description). Still efficient for a complex tool.

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

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

Covers purpose, requirements, type examples, delivery options, and behavioral limits. Lacks error scenarios or return value details beyond stating 'Returns the new subscription id'. Given no output schema, more on output structure would be helpful, but the description is adequate for a 3-param tool with nested objects.

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

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

Adds significant meaning beyond schema: for 'type', enumerates all supported values with context; for 'params', provides detailed per-type examples; for 'delivery', explains channel-specific details (email, SMS, webhook with security). Schema coverage is 100% but description enriches it.

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 verb 'Create...subscription' and identifies the resource as a 'live-data event stream', clearly distinguishing it from siblings like 'unsubscribe' and 'list_subscriptions'.

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

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

Explicitly states OAuth account requirement (not for anonymous/BYO), supported types with examples, and delivery options. However, no explicit when-not-to-use or alternative tool comparisons are given.

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

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns category-bucketed example questions drawn from a live catalog, and explains the structure. No contradiction.

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

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

The description is well-structured with example queries front-loaded. It is slightly long but every sentence adds value. The structure is clear and easy to scan.

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 role as an onboarding/discovery tool with no output schema, the description fully explains purpose, usage, parameters, and return structure (category-bucketed examples with tool shapes). It is complete and leaves no gaps.

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

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

Schema description coverage is 100%, but the description adds value by listing possible values ('finance | pharma | ...') and explaining the behavior when omitted (full spread). This is helpful beyond the schema's generic description.

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

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

The description clearly states it is an onboarding entry point for an agent to know what questions to ask, returning category-bucketed example questions with tool+argument shapes. It distinguishes from sibling tools by being the first tool to use when unsure about Pipeworx's capabilities.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Provides guidance on when to pass no arguments for full spread or a specific topic to focus, with examples.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the data returned (display name, description, tier, dates, prize pool), giving the agent a concrete expectation without contradicting 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?

A single, front-loaded sentence that states the action, resource, lookup key, and key return fields. There is 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?

For a simple read-only fetch tool with two well-typed parameters and rich annotations, the description is complete. It names the resource, the identifier, and the expected return content, so an agent has enough context to call it correctly despite the absence of an 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 coverage is 50%: _apiKey is fully documented, but id has only a type. The description compensates partially by clarifying that id is the numeric tournament/league identifier, but it does not add further semantic detail about id formats or the meaning of the listed output fields beyond what common sense would expect.

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

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

The description uses a specific verb ('Fetch'), identifies a concrete resource ('a single Dota 2 tournament (league)'), and states the lookup key ('by numeric id'). It also lists the returned fields, and the word 'single' distinguishes it from the sibling 'tournaments' 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 phrase 'single Dota 2 tournament ... by numeric id' gives clear selection context: use when you have a numeric id and need details for one league. It does not explicitly name alternatives or state when not to use it, but the 'single' qualifier implies that the plural sibling is for 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context beyond that: default sort order, a 50-result cap, returned fields, and the effect of only_premium=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 compact sentences carry all essential information: what is returned, ordering, limit, fields, and the filter option. No filler or redundancy is present, and the key action is front-loaded.

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

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

For a low-complexity list tool with no output schema, the description includes the necessary return fields, ordering, limit, and filter behavior. It could add a brief note about the default behavior when only_premium is omitted, but that is reasonably implied by 'restrict.'

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 50%, but the description compensates for the undocumented only_premium parameter by explaining it restricts results to MAJOR and INTERNATIONAL tier events. The _apiKey parameter is fully described in the schema. Together, both parameters are semantically clear.

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

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

The description specifies a clear verb and resource: 'List Dota 2 tournaments (leagues) from STRATZ.' It adds concrete details such as ordering, a 50-item limit, and included fields (id, name, tier, dates, prize pool). The plural 'tournaments' also differentiates it from the singular sibling tool 'tournament'.

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 context is clear: this tool lists Dota 2 tournaments, sorted by most recent start date, with an optional premium-only filter. It does not explicitly state when not to use it or name an alternative like 'tournament' for a single-event lookup, so it misses the top bar for explicit 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?

Adds value beyond annotations by detailing ownership enforcement, deactivation (not deletion), and link to recent_alerts. Annotations already indicate non-destructive and idempotent behavior.

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

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

Two concise sentences, no wasted words, front-loaded with action and resource.

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

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

For a simple tool with one parameter and no output schema, the description fully covers ownership, side effects, and relation to other tools.

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

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

Schema coverage is 100% and the description does not add additional parameter meaning beyond the schema's description of 'id'.

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 verb 'Cancel' and resource 'subscription by id', clearly distinguishing from sibling tools like subscribe and list_subscriptions.

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

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

Explicitly mentions ownership enforcement and that historical events remain via recent_alerts, providing context for appropriate use, though no explicit when-not-to-use.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds substantial context beyond this: it explains the two routing paths, the exact verdict values, the meaning of 'could_not_verify' (including the critical warning that it is not evidence), and the citation/reasoning return format. This goes well beyond the annotation baseline.

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 earns its place, covering query phrasing, usage, dual pipeline, return values, and error semantics. It is front-loaded with examples and clearly structured into readable segments. Slightly padded by the example phrases but still efficient for the tool's complexity.

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

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

Given the tool's complexity and the absence of an output schema, the description fully explains what is returned (verdict, actual value with pipeworx:// citation, reasoning) and the meaning of edge-case verdicts like 'could_not_verify' and 'unsupported'. It also explains the internal routing and the efficiency benefit, making it complete for an agent to confidently invoke the tool.

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

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

Schema description coverage is 100%, with both 'claim' and 'tolerance_pct' already well documented. The description body does not add any parameter-specific information beyond the schema, so it stays at the baseline of 3. No credit is needed for the schema's own richness.

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

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

The description explicitly states the tool performs natural-language claim verification against authoritative sources, with a clear verb ('verify', 'fact check') and resource ('claims'). It distinguishes itself from siblings by specifying the verdict output and noting it replaces 4–6 sequential calls, making its unique role unambiguous.

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

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

The description clearly states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also details the two processing paths (structured SEC EDGAR for company-financial claims, grounded pipeline for all else), providing strong contextual guidance. It does not explicitly mention when not to use or name alternatives, so it earns a 4 rather than 5.

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