Steam

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the default model is free, passing _apiKey invokes Anthropic and the user pays Anthropic directly, and the return shape is per-model {score, confidence, signals, raw_response} plus a combined view. No contradictions with annotations.

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

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

The description is three sentences, front-loaded with the core action and output, followed by default behavior and use cases. Every sentence adds unique information without 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?

The description covers the main function, default vs optional models, cost implication, return format, and use cases. With no output schema, it adequately describes what the agent can expect back. Minor gap: it does not explain what the 'signals' field contains or how the 0-100 score is derived, but this is not critical for invoking 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?

All 4 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds extra semantics by explaining the default model selection ('Omit for just workers-ai'), the pass-through nature of _apiKey, and the disambiguation purpose of context. This goes beyond the schema's field 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 opens with a specific verb ('probe') and resource ('one or more LLMs'), defines the output score (0-100 per model), and includes concrete use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring), making the tool's purpose unmistakable. It distinguishes itself from similar sibling tools like scan_competitor_ai_presence by focusing on per-model visibility scoring.

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

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

The description lists explicit use cases ('Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring'), giving clear context for when to apply the tool. However, it does not mention when not to use it or point to alternatives like scan_competitor_ai_presence, so it falls short of explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, fully covering safety and non-mutating behavior. The description adds only the source (Steam Store API), which is minimal behavioral context but not contradictory. No additional caveats like rate limits or data scope are provided, but the annotation coverage lowers 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?

The description is a single sentence that is front-loaded with the key phrase 'Store page detail' and the source. It is extremely concise with zero wasted words, earning a perfect score for efficiency.

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 an output schema present and annotations covering safety, the description is minimally sufficient for a simple lookup tool. However, it lacks usage context, prerequisites, or parameter details, making it only adequately complete for a tool of this simplicity.

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 0%, meaning the description does not explain any of the three parameters (appids, l, cc). The schema examples provide some implicit meaning (e.g., 'l' as language, 'cc' as country code), but the description itself adds no semantic value beyond what the structured examples show, failing to compensate for the low coverage.

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

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

The description clearly identifies the tool's purpose as retrieving store page details from the Steam Store API, which distinguishes it from siblings like app_news or app_list. However, it lacks an explicit verb such as 'retrieve' or 'fetch', making it slightly less direct than ideal.

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 on when to use this tool versus alternatives. Sibling tools like app_list and app_news exist, but there is no mention of selection criteria, exclusions, or preferred scenarios, leaving the agent to infer usage from the name alone.

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, covering the safety profile. The description adds the 'large' qualifier, which warns about output size—useful behavioral context. However, it does not disclose pagination, response limits, or performance implications beyond 'large.' With annotations providing the core safety traits, this partial additional context merits a 3.

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

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

The description is extremely concise—a 4-word phrase—with no filler or redundant information. Every word adds value: 'Full' indicates completeness, 'app list' identifies the resource, and 'large' provides a key output warning. It is tightly front-loaded and wastes zero space.

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

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

Given the tool has zero parameters, a rich output schema, and strong annotations (read-only, idempotent, non-destructive), the description is largely complete for a list retrieval tool. The 'large' warning is the main missing piece that could be elaborated (e.g., whether pagination is needed), but the presence of an output schema and annotations reduces the burden. It is adequate but could add one sentence about output size/limits.

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

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

The input schema has zero parameters, so per the baseline for 0-parameter tools, the description does not need to explain parameters. The description adds no parameter information, but none is needed. The baseline of 4 applies because no parameter semantics are required.

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 'Full app list (large)' clearly identifies the resource (app list) and scope (full/large), distinguishing it from sibling tools like app_details and app_news. However, it lacks an explicit verb (e.g., 'returns' or 'lists'), so it is not a complete verb+resource statement.

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?

No guidance is provided about when to use this tool instead of alternatives. It does not mention that app_details is for a specific app or that app_news provides news, nor does it suggest situations where the full list is appropriate. The description simply states what it is, with no comparative or contextual guidance.

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

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

The description adds no behavioral context beyond what annotations already provide. While annotations (readOnlyHint, idempotentHint, etc.) indicate a safe read operation, the description does not disclose what the news feed contains, how results are paginated, or any other operational details.

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

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

The description is extremely short, but this is under-specification rather than conciseness. It is a single noun phrase that provides minimal information, similar to a low-quality label rather than a useful tool description.

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 incomplete given its parameters and sibling context. There is no explanation of what 'news' refers to, how appid is used, or what the output represents. Even with an output schema present, the description fails to provide enough 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?

With 0% schema description coverage, the description must compensate by explaining parameters, but it does not. The schema lists appid, count, and maxlength without any descriptions, and the description offers no hints about their meaning or 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 'App news feed' essentially restates the tool name and title without using a specific verb like 'get' or 'list'. It gives a vague sense that the tool returns news items for an app, but does not clearly distinguish it from sibling tools such as app_details or app_list.

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 on when to use this tool versus alternatives. The description does not mention any prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the name alone.

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 read-only/idempotent behavior, so the bar for extra context is lower. The description adds substantial behavioral detail: it routes to thousands of tools, fills arguments automatically, returns citations via pipeworx:// URIs, works on every tier, and is a single fast call. It also clarifies that it can handle breaking news through live news feeds. This goes well beyond the annotations and fully discloses the tool's behavior.

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

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

The description is longer than average but front-loaded with a clear directive ('PREFER OVER WEB SEARCH') and organized into use cases, examples, and alternatives. Every sentence provides useful information, and the structure is logical. It is slightly verbose but earns its length given the tool's broad scope.

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

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

For a tool that routes to 5,508 tools, the description is remarkably complete: it explains the routing behavior, output format (structured answer with citation URIs), performance (one fast call), availability (every tier), and when to use alternatives. No output schema exists, but the description sufficiently sets expectations for return values. It also addresses edge cases like breaking news and multi-part questions.

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 is self-explanatory: the parameters are all aliases for the 'question' field, each with a description. The description itself includes examples of valid questions ('What was Apple's revenue in 2024?', 'Any recent SEC filings for $NVDA?') which illustrate expected input format. This meets the baseline for high schema coverage; the description adds marginal value by showing natural-language 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 states a specific verb+resource: 'Routes the question to the right one of 5,508 tools across 1448 verified sources, fills arguments, returns the structured answer with stable pipeworx:// citation URIs.' It also distinguishes from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for different needs. This leaves no ambiguity about what the tool does.

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

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

The description explicitly says to prefer this over web search, provides a comprehensive list of use cases (SEC filings, FDA data, FRED/BLS, etc.), gives trigger phrases ('what is', 'look up', 'find'), and offers concrete examples. It also states when to step up to alternatives: 'for a hallucination-resistant single answer with verbatim evidence + confidence use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research.' This is exemplary usage guidance.

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

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

Beyond the readOnly, idempotent, and openWorld annotations, the description reveals that this is an experimental router with candidate improvements enabled live only when under test. It states that no candidate is active, that it currently matches ask_pipeworx exactly, and that it 'falls back to nothing'—providing critical behavioral context for beta usage. 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 four sentences long, densely packed with important information: identity, current status, usage, and reassurance that it is a full working router. It is front-loaded and has no fluff, though the specific date and detailed caveats make it moderately verbose rather than ultra-terse.

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

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

Given the lack of an output schema, the description compensates by stating the response shape is the same as ask_pipeworx, which gives agents a reference point. It fully explains the beta/experimental nature, current parity with the stable router, and that it is a fully functional router. It does not explicitly describe return values, but the reference to ask_pipeworx makes it sufficient.

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

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

The input schema already provides 100% coverage with descriptions for all six parameters, including the question field and all aliases. The description only adds 'same arguments' without offering new semantic detail beyond what the schema contains, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies this as a 'Beta version of ask_pipeworx: identical universal router' with 'same 5,508 tools', making the tool's purpose obvious. It differentiates from the stable ask_pipeworx by emphasizing 'candidate routing improvements' and the 'experimental edge'.

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

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

The description explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing' and clarifies the current state ('No candidate is active right now... currently matches ask_pipeworx exactly'). It does not mention alternatives such as ask_pipeworx_grounded or provide explicit when-not-to-use guidance, so it falls just short of a 5.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds substantial behavioral context beyond those: it details the strict evidence grounding, the possible refusal reasons, the returned object shape, and the runtime cost of an extra LLM call. No contradictions with annotations.

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

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

The description is dense but well-organized: it leads with the core value proposition, then explains the mechanism, return behavior, use cases, and trade-off. It is longer than a tweet but every clause earns its place, so it remains appropriately efficient.

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

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

The description is complete for a complex tool. It explains the routing behavior, the evidence requirement, the refusal reasons, and the output shape. Even without an output schema, the agent knows exactly what to expect. It also names the sibling alternative and the cost trade-off.

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 only required parameter is 'question' with clear alias descriptions. The description doesn't need to add more parameter semantics; the schema already covers the input fully. 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 opens with a specific, informative purpose: a hallucination-resistant answer mode for high-stakes reads. It clearly distinguishes this tool from its sibling ask_pipeworx by describing the extraction-only behavior and the refusal mechanism.

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

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

Explicit guidance is given: use when the answer will be quoted, cited, or acted on, and when the agent must not invent facts. It also explicitly says to prefer ask_pipeworx for casual lookups because this tool costs an extra LLM call.

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

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

Annotations declare readOnlyHint and idempotentHint, but the description adds substantial behavioral detail: low-confidence match short-circuiting, market_closed_or_inactive status, wide-spread illiquidity flags, resolver contract fields, parent_event extraction, news fallback behavior, and cancellation-rule risk. This far exceeds the annotation baseline and accurately describes edge cases without contradicting the read-only hints.

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

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

The description is long, but well-structured with clear sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, SAFETY, RESOLUTION-RULE RISK). The core purpose is front-loaded in the first sentence. While dense, nearly every sentence delivers actionable detail, so the length is earned.

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 fully explains return values: result.market fields, result.analysis including edge/kelly warnings, result.evidence keying, resolver contract fields, parent_event extraction, news fallback flags, and cancellation-rule risk. It covers normal operation, low-confidence matches, closed markets, illiquidity, and rule-based pitfalls—exceptionally complete for an agent.

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

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

Schema coverage is 100% for all three parameters, yet the description adds valuable context: concrete examples of slug/URL/question text for 'market', the meaning of 'depth' (quick = 2-3 sources vs thorough = full fan-out), and 'include_raw' size implications (~20KB vs 50KB-500KB). The fan-out examples also illustrate how depth changes behavior.

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

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

The description opens with a specific verb+resource: 'Research a Polymarket bet' and clearly enumerates input formats (slug, URL, question text). It distinguishes the tool from siblings by describing the fan-out to category-specific data packs and the market-vs-model comparison, making its role in evidence gathering explicit.

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

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

The description provides explicit when-to-use guidance with 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It does not explicitly name alternative tools for when not to use it, but the use cases and structure clearly separate it from the sibling arbitrage/edge tools.

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

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

The description adds substantial behavior beyond annotations: it specifies data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with citation URIs. This complements the readOnly/idempotent hints without contradiction.

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

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

The description is dense but well-structured, starting with trigger phrases and then explaining behavior. While slightly long, every sentence carries useful information—examples, sources, sorting, and efficiency gains. No fluff, but it could be tightened some.

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 lack of output schema, the description covers what data is returned (financial metrics for companies, FAERS counts for drugs), how results are ordered, and that each entity gets paired with citation URIs. It also addresses edge cases like fiscal year alignment, making the tool's behavior predictable 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 already describes both parameters with 100% coverage, but the description enriches them: type's enum values are explained with specific data pulled, and values get examples (tickers vs drug names) plus min/max constraints. This adds value beyond the schema's minimal 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 compares 2–5 companies or drugs in one parallel call, with specific trigger phrases like "X vs Y" and "which is bigger." It distinguishes itself from sequential lookups and the sibling entity_profile by emphasizing parallel side-by-side comparison.

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

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

Explicitly says "ALWAYS PREFER over sequential single-pack lookups when comparing entities," which names the alternative and gives a clear when-to-use rule. It also distinguishes between company and drug types, providing concrete examples that guide invocation.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. However, the description adds no behavioral context beyond that, such as what 'current' means, whether it is real-time, or what the response structure looks like. It contributes nothing 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 extremely short, but it is under-specified. It is a fragment, not a sentence, and provides minimal information. While it is concise, the brevity is harmful because it obscures essential 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?

Even though there is an output schema and annotations, the description lacks any context about what 'current concurrent players' means, how to interpret the appid, or any retrieval behavior. For a simple tool, it might be enough, but the absence of parameter explanation and usage guidance makes it incomplete.

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 does not explain the 'appid' parameter at all. Schema description coverage is 0%, so the description must compensate, but it fails. An agent cannot infer that appid refers to a game/application ID or how it affects the returned player count.

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 'Current concurrent players' is a noun phrase that essentially restates the title 'Current Player Count'. It lacks a verb and does not explicitly state what the tool does (e.g., retrieve, fetch). It gives a vague idea but doesn't distinguish from sibling tools like 'app_details' or 'player_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?

There is no guidance on when to use this tool versus alternatives. It does not mention any use cases, exclusions, or related tools. The sibling list is large, but the description provides no context for selection.

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

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses account requirements, depth-dependent behavior (gap recovery, contradictions scan), latency, citation_uri resolution policy, semantic excerpting, and the guarantee never to invent findings. This is far richer than annotations alone.

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

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

The description is long but well-structured, front-loading the account requirement and the key distinction from ask_pipeworx. Every sentence adds a distinct behavioral detail, though the density makes it slightly harder to scan than a more concise alternative.

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 fully compensates for the missing output schema by detailing the findings packet (verbatim evidence, confidence, source, fetched_at, citation), gaps[], contradictions[], hop field, and timing. It covers prerequisites, limitations, and alternatives, making it extremely 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?

Even though the schema covers both parameters (question, depth), the description adds meaning: depth='quick'/'standard'/'thorough' with specific facet counts and hop behavior, and that 'question' may be broad/multi-part because decomposition is the point.

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

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

The description clearly identifies this as a multi-source research tool that decomposes questions, routes to 5,508 tools in parallel, and returns a findings packet. It explicitly distinguishes itself from open-web search and from the sibling ask_pipeworx by scope.

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

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

Explicitly states when to use (broad/multi-part questions over structured data) and when not to (single lookups, breaking/current news), naming alternatives like ask_pipeworx. It also specifies account requirements and depth-level trade-offs.

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 valuable behavioral details: it returns 'top-N most relevant tools with names, descriptions, and full input schemas' and notes 'no second schema lookup needed,' plus the strategic advice to call it first. This goes beyond the annotations without contradicting them.

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

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

The description is three sentences with front-loaded purpose and clear structure. The enumeration of domains is lengthy but useful for an agent deciding if this tool applies. No wasted words, though the domain list could be seen as slightly overlong; still, each part 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?

Despite lacking an output schema, the description fully covers what the tool returns (names, descriptions, full schemas, examples) and how to use it (call first for option set). It lists relevant domains and specifies the 'limit' behavior. This is a complete description for a discovery tool with good annotations.

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

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

The input schema already provides 100% description coverage for all 6 parameters, including aliases for 'query' and the 'limit' default/max. The tool description does not add significant parameter semantics beyond suggesting 'top-N' (which aligns with 'limit'). Since the schema does the heavy lifting, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Find tools by describing the data or task.' It specifies a broad set of domains (SEC filings, FDA drugs, etc.) and distinguishes itself as a meta-tool from the sibling domain-specific tools. The verb 'find' and resource 'tools' make 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: 'Use when you need to browse, search, look up, or discover what tools exist.' It also gives a strong directive: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This implies alternatives (the specific tools) and provides clear context for when this tool is preferable.

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, the description reveals important behaviors: parallel fan-out (ONE parallel call), fallback chain (GDELT→GNews), and a soft-fail for patents until May 2025. Also clarifies that names are not supported. These are critical operational details not otherwise available.

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

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

The description is long but dense with necessary information. It is front-loaded with trigger examples and structured by return field groups. It avoids fluff, but the density makes it slightly harder to parse at a glance; a short bulleted list could improve scanability.

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

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

Given there is no output schema, the description covers all essential context: input constraints, exact outputs, data sources, failure behavior, and alternatives. It even specifies URI templates for filings. This is comprehensive for a read-only aggregation 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?

The schema already covers both parameters with 100% description coverage, so the bar is baseline 3. The description adds value with concrete examples ("AAPL", "0000320193") and reinforces the zero-padded CIK requirement, providing operational clarity beyond the schema text.

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 ("Tell me about X" / "research Acme") and clearly states it produces a 'full cross-source profile of a US public company in ONE parallel call.' It enumerates exact return fields (cik, company_name, recent_filings, fundamentals, patents, news, LEI), distinguishing it from sibling tools like resolve_entity (which handles name resolution) and 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?

Explicit guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' tells the agent when to use it. It also specifies an alternative: 'use resolve_entity first if you only have a name.' This gives clear positive and negative use conditions.

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 destructive (destructiveHint=true) and idempotent (idempotentHint=true). The description adds context about what is deleted (previously stored memory) and why (stale, done, sensitive), 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?

Two sentences: one for the action, one for usage guidance. No filler, front-loaded key 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 one-parameter tool with rich annotations and no output schema, the description fully covers purpose, usage, and relationship to siblings. No missing critical information.

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

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

Schema covers the required 'key' parameter with description 'Memory key to delete', so coverage is 100%. The description adds no further format or usage details for the key, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Delete') and resource ('a previously stored memory') with a mechanism ('by key'), clearly distinguishing it from sibling tools like remember and recall.

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

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

Explicitly states when to use it: on stale context, completed tasks, or clearing sensitive data. Also names related tools (remember, recall) for pairing, providing integrated guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the return format (array of SteamID64s and relationship status) and the filtering behavior, which go beyond annotations.

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

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

The description is two tight sentences, front-loaded with the primary action, then the optional filter, then the return type. Every word earns its place, with no repetition 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?

For a simple list tool with strong annotations and an output schema, the description covers the operation, parameters, filtering, and return value. It provides all necessary context to invoke the tool correctly without needing pagination or error details.

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 no schema descriptions (0% coverage), the description compensates by explaining both parameters: steamid is a SteamID64 and relationship filters to 'friend' or 'all'. It leans on the description for semantics but doesn't detail the exact format of SteamID64 beyond the name.

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

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

The description clearly states the tool lists a Steam user's friend list by SteamID64, with optional relationship filtering. The verb 'List' plus the specific resource 'friend list' and the return of SteamID64s and relationship status distinguish it from sibling tools like player_summaries or resolve_vanity_url.

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 clear usage: when you need a Steam user's friends, pass a SteamID64 and optionally filter by relationship. It doesn't explicitly name alternatives or exclusions, but the purpose is unambiguous and aligns with only this tool among siblings.

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

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

Annotations already declare readOnly, openWorld, and idempotent hints. The description adds valuable process details: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format' and describes the output as a 'single text blob'. This goes beyond the basic safety profile, though it doesn't discuss rate limits or error handling.

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 of core content plus a use case list, all front-loaded and factual. Every sentence serves a purpose—what, how, output, and when to use—without 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?

For a moderate-complexity tool with two well-documented parameters and no output schema, the description covers purpose, process, output type, and use cases. It clearly explains the output format ('standard llms.txt markdown format', 'single text blob'), making it sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, with both 'url' and 'max_links' fully documented. The description doesn't add parameter-specific information beyond what the schema already provides, so 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 states a specific verb ('Generate'), resource ('llms.txt file'), and scope ('for any URL'), making the tool's purpose unmistakable. While it doesn't explicitly name sibling tools, the function is so distinct that differentiation is implicit.

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

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

The description provides clear context by listing three concrete use cases ('getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor'). However, it doesn't explicitly mention when not to use this tool or suggest alternatives, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, establishing the safety profile. The description adds useful behavioral context by specifying the return fields and that it lists 'active subscriptions' (implying inactive ones are excluded by default). It does not contradict 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 two sentences. The first sentence states the primary function, and the second lists return fields and usage guidance. Every sentence adds value, with no redundancy or irrelevant 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 simple read-only list tool with one optional parameter and no output schema, the description is adequately complete. It covers what the tool returns, the intended use cases, and the read-only nature via annotations. Minor gaps like pagination or ordering are not critical for this use case.

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

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

The single parameter include_inactive has a complete schema description ('Include cancelled subscriptions in the response (default false)'), giving 100% schema coverage. The tool description does not add extra parameter details, but the schema already provides sufficient meaning, so the baseline score of 3 applies.

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

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

The description uses the specific verb 'List' with the resource 'the caller's active subscriptions', and details the returned fields (id, type, params, created_at, last_fired_at, fire_count). It clearly distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on listing existing subscriptions.

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

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

The description provides explicit usage contexts: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This tells the agent when to call this tool, though it doesn't explicitly mention when not to use it or point to alternative tools. The context is clear enough for proper selection.

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

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral details: it returns specific fields (appid, playtime_forever in minutes, and per-game metadata) and notes optional inclusions. This provides enough context beyond the safety hints, without redundancy.

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, front-loaded sentence that states the core action and then adds optional parameters and return fields. Every word contributes value; there is no fluff or repetition of what annotations already state.

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?

This is a simple, read-only list tool with an output schema, so the description does not need to detail return structures. It covers the essential aspects: input (SteamID64), optional flags, and key output fields. It does not mention pagination or rate limits, but for this basic tool the description is adequately complete.

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

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

Given the schema has no property descriptions (0% coverage), the description compensates well. It explains steamid via the main sentence, and the optional parameters are conveyed through 'include app name/icon' and 'include free-to-play games'. The mention of 'playtime_forever (minutes)' also adds unit context. The mappings are clear, though not explicitly named.

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

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

The description clearly states the tool lists all games owned by a SteamID64, with a specific verb and resource. It also distinguishes itself from siblings like recently_played by focusing on the full owned-game library, and optionally includes app info and free-to-play status. This makes the purpose unambiguous and differentiated.

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 primary use case is explicit: retrieve all games owned by a given SteamID64. The description also clarifies optional behaviors (including app info and free-to-play games) that adjust the query. However, it does not explicitly compare against alternatives like recently_played or friend_list, so there is no exclusionary guidance, only clear 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 are sparse (all false), but the description adds rich behavioral context: rate-limited to 5 per identifier per day, free and not counted against quota, returns a claim_token when filed without an account, and explains the follow-up flow. This goes far beyond the annotations without contradicting them.

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

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

Though long, every sentence earns its place: purpose, use cases, exclusions, claim_token flow, rate limit, and cost are all covered. Information is front-loaded with the core purpose first, then operational details, making it 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 complexity (nested context object, 0 required params, no output schema), the description fully covers what the agent needs: how to invoke, what to include, what to expect in return, and constraints. The sibling list contains many unrelated tools, so the clear exclusions are especially valuable.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful detail for claim_token ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and clarifies that it should be used alone. This elevates parameter 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 opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this from the many sibling tools by focusing on feedback about the Pipeworx connection itself, not data retrieval or analysis.

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

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

Explicitly states when to use the tool (bug, feature, data_gap, praise) and when NOT to use it (feedback for other MCP servers), including a disambiguation rule ('Pipeworx tool names are the ones this connection lists'). Also gives guidance on using claim_token for follow-up.

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

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

Annotations already declare read-only/idempotent, and the description adds valuable context: caching ('Cached 5min-1h'), data source ('derived from CF analytics-engine'), no PII, and self-aggregating nature. This goes beyond the annotations nicely, though it doesn't cover potential rate limits or error behavior.

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

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

The description is well-structured: a clear opening statement, a numbered list of use cases, and a concise technical note. It's longer than strictly necessary but 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?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers what it returns, when to use it, and behavioral nuances like caching. No critical context appears missing.

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

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

The schema covers the window parameter 100% with enum and description. The tool description adds interpretive guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This extra semantic meaning justifies a score above the baseline 3.

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

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

The description clearly states the tool's function: 'What other AI agents are calling on Pipeworx right now' and explicitly lists outputs ('top tools, top packs, and total call volume'). It distinguishes itself from siblings like discover_tools by emphasizing popularity/trending rather than general discovery.

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

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

Provides explicit use cases: discovering hot data sources, confirming canonical tool choice, and aligning with agent needs. Does not explicitly mention when not to use or mention alternatives, but the use cases are concrete enough to guide selection among the many sibling tools.

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

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

The description adds no behavioral context; annotations already provide readOnly and idempotent hints. It does not disclose any additional traits such as returning a list, language behavior, or what happens if no achievements exist. However, since annotations cover safety, the description's lack of extra context is somewhat mitigated, but it still fails to describe the operation.

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

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

The description is a single short phrase, but it is under-specified rather than concise. It lacks substance and does not earn its place; it is essentially a title, not a functional description.

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 the existence of an output schema and annotations, the description is completely inadequate for a tool with two required parameters. It does not explain what data is returned, how to format a call, or any prerequisites, making it insufficient for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description must explain the parameters but only says 'Achievements for a game.' It does not define appid, steamid, or l, nor any relationship between them. Examples in schema are not part of the description text, so no parameter meaning is conveyed.

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 'Achievements for a game' is a noun phrase that essentially restates the tool name/title without a verb or clear action. It does not specify whether it retrieves, lists, or summarizes achievements, and provides no differentiation from sibling tools like player_stats or player_bans.

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 on when to use this tool versus alternatives. It does not mention required inputs (steamid, appid) or any context like needing a specific Steam ID. The description offers no explicit or implicit usage scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, so the safety profile is clear. The description adds behavioral details beyond annotations: it accepts one or more comma-separated SteamID64s and returns specific fields (CommunityBanned, VACBanned, NumberOfVACBans, DaysSinceLastBan). This adds useful context about invocation style and output.

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

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

The description is two sentences, with the primary action and resource in the first sentence and a concise list of return fields in the second. No filler or repetition. It is front-loaded and 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?

The tool is simple with a single parameter, and an output schema exists (covering return values). The description fully specifies the input format and the output fields, making it self-sufficient for an agent. Given the low complexity and annotations, no additional context is needed.

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

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

The schema only defines 'steamids' as a string with no description (0% coverage). The description compensates fully by explaining the expected format: 'one or more comma-separated SteamID64s'. This is critical for correct invocation, and the schema example reinforces it. The description adds essential meaning beyond the bare 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 identifies the tool's purpose: checking VAC, community, and economy ban status for SteamID64s. It names the specific resource (ban status) and the verb (check), and the output fields are listed. It distinguishes from sibling tools like player_summaries or player_level by focusing specifically on bans.

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 the tool should be used when ban information is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or legacy considerations. The clarity of the tool name and description provide some context, but explicit guidance on alternatives is missing.

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, covering the safety profile. The description adds no behavioral context beyond the basic return type, which is already covered by the output schema. No contradiction exists.

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

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

The description is a single, front-loaded sentence that contains no filler. Every word contributes directly to understanding the tool's purpose and required input.

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 getter with one parameter, the description, combined with annotations and output schema, provides enough context to use the tool correctly. A minor gap is the lack of mention of error handling for invalid SteamID64s, but this is not critical for basic usage.

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

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

The schema has 0% description coverage for the sole parameter 'steamid'. The description adds 'SteamID64', specifying the expected ID format, which is a meaningful clarification over the bare schema. However, it does not elaborate on formatting or validation rules.

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 ('Return') with a clear resource ('Steam Community level') and the input format ('SteamID64'). It distinguishes itself from sibling tools like player_summaries or player_achievements by focusing solely on the level.

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 usage for retrieving a player's level but does not explicitly state when to use this tool over alternatives (e.g., player_summary) or mention any prerequisites. Context is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. However, the description adds nothing about rate limits, required auth, or what data is returned; it's a bare statement with no behavioral context beyond what annotations already provide.

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

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

The description is a single short sentence, but it doesn't earn its place as it provides minimal information. This is under-specification, not effective conciseness, since the sentence adds little value beyond 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?

Even though an output schema exists, the description fails to orient the agent about what 'stats' means, how it differs from similar tools, and what the expected use case is. For a 2-parameter tool within a rich sibling set, this is incomplete and would require the agent to guess or explore.

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 0%, so the description carries the full burden for explaining steamid and appid. It only says 'for a game,' which weakly hints that appid is the game identifier, but neither parameter is explained beyond its name, leaving unclear 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 'User stats for a game' is a noun phrase that essentially restates the title 'Player Stats' with synonyms. It lacks a specific verb and doesn't specify what kind of stats are included, making it hard to distinguish from sibling tools like player_achievements or player_summaries.

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 on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to guess which player-related tool fits the query.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful context beyond annotations: the 'public' qualifier for profiles, the batch limit of 100, and the return fields, enriching the behavioral picture without contradicting 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 a single sentence that packs in purpose, constraints, and return values with no redundancy. Every clause adds essential information, making it highly efficient and well-structured.

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

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

For a tool with one parameter and an output schema, the description covers all necessary context: what it does, the batch limit, the public nature of data, and the returned fields. Annotations cover the safety profile, and the output schema handles return structure, so no critical gaps remain.

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

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

The schema provides only a type of 'string' for steamids with 0% coverage. The description fully compensates by specifying the exact format (comma-separated), the ID type (SteamID64), and the maximum of 100 per request, giving the agent precise guidance on constructing valid input.

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 fetches public Steam profiles for up to 100 comma-separated SteamID64s in one request, and lists the specific returned fields (persona name, avatar, country, status). This identifies a specific verb and resource, and the batch nature distinguishes it from the singular sibling player_summary.

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 usage for batch lookups by specifying 'up to 100 comma-separated SteamID64s in one request', giving clear context for when to use it. However, it does not explicitly contrast with alternatives like player_summary or state when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the 'public' qualifier but does not disclose additional behavioral traits such as rate limits, error behavior, or authentication needs. It does not contradict 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 one sentence, front-loaded with the action and resource, and lists output fields without any filler. Every word 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 one parameter and an output schema exists, so the description covers the essential return data and use case. It does not address edge cases like invalid IDs or private profiles, but the 'public' qualifier sets expectations. Overall, it is complete enough for an agent to invoke correctly.

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

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

The input schema only defines a required string 'steamid' with no description. The description's 'single SteamID64' tells the agent the type of identifier expected, adding meaning beyond the bare schema. It could be improved by providing format examples or constraints, but it is sufficient for the single-parameter tool.

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 the specific verb 'Fetch' and identifies a precise resource: 'public Steam profile for a single SteamID64'. It also enumerates the returned fields, making it easy to distinguish from sibling tools like player_summaries by emphasizing 'single'.

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 implies its use case: fetching a single public profile by SteamID64, which distinguishes it from plural-oriented siblings like player_summaries. However, it does not explicitly state when not to use this tool or mention alternatives by name.

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

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

Annotations already declare readOnly/openWorld/idempotent, but the description adds significant beyond-annotation behavior: fill-check semantics ('realizable_edge_pp ≤ 0 means the overround exists only at last-trade... do not trade it'), Jaccard similarity threshold of ≥0.30, placeholder filters, and response structure. No contradiction exists.

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

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

The description is long but every sentence contributes operational detail—modes, filters, fill-check, response fields—with no repetition or fluff. It is front-loaded with the core purpose and usage, then dives into edge cases only where needed.

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

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

Although there is no output schema, the description covers response fields (opportunities[], partition_check), fill-check behavior, placeholder filtering, and similarity thresholds. It fully equips an agent to decide when to call this tool and interpret results, given the tool's complexity.

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

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

Even though schema coverage is 100%, the description enriches both parameters with concrete examples ('fed-decision-may-2026', 'Strait of Hormuz traffic returns to normal') and explains the mode-specific behavior for event vs topic. It also documents the no-arg default.

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 concrete verb and mechanism: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly enumerates three modes (trending_scan, event, topic), distinguishing it from sibling tools like polymarket_fill_risk and polymarket_edges.

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

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

Explicit calling conventions are given: 'Call with NO args for a trending_scan', 'pass event', 'pass topic'. It also recommends which mode to use ('event (recommended for a specific market)') and redirects custom sizing to polymarket_fill_risk, making alternatives and when-to-use clear.

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

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

While annotations already declare read-only, idempotent, and non-destructive behavior, the description adds substantial context: caching at the KV level keyed on all knobs, diagnostics to explain why segments are empty, per-model-family details (including alpha values and thresholds), the 24h-move warning, and the rare-by-design nature of concentrated longshots. It also clarifies the fed-bet exclusion rationale. No contradictions with annotations.

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

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

The description is long but well-structured with explicit segment headers and lists. It is front-loaded with the core purpose and quickly moves into actionable details. Some content is repeated (e.g., kelly_fraction details appear twice) and the alpha constants could arguably live in schema, but every section earns its place given the tool's complexity.

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

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

With no output schema, the description carries full burden of explaining return values, which it does thoroughly: top-level by_segment structure, diagnostics, fed_note, and per-opportunity fields (edge_pp_net, kelly_fraction, liquidity, etc.). It also explains the meaning of empty segments and the effect of knobs. This is a complete picture for an agent to use the tool effectively.

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 meaning beyond the schema by grouping knobs as 'tradeable-edge knobs,' explaining the rationale behind defaults (e.g., slippage_pp references Polymarket's zero fees and typical 20-50bp costs), and clarifying the interaction between min_kelly and min_partition_leg_kelly for partition arbs. This is more than mere restatement.

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

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

The description opens with a specific verb and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It clearly states the tool's purpose as a discovery mechanism for betting opportunities, and distinguishes itself by noting it avoids paging hundreds of markets. The three response segments further clarify the scope.

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

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

The description explicitly frames usage as 'what should I bet on today' and explains that it discovers opportunities without scanning hundreds of markets, implying it is the go-to screening tool. It also provides a specific exclusion note about fed bets being unreliable and excluded from ranking, which is a clear usage caveat. However, it does not name sibling alternatives or explicitly state when another tool should be used instead.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false), the description richly discloses behavior: snapshots are written only on cache-miss so gaps are meaningful, history depth is bounded by a 60-day TTL, and decay is computed from daily closes net of default slippage, not intraday. This adds substantial non-obvious 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 extremely dense and well-structured, with RESPONSE and LIMITS sections clearly delineated. The opening sentence immediately states the tool's core purpose, and every sentence adds information. It is slightly verbose in terms of length but justified by the complexity.

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

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

For a complex telemetry tool with no output schema, the description is remarkably complete: it enumerates the output fields (tracked, expired, snapshot_dates), explains each one's meaning, notes boundary cases (snapshot gaps, TTL, not intraday), and gives practical trading guidance. Nothing important is left unstated.

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

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

Schema coverage is 100%, but the description adds important semantics beyond the schema: it explains days default and clamp, the window snapshot family concept, and the meaning of the edge_pp_net time-series. It also clarifies that negative edge values indicate SELL YES, which is critical for interpreting the response.

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 gives a specific verb and resource: 'edge persistence and decay telemetry built from daily polymarket_edges snapshots,' and clearly answers a concrete question ('how long has this edge existed and is it shrinking?'). This distinguishes it from sibling tools like polymarket_edges by focusing on time-series persistence rather than raw edge snapshots.

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 strong contextual guidance: it explains the trading implication of edge age ('a fresh wide edge and a 3-week-old wide edge are different trades') and details the response fields and limits, giving the agent clear clues about when this tool is appropriate. However, it does not explicitly name alternative tools or state when NOT to use it, so it falls slightly 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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description discloses extensive behavior: it walks the order-book ladder, returns specific metrics (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd), and explains the risk of partial basket fills converting an arb into directional risk. This goes far beyond what annotations alone convey.

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

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

The description is long but well-structured with clear SINGLE-MARKET and BASKET sections. Every sentence carries substantive guidance, but it could be slightly trimmed for brevity. The front-loaded purpose sentence and the explicit 'USE THIS' directive make it actionable despite the length.

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

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

Despite having no output schema, the description enumerates all key return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk). It also covers all four parameters, default behaviors, and safety warnings, making it fully self-contained 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?

Even though the schema has 100% parameter description coverage, the tool description adds significant semantics: it explains the dual-mode interpretation of `side`, clarifies that `size_usd` means 'max spend' for buys and 'target proceeds' for sells, and for basket mode defines `size_usd` as settlement notional S with shares paying $1. It also documents the default (1000) and clamp range (10–1,000,000), which the schema omits.

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

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

The description clearly states the tool's function: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It specifies two modes (single-market and basket) and explicitly distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by positioning itself as the pre-trade risk check for those 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?

The description provides explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why it's necessary (theoretical overround on thin books is not capturable; partial basket fills create unhedged directional risk), which effectively communicates when alternatives are insufficient.

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

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

The description goes well beyond the annotations by disclosing edge-case behaviors: safety fields (compatibility_warning, temporal_alignment), counters (skipped_cross_type/subtype), and the meaning of matched_pairs:0. It explicitly warns that most pre-mapped topics return compatibility warnings, which is critical for setting expectations. This is a model of behavioral transparency.

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

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

The description is lengthy and dense, but every sentence carries informative value. It is front-loaded with the core purpose and then systematically covers modes, response, and safety caveats. It could be improved with better visual structure (e.g., bullet points), but it avoids repetition and under-specification, making it appropriately thorough 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 no output schema, the description compensates by detailing the response contents (leg-by-leg prices, spread, compatibility_warning, temporal_alignment, skipped counters). It also covers failure modes and multi-venue nuances. This makes the tool's behavior fully understandable without requiring external documentation.

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

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

The input schema simply lists parameters with terse descriptions, but the tool description explains how they interact: topic is a pre-mapped shortcut, while kalshi_event_ticker and polymarket_event_slug explicitly override the mapped side. This adds meaningful semantics beyond the schema, especially the relationship between modes and parameter precedence.

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

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

The description opens with a clear verb+resource statement: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It distinguishes itself from sibling Polymarket tools by focusing specifically on cross-venue spreads and explicitly describes two modes of operation. The scope is 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?

It provides explicit guidance on when to use the tool (tracking spreads across venues, with two modes) and when not to trust the output, e.g., 'pre-mapped ≠ tradeable', compatibility_warning scenarios, and temporal_alignment false. This effectively tells the agent when the tool is meaningful and what exclusions apply.

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

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

Adds scoping to user identifier (anonymous IP, BYO key hash, or account ID) and the omit-key-to-list behavior, going beyond the readOnly/idempotent annotations; no contradiction.

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

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

Two dense, front-loaded sentences conveying purpose, usage, scoping, and workflow without fluff.

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

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

For a simple tool with one param and no output schema, the description adequately covers purpose, usage, scoping, and companion tools, making it complete enough for effective selection and invocation.

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

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

Schema already fully documents the key parameter with 100% coverage; description reinforces the omit-to-list behavior but adds little beyond the schema's own 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?

States it retrieves a value saved via remember or lists all saved keys, using specific verb+resource and distinguishing from sibling remember/forget tools.

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

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

Explicitly provides when to use (look up saved context like ticker/address/notes) and mentions companion tools remember/forget, giving clear guidance vs alternatives.

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

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

The description contradicts the readOnlyHint annotation by disclosing a mutating side effect: setting mark_read:true flags events as read, which changes the feed state for subsequent calls. Since readOnlyHint=true promises no state modification, this is an annotation contradiction, warranting a score of 1.

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 composed of five efficient sentences, each adding distinct value: purpose, return contents, filtering, mark_read effect, and polling/HTTP alternative. It is front-loaded with the core purpose and avoids fluff, making it easy to scan while remaining informative.

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 appropriately explains the return payload (source, citation_uri, raw event payload). It covers key behavioral aspects like filtering and mark_read, and even notes an HTTP endpoint. However, it does not mention unread_only or error conditions, but these are less critical given the schema coverage. Overall, it is sufficiently complete for a read-oriented list 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 the baseline is 3. The description adds value beyond the schema by explaining the effect of mark_read (next call only shows newer events) and providing a concrete type example ('sec_8k'). It does not elaborate on limit or unread_only, but the schema already covers them. This extra context justifies a 4.

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

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

The description clearly states the tool pulls fired events from the subscription feed and returns recent alerts written by the evaluator. It specifies the resource (subscription feed), the operation (pull/return), and the returned contents (source, citation_uri, raw payload). This distinguishes it from siblings like list_subscriptions, which likely lists subscriptions rather than alerts.

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

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

The description provides clear context for when to use the tool: polling works fine, and it explains filtering by type and since, plus mark_read behavior. It also mentions an HTTP alternative for external scripts, which is a form of alternative guidance. However, it does not explicitly mention when not to use this tool vs. other MCP tools, 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?

The description discloses significant behavioral details beyond annotations: fan-out to SEC EDGAR, GDELT→GNews fallback with rationale (rate limits/5xx), USPTO patents with soft-fail due to PatentsView API sunset, and the structured output format. This enriches the readOnly/idempotent hints with concrete operational 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 dense but every sentence earns its place—starting with user intent examples, then source behavior, parameter semantics, output format, and alternative tool. There is no filler; the length reflects the complexity of a multi-source feed 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?

Since there is no output schema, the description fully specifies return values (structured changes[] grouped by source, total_changes count, pipeworx:// citation URIs). It also covers data sources, failure modes, parameter formats, and the alternative entity_profile, making it self-contained for agent invocation.

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

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

Although the schema covers all three parameters with 100% description coverage, the tool description adds meaningful guidance: 'since' accepts ISO format or relative shorthand with concrete examples, recommends '30d' or '1m' for typical monitoring, and clarifies 'value' can be a ticker or CIK. This goes beyond the schema's basic descriptions.

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

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

The description immediately identifies the tool as a change feed for a company in a recent window, with multiple natural language examples ('What's new with X'). It explicitly contrasts with entity_profile by clarifying that recent_changes is for windowed changes while entity_profile is for static profiles, clearly distinguishing from that sibling 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?

Provides explicit when-to-use guidance via example queries and states the alternative: 'Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.' Also details fallback behavior (GDELT→GNews) and indicates typical monitoring use ('30d' or '1m'), giving clear context for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description does not need to restate safety. It adds behavioral context beyond annotations by specifying the time range (last two weeks) and the return fields (playtime in last 2 weeks and total playtime), which helps the agent understand what to expect.

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 sentence that is front-loaded with the action and resource, followed by output details and the optional parameter. Every word earns its place; there is 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?

Given the tool's simplicity, the annotations, and the presence of an output schema, the description covers the essential purpose, parameter semantics, and scope. Minor ambiguities (e.g., exact sorting or zero-playtime handling) are not critical for a read-only, idempotent 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?

The input schema has 0% description coverage, so the description must compensate. It does: 'SteamID64' clarifies the steamid format, and 'Optional count caps results' explains the count parameter's effect. This adds meaningful semantics beyond the bare 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 action ('List games played'), the target resource ('by a SteamID64'), and the time scope ('in the last two weeks'). It also mentions the included playtime data, making it distinct from owned_games and other Steam tools. This is a specific verb+resource+scope formulation.

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 the tool's use case (recently played games in a two-week window) but does not explicitly state when to use it over alternatives like owned_games or player_stats. It provides clear context but no exclusions or comparisons to sibling tools.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context: key-value scoping, retention periods (24 hours for anonymous), and cross-session persistence. It does not detail overwrite semantics, but the idempotentHint covers that, and the additional context goes beyond the annotations.

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

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

Three sentences, each serving a distinct purpose: stating the core function, providing usage triggers, and explaining storage semantics. No fluff or redundancy, perfectly 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 simple tool with two parameters and no output schema, the description covers purpose, usage, persistence behavior, authentication differences, and sibling relationships. Nothing essential is missing, making it complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with examples for both parameters, giving a baseline of 3. The description enriches this with domain-specific examples (ticker, address, preference) and clarifies that the value is arbitrary text, adding meaningful context beyond the schema.

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

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

The description uses the specific verb 'Save' and identifies the resource as data for later reuse, clearly distinguishing it from siblings like recall and forget, which are explicitly paired. This is a specific verb+resource statement with clear sibling differentiation.

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

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

It provides explicit when-to-use guidance ('when you discover something worth carrying forward') and names companion tools (recall, forget) for retrieval and deletion, making the selection criteria unambiguous. It also notes the persistence difference for authenticated vs. anonymous sessions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds behavioral details beyond that: it returns specific fields (ticker, CIK, company_name, RxCUI, ingredient, brand) plus citation URIs, mentions internal cascading lookups and auto-disambiguation. This adds context 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?

The description is well-structured and front-loaded with query examples that immediately clarify purpose. Every sentence adds value: supported types, return details, citation URIs, and a note that it replaces multiple lookups. No redundant or filler content.

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

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

Given there is no output schema, the description fully covers what the tool returns for both entity types, including citation URIs. It also clarifies input formats and disambiguation behavior, making the tool's usage and output predictable. The mention of internal cascading helps set expectations about 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 enriches parameter meaning by explaining how each parameter is used per type: for 'value' it lists ticker/CIK/name examples and brand/generic examples, and for 'type' it clarifies the two enum options with their respective outputs. This goes beyond the schema's minimal 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 resolves user-spoken names to canonical/official identifiers for company and drug types, with concrete examples like 'What's the ticker for…'. It explicitly distinguishes from siblings like resolve_vanity_url by specifying supported types (company, drug) and the return format (ticker, CIK, RxCUI).

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

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

The description gives explicit usage guidance: 'Use FIRST whenever you have a name but need an ID.' It also details accepted input formats per type (ticker, CIK, name for company; brand/generic for drug), making it clear when to invoke. It doesn't explicitly mention when not to use it, but the guidance is strong enough for correct selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. However, the description adds no behavioral context beyond the conversion—no error handling, response format, or API specifics. With annotations present, the safety profile is covered, but the description itself is thin.

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

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

The description is extremely concise with a clear arrow notation, containing no filler. However, the brevity verges on cryptic—it could be slightly expanded without losing efficiency, so it earns a 4 rather than a 5.

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

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

Despite having annotations and an output schema, the description is incomplete. It doesn't provide usage context, input formatting guidance, or behavior for invalid/unknown vanity URLs. The presence of a sibling resolve_entity tool makes differentiation even more necessary, which the description fails to address.

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 0%, so the description must carry the burden of explaining parameters. 'Vanity URL' identifies the input type, but it doesn't clarify whether to provide the full URL or just the custom name, nor any format constraints. The schema example helps, but the description itself provides minimal semantic detail.

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

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

The description 'Vanity URL → SteamID64' clearly specifies the transformation the tool performs, identifying both input and output. It distinguishes itself from sibling tools like resolve_entity by focusing on the vanity URL to SteamID64 mapping.

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 no guidance on when to use this tool versus alternatives such as resolve_entity. There is no mention of prerequisites, exclusions, or contextual scenarios, leaving the agent to infer usage from the name alone.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds meaningful orchestration context: it calls ai_visibility_check per entity and returns a ranked list with score, confidence, and signal density, which goes beyond the annotations.

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

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

Three concise sentences, front-loaded with the primary action, includes a concrete example, and contains no redundant or tangential 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?

No output schema is present, so the description must specify the return shape, which it does (ranked list with score, confidence, signal density). Input details like model selection and API key are fully documented in the schema, and the overall workflow is clear enough for a tool of this complexity.

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

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

Schema coverage is 100% with all parameters described. The description reinforces that the first entity is the 'subject' and context is shared across probes, but adds little new semantic detail beyond the schema, so 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?

Description uses specific verb 'Compare' and resource 'AI visibility across multiple entities side-by-side', clearly distinguishing from single-entity ai_visibility_check and generic compare_entities. It also states the tool probes each entity with ai_visibility_check and ranks results, making its function unambiguous.

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

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

Explicitly frames usage as 'competitive AI-marketing audits' with an example question, and implies it's the multi-entity counterpart to ai_visibility_check. However, it doesn't explicitly state when not to use it (e.g., for single-entity checks), so a clear exclusion is missing.

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, but the description adds valuable context: composite fan-out across multiple services, partial-failure degradation with graceful timeout handling, and the 5-30s delay for first bundlephobia measurement. 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 dense but every sentence earns its place: purpose, usage triggers, return fields, scope, and failure behavior. It is front-loaded with the primary purpose and reads as a well-organized summary for a complex composite 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?

Despite having no output schema, the description lists the return summary block fields, mentions per-advisory detail and links, explains the NPM-only limitation, and details timeout behavior. This fully equips the agent to understand what the tool returns and how it behaves under partial conditions.

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 parameters are fully documented. The description adds minimal new parameter semantics—'package' is npm package name and 'version' defaults to latest, both already in the schema. Baseline 3 is appropriate as the description does not need to compensate.

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

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

The description clearly states it is a composite 'should I add this npm package to my project' check that fans out across deps.dev and bundlephobia. The verb 'check' with resource 'npm package' is specific, and the composite nature distinguishes it from sibling tools like deep_research or validate_claim.

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"' and also states the NPM-only scope with alternatives for other ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'). This provides clear when-to-use and when-not-to-use guidance.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals substantial behavioral traits: it returns 'top-N passages with character offsets and similarity scores,' uses 'BGE-base-en embeddings + cosine over 500-char overlapping windows,' and enforces a '200K chars' cap with truncation flagged. This gives the agent a vivid picture of what will happen when it invokes 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?

The description is four well-crafted sentences: it states the core function, the returned data, the use case, and the technical constraints. Every sentence carries distinct value, and none are redundant or verbose despite covering rich detail.

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

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

With no output schema, the description must explain what the caller will receive, and it does: 'get back the top-N passages with character offsets and similarity scores.' It also covers the 200K-char cap and truncation behavior, making it complete enough for an agent to understand the tool's contract in any context.

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

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

Schema coverage is 100%, so the description need not explain each parameter, but it reinforces the meaning of 'text' and 'query' with examples (e.g., 'a SEC 10-K body' and query examples like 'supply-chain risk'). Still, it adds no new information about 'limit' or edge-case parameter formatting that the schema doesn't already provide, so it stays at the baseline for high coverage.

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

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

The description opens with a specific verb+resource+scope: 'Semantic search INSIDE a fetched record,' making the tool's function immediately clear. It further differentiates from siblings by emphasizing that the input is text already pulled from a record, not a database-wide search, which distinguishes it from tools like 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?

The description explicitly states when to use it ('Use when the record is too big to cram into the prompt') and provides an alternative workflow by pairing with ask_pipeworx_grounded ('fetch with the gateway, ground over the relevant passages instead of the whole document'). However, it lacks an explicit when-not to use or a direct comparison to other similar semantic search tools, so it stops short of fully exhaustive guidance.

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

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

The description discloses important behavioral requirements: requires OAuth account, phone verification, 10/day SMS cap, and the always-on feed. The idempotentHint is slightly ambiguous against 'new subscription id' but the description doesn't explicitly conflict; it adds value beyond the annotations by explaining verification and rate limits.

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

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

The description is dense but well-structured: it leads with the main action, then return value, auth requirement, supported types, and delivery options. Each sentence contributes useful information, though the delivery details are also duplicated in the schema, making it slightly redundant.

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 (5 subscription types, nested delivery object) and no output schema, the description covers the essential aspects: purpose, return value, auth, type-specific params, and delivery options. It doesn't explain how to manage subscriptions or what the output format looks like beyond the id, but sibling tools like list_subscriptions and unsubscribe cover those aspects.

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 provides 100% parameter descriptions with examples for all subscription types. The description reinforces this with examples like items:['5.02'] and delivery constraints (phone must be verified, 10/day cap), adding practical meaning beyond the schema's baseline.

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

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

The description clearly states a specific action ('Create a proactive monitoring subscription') targeting a defined resource ('live-data event stream'). It distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation, not listing or removal.

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 provides clear context for when to use: describes supported subscription types and delivery channels. It also references how to consume the feed (via recent_alerts or the public registry endpoint), giving practical guidance. However, it doesn't explicitly name alternative tools for other operations, but the sibling list implies them.

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 what the tool returns: category-bucketed example questions with tool+argument shapes, drawn from a live catalog. It also notes the optional `topic` parameter modifies the output. This adds meaningful behavioral context 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?

The description is fairly long but front-loaded with the purpose and includes the question list that helps an agent recognize when to invoke it. Every sentence adds value, though the opening query list could be trimmed slightly without losing essential meaning. Still well-structured.

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

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

Despite having no output schema, the description clearly conveys the return structure (category-bucketed example questions with tool+argument shapes) and the categories involved. It covers all necessary context for a simple optional-parameter tool: purpose, output, and usage timing.

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

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

The input schema already provides 100% coverage with a detailed description of the `topic` parameter including values and the default behavior. The description only restates this ('pass topic (e.g. "finance", "pharma", "betting") to focus'), adding no new semantics. 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 identifies this as the onboarding entry point for Pipeworx, returning category-bucketed example questions with the exact tool and argument shape. It distinguishes itself from siblings by explicitly stating 'Use this FIRST when you do not yet know what Pipeworx can do for you.'

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

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

The description provides explicit guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also explains how to vary behavior: 'Call with no arguments for the full spread, or pass `topic`.' This clearly separates it from alternatives like ask_pipeworx or discover_tools.

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

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

Beyond annotations (idempotentHint, destructiveHint false), the description discloses the soft-delete behavior ('row is deactivated (not deleted)') and the data retention consequence for recent_alerts. It also adds the ownership constraint, providing material context that annotations alone do not convey.

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

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

The description is two sentences, front-loaded with the primary action, and each sentence adds meaningful behavioral or constraint information. No redundant phrases 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?

For a simple single-parameter cancel operation, the description covers ownership, deactivation instead of deletion, and the historical data linkage. The lack of an output schema does not hurt, as the tool's side effects are clearly communicated. It feels complete for effective 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 description coverage is 100% for the single 'id' parameter, and the schema already explains it is a subscription UUID from subscribe. The description adds no further parameter nuance beyond the implicit 'by id' from the purpose, so baseline 3 is appropriate.

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

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

The description states 'Cancel a subscription by id' with a specific verb and resource, clearly distinguishing it from sibling tools like subscribe and list_subscriptions. It also adds scope ('your own subscriptions') and deactivation behavior, 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 implies usage context by stating ownership enforcement and the effect on historical events via recent_alerts. However, it does not explicitly name alternatives or exclusionary cases (e.g., 'use list_subscriptions to view subscriptions instead'), which keeps it from a 5.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile. The description adds substantial behavioral detail beyond that: the dual-path routing (SEC EDGAR/XBRL vs. grounded pipeline), the tolerance-based verdict system, and the claim that it replaces 4–6 sequential calls. This gives the agent a clear model of the tool's inner workings 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?

The description is well-structured, front-loading usage triggers and then explaining processing and return format. The list of natural-language paraphrases is slightly redundant but useful for an AI agent. Overall, it is comprehensive without unnecessary 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?

Despite no output schema, the description fully explains the return value (verdict, actual value with citation, reasoning), the two routing paths, and the tool's value proposition. Combined with the detailed input schema and annotations, the agent has everything needed to invoke and interpret results correctly.

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

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

The input schema provides 100% coverage of both parameters with rich descriptions, including examples and tolerance ranges. The tool description itself does not add parameter-specific meaning beyond what the schema already states, so 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 explicitly states the tool performs 'natural-language claim verification against authoritative sources' with a specific verb (validate/verify) and resource (claims). It clearly distinguishes from sibling tools like ask_pipeworx_grounded or deep_research by focusing on fact-checking with verdicts, not open-ended 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?

It gives explicit when-to-use guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It further subdivides usage by claim type (company-financial vs. other). However, it does not explicitly name alternative tools or provide when-not-to-use scenarios, 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.