Bungie

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds cost implications for Anthropic, return structure, and scoring range, which are useful beyond annotations.

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

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

Two sentences plus usage note, front-loaded with action and result. Every sentence adds value with no redundancy.

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

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

For a probe tool without output schema, description explains return values (per-model {score, confidence, signals, raw_response} + combined view), cost, and key handling. Comprehensive.

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

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

Schema coverage is 100% with clear descriptions. Description adds context (default model, API key usage, disambiguation purpose) but does not significantly enhance 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 clearly states the tool probes LLMs for knowledge and scores visibility (0-100). It distinguishes from siblings like compare_entities and scan_competitor_ai_presence by focusing on any brand/product/topic with a scoring 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?

Provides explicit use cases (AI-marketing audits, pre-launch checks, competitive monitoring) and mentions default vs. paid model options. Does not explicitly list when not to use or compare to siblings, but context is sufficient.

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

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

The description discloses important behavioral traits beyond the annotations: it routes to thousands of tools, auto-fills arguments, returns pipeworx:// citation URIs, and is described as fast and universally available. This adds context about the tool's internal routing and output format, though it does not detail potential failure modes or 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 verbose, containing lengthy lists, promotional phrases, and repeated encouragement (e.g., 'START HERE', 'one fast call'). While the information is useful, it could be tightened significantly without losing essential guidance.

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 return format (structured answer with citation URIs), usage scope, and alternatives. With no output schema, this is essential and mostly sufficient. It could mention handling for unsupported queries or how to interpret results, but overall it is complete for the tool's broad scope.

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

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

Schema coverage is 100% with the 'question' parameter and aliases clearly documented. The description adds value by giving varied examples and specifying that natural-language phrasing is acceptable, going beyond the schema's basic definition. It helps the agent understand the flexible input format.

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: it answers factual questions by routing to a large set of verified sources and returning structured answers with citations. It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, establishing a unique role as the default entry point.

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

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

The description provides explicit guidance on when to use the tool ('START HERE for most questions', 'PREFER OVER WEB SEARCH') and when to step up to alternatives (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions). It also includes concrete examples and trigger phrases.

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 valuable context beyond the annotations: it reveals the experimental nature, the current state (no active candidate, matching ask_pipeworx), and clarifies that it is a full working router. This goes beyond the readOnlyHint/openWorldHint/idempotentHint annotations by explaining the potential for behavior changes when a candidate routing improvement is under test. No contradiction with annotations.

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

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

The description is a single paragraph with front-loaded orientation ('Beta version of ask_pipeworx'). All sentences contribute relevant information, but some details like the exact retirement date (2026-07-26) and the phrase 'Falls back to nothing' are slightly verbose and could have been trimmed without losing meaning.

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 as an experimental variant, the description covers the relationship to ask_pipeworx, the current parity, and the usage context. It does not explain return values, but explicitly states the response shape is identical to ask_pipeworx. It doesn't mention potential risks of experimental routing (e.g., possible misrouting) beyond 'experimental edge', but overall it is complete enough 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?

The schema already documents all 6 parameters with complete descriptions (100% coverage), including aliases for 'question'. The description does not add any new parameter-level meaning; it only says 'same arguments' which references the overall tool, not individual parameters. 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 the tool as the beta version of ask_pipeworx, explaining it routes to the same 5,529 tools with the same arguments and response shape. It distinguishes it from the stable ask_pipeworx and other siblings by framing it as the experimental edge, though it does not explicitly state a primary verb like 'ask' or 'route'.

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 it exactly like ask_pipeworx when you want the newest routing.' It also mentions that results are compared against the stable router, implying ask_pipeworx for stable use, though it does not explicitly say 'don't use this if you need stable behavior.' The alternative is named, but the when-not 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?

Goes well beyond the readOnly/idempotent annotations by disclosing the additional LLM call, the explicit refusal mechanism with enumerated refusal_reason values, and the guarantee to use only tool-result content. This adds critical behavioral context for an AI agent.

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

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

The description is dense but well-organized: it opens with the core purpose, then details behavior, return values, use cases, and trade-offs. Every sentence adds value, and no filler is present.

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 explicitly defines the success and refusal response shapes, lists all refusal reasons, and explains the cost trade-off relative to the sibling. This gives an agent complete context for invoking the tool and interpreting results.

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

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

The schema already provides 100% coverage for all parameters, including aliases and natural-language guidance. The description adds no new parameter-level information, 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 this is a grounded, hallucination-resistant answer mode that extracts answers only from tool results, distinguishing it from the sibling ask_pipeworx. It specifies the exact behavior (routing, fetching, extracting) and output structure, making the tool's purpose unmistakable.

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

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

Explicitly says 'Use whenever an answer will be quoted, cited, or acted on' and names the alternative 'ask_pipeworx' for casual lookups, including a cost/benefit note about the extra LLM call. 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?

The description goes far beyond the annotations (which already indicate safe, read-only, idempotent behavior) by detailing resolution logic, fan-out strategies, response shapes, edge cases (low-confidence, closed markets, wide spreads), and resolution-rule risk. This level of disclosure significantly aids agent decision-making.

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?

While well-structured with clear sections, the description is verbose and contains extensive detail that could be condensed. The first sentence is effective, but subsequent paragraphs read more like documentation than a concise description, making it harder for an agent to quickly parse.

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, the description covers all necessary aspects: input types, resolution process, fan-out behavior, response structure, error states, and safety mechanisms. Despite lacking an output schema, the description explains return fields, satisfying the completeness requirement.

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 adds substantial value: it explains the 'depth' parameter with default value and example sizes, gives example inputs for 'market' (slug, URL, question text), and clarifies 'include_raw' with size estimates and use cases. This provides critical context beyond the schema definitions.

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

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

The description opens with 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call,' clearly stating the verb ('Research') and resource ('Polymarket bet'). It distinguishes itself from sibling tools like polymarket_edges by emphasizing a comprehensive, one-call research approach.

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

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

The description explicitly states when to use the tool: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It provides concrete usage examples. However, it does not explicitly mention when not to use it or directly compare with alternatives, though the context strongly implies 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 (readOnlyHint, idempotentHint, destructiveHint) already declare safe behavior. The description adds that the 'components' parameter controls which data blocks are returned, providing behavioral context beyond annotations.

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

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

Single sentence, 160 characters, clearly front-loaded with purpose. Every word adds value, no redundancy.

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

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

Given the rich annotations and existing output schema, the description adequately covers core functionality. It could include more detail on parameter types (e.g., membership_type enumeration), but overall it is sufficient.

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

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

Schema coverage is 0%, so the description must compensate. It mentions all four parameters and gives an example of component values (200=characters, 205=equipment). However, it does not describe membership_type or destiny_membership_id beyond naming them, slightly lacking depth.

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

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

The description uses a specific verb 'Fetch' and resource 'Destiny 2 character data', clearly identifying the tool's purpose. It distinguishes from siblings like 'profile' by targeting a single character with unique IDs.

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 explicit when-to-use or alternatives are provided. While the description implies usage when you have the specific IDs, it does not compare to sibling tools like 'profile' or 'search_destiny_player'.

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 clearly indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the agent knows this is a safe, idempotent read operation. The description adds no extra behavioral detail (e.g., rate limits, auth), but does not contradict annotations.

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

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

The description is extremely short (4 words), but lacks necessary information. While concise in length, it sacrifices completeness, making it insufficient for an agent to understand the tool's purpose.

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

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

The tool has one parameter and an output schema, but the description fails to convey what the output represents or how to use the tool effectively. The context is incomplete for a simple lookup 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 one required string parameter 'group_id' with no description. Schema coverage is 0%, and the tool description does not explain the parameter's meaning or format, forcing the agent to guess.

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 'Clan/group detail.' identifies the resource but lacks a verb (e.g., 'get' or 'retrieve') and does not specify what kind of detail is provided. The sibling tool 'clan_members' suggests differentiation, but the description does not distinguish itself.

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

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

No usage guidance is provided. There is no indication of when to use this tool versus alternatives like 'clan_members' or 'entity_profile', leaving the agent without 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, but the description adds no behavioral context (e.g., pagination via current_page). Minimal added value beyond annotations.

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

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

Extremely short but this is under-specification, not conciseness. Every sentence should add value; no sentence provides useful information beyond the title.

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 presence of an output schema and two parameters, the description is wholly inadequate. It fails to explain what the tool returns or how parameters affect behavior.

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

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

Schema description coverage is 0%, and the description entirely omits parameter meanings. Parameters group_id and current_page are undocumented, leaving their roles unclear.

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 'Clan members.' is a tautology of the title 'Clan Members'. No verb or resource action is stated, leaving the purpose ambiguous (e.g., list, get, update).

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 on when to use this tool versus siblings like 'clan'. The description provides no context on alternatives or prerequisites.

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 readOnlyHint, openWorldHint, and idempotentHint annotations, the description reveals that for type='company' it pulls 10-K financials from SEC EDGAR/XBRL with proper fiscal-year handling, and for type='drug' it pulls FAERS/FDA/active trial counts. It also notes sorted output and citation URIs, adding significant behavioral detail.

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 clear and front-loaded with trigger phrases, but it is somewhat verbose—three sentences plus examples could be slightly tightened while retaining all essential guidance.

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 mentions 'Returns paired data + pipeworx:// citation URIs per entity' and notes that results are sorted by main metric. Given the tool's complexity (two entity types, data sources, sorting), this is complete enough for reliable agent selection and invocation.

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

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

With 100% schema coverage, the description still adds value: it explains that 'company' pulls financial data while 'drug' pulls counts, and gives concrete examples for the values parameter (tickers/CIKs for companies, drug names). This enriches the schema definitions.

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

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

The description opens with natural-language triggers like 'Compare X and Y' and specifies a side-by-side comparison of 2–5 companies or drugs. It clearly distinguishes this from sequential single-pack lookups, making the purpose unmistakable.

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

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

The description explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also provides concrete example queries (which is bigger, rank these companies) that help the agent decide when to invoke the tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial context beyond these: account requirement, paid tier for thorough depth, return packet contents (verbatim evidence, confidence, source, fetched_at, citation_uri), guaranteed 'never invented' behavior, gaps[] and contradictions[] handling, semantic excerpting, and latency expectations. 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 lengthy but dense with unique operational information. It is front-loaded with the critical account requirement and core positioning before diving into details. While it could be slightly more structured with line breaks, each sentence 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 compensates by fully specifying what the agent will receive: a findings packet with verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, gaps[], hop field, contradictions[] for standard/thorough, and semantic excerpting. It also covers auth, latency, and edge cases, leaving no major ambiguity.

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 both parameters, and the schema already explains depth's enum values. The description adds practical context: question is natural language and broad/multi-part is fine, depth values have concrete facet counts (quick=3, standard=5, thorough=8) and behavioral differences, and thorough is paid. This complements the schema without repeating it.

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

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

The description states the tool does 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' and explains it decomposes questions into facets routed in parallel. It clearly distinguishes itself from ask_pipeworx (single lookup) and explicitly says it is NOT open-web search, providing a specific verb, resource, and 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?

Explicit when-to-use: 'Best for broad/multi-part questions over structured data' and 'For a single lookup use ask_pipeworx'. It also gives an exclusion for current-news topics by stating deep_research returns mostly empty gaps[] and to prefer ask_pipeworx. The account-required note with the fallback to ask_pipeworx adds a clear prerequisite and alternative.

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, establishing safety. The description adds valuable behavioral context: it returns top-N relevant tools with names, descriptions, full schemas, and curated examples, each ready to call directly. This goes beyond annotations by clarifying output format and call readiness. No contradiction.

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

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

The description is concise: a single paragraph that front-loads the main action ('Find tools by describing the data or task'). It efficiently covers purpose, usage guidance, and output details without unnecessary repetition. Could be slightly more structured (e.g., bullet points for examples), but it's clear and economical.

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 meta-nature and the absence of an output schema, the description provides sufficient context: it explains what the tool returns (tool names, descriptions, schemas, examples) and when to use it. Parameters are well-documented in the schema. The description covers the core behavior and boundaries. No major gaps remain.

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

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

Schema description coverage is 100%, so baseline is 3. The description reinforces that 'query' is a natural language description and provides examples (e.g., 'analyze housing market trends') but does not add new meaning beyond the schema. The schema already explains alias parameters and limit. Minimal extra value from description itself.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It provides concrete examples of domains (SEC filings, FDA drugs, etc.) and specifies that it returns top-N relevant tools with full schemas, ready to call. This distinctively positions it as a meta-tool for tool discovery, differentiating it from sibling tools like 'ask_pipeworx' or 'search_destiny_player.'

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

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

The description explicitly instructs: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear when-to-use guidance. While it doesn't name specific alternatives, the directive to use it first implies it's a starting point before selecting a specific tool. This is strong context for the AI agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds value by clarifying the operation scope, but no extra behavioral context is required.

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 (5 words) and front-loaded, but it sacrifices informativeness. It could be expanded slightly while remaining concise.

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

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

Given the presence of an output schema and rich annotations, the description is borderline adequate for a lookup tool. However, it lacks context about what a 'definition' is and how the hash is used, leaving some ambiguity.

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% and the description only mentions 'type + hash' without explaining their meaning or format beyond the example. This fails to compensate for the lack of schema descriptions for two non-obvious parameters.

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

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

The description 'Single definition by type + hash.' clearly states the action (get a single definition) and the resources (type and hash). It distinguishes itself from siblings like 'compare_entities' and 'entity_profile' by implying unique retrieval.

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

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

No explicit guidance on when to use or alternatives. The description implies usage for fetching one definition, but lacks when-not or comparison with siblings like 'resolve_entity' or 'search_within'.

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 include readOnlyHint, openWorldHint, idempotentHint. Description adds significant behavioral details: fans out across multiple sources, returns specific data fields, patents note about sunset, news fallback, parallel 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?

Description is a single dense paragraph; though front-loaded with examples, it would benefit from bullet points or clearer structure for scanning. Every sentence adds information, but readability is compromised.

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 exists; description lists all return fields (cik, company_name, recent_filings with URIs, fundamentals sorted, patents, news, LEI). Covers sources and structure but omits error conditions or data absence behavior. Reasonably complete for a complex multi-source 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% with descriptions. Description adds value by repeating key points in context (e.g., names not supported, zero-padded CIK example) but does not substantially exceed schema. Baseline 3, extra examples push to 4.

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

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

The description starts with explicit example queries ('Tell me about X', 'research Acme') and clearly states the tool returns a 'full cross-source profile of a US public company in ONE parallel call'. It distinguishes purpose from sibling tools like resolve_entity (name lookup) and compare_entities (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 states 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view'. Also advises to use resolve_entity if only a name is provided, and notes patents may soft-fail. 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral detail beyond 'components=205', which is unexplained. No mention of what happens during fetch or any side effects.

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

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

The description is very short (one sentence), but conciseness is undermined by lack of useful information. It is not front-loaded with key purpose; the only added detail 'components=205' is opaque.

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?

While an output schema exists, the description fails to explain what the tool returns or how the input parameters relate to the game context. For a tool with three required parameters and many siblings, this is insufficient.

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 three parameters (character_id, membership_type, destiny_membership_id) have 0% schema description coverage. The description does not explain what these parameters represent or how they should be used, leaving the agent to guess.

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 merely restates the tool name 'Equipped loadout' with a cryptic 'components=205'. It does not clarify that this retrieves a Destiny character's currently equipped items, nor does it distinguish the tool from siblings like 'character' or 'profile'.

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

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

No guidance on when to use this tool instead of alternatives. Sibling tools cover many related functions (e.g., 'character', 'profile', 'entity_definition'), but the description offers 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?

Annotations show destructiveHint=true and readOnlyHint=false, matching the delete behavior. Description adds context about clearing sensitive data, enhancing transparency beyond annotations.

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

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

Two concise sentences with no fluff, front-loaded purpose, and efficient use of words.

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

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

Given a single required parameter with full schema coverage, annotations, and no output schema needed, the description provides sufficient context for correct usage.

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

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

Schema has 100% coverage with parameter 'key' described as 'Memory key to delete'. Description does not add further meaning beyond schema, so baseline 3 applies.

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

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

Clearly states 'Delete a previously stored memory by key.' Specifies verb (delete) and resource (memory by key), and distinguishes from siblings (remember, 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 describes when to use: when context is stale, task is done, or to clear sensitive data. Mentions pairing with remember and recall, providing alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it fetches the page, extracts content, and outputs a specific format, providing behavioral context beyond annotations. No contradictions.

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

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

Two sentences plus a list of use cases, all front-loaded with the main purpose. Every sentence adds value with no redundant information.

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

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

Given no output schema, the description sufficiently explains the output format ('standard llms.txt markdown format' and 'single text blob'). It covers input, process, and outcome for the tool's simple 2-parameter interface.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions, which adequately define 'url' and 'max_links'.

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

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

The description clearly states the verb 'generate' and the specific resource 'llms.txt file', and explains the purpose of helping AI crawlers index a site. It distinguishes from sibling tools like 'ai_visibility_check' by focusing on producing a standard file format.

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

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

The description provides concrete use cases (client site indexing, own project, competitor auditing) as guidance. However, it does not explicitly mention when to avoid using this tool or contrast with sibling tools, which would make it 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, and destructiveHint=false, so the description's behavioral disclosure is limited. It confirms the fetch action but adds no further behavioral traits (e.g., pagination, rate limits, or output format). This is adequate given the annotation coverage.

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

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

The description is a single, well-structured sentence that front-loads the purpose and includes essential details without redundancy. Every part contributes to understanding.

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 an output schema, the description does not need to explain return values. It covers the core functionality, required parameters, and filtering options. A very minor gap is the lack of explanation for membership_type and destiny_membership_id, but overall it is sufficiently complete for agent 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 description explains the purpose of 'modes' (comma-separated mode IDs) and 'character_id' (0 for account), but does not clarify 'membership_type' or 'destiny_membership_id'. With 0% schema description coverage, the description provides partial but incomplete parameter guidance.

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

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

The description uses a specific verb ('Fetch') and resource ('historical Destiny 2 stats'), lists examples of stats (kills, deaths, KD, wins), and clarifies that character_id=0 corresponds to an account, distinguishing it from the sibling tool 'historical_stats_for_account'.

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

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

The description clearly states when to use the tool (fetching stats for a character or account with optional mode filtering) and implies the distinction between character (character_id set) and account (character_id=0). However, it does not explicitly state when not to use it or name alternatives beyond the sibling 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. Description adds context about account-wide aggregation but lacks details on authentication, rate limits, or data freshness.

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

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

Single sentence, front-loaded with verb and resource, no wasted words.

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

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

With output schema present, return values need not be explained. Description covers what is fetched and how to identify the account. Could add membership type values, but still adequate for a simple fetch tool.

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

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

Schema description coverage is 0%, so description should compensate. It only mentions parameter names without explaining what 'membership_type' (e.g., platform codes) or 'destiny_membership_id' represent, adding minimal semantic value.

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

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

Description clearly states 'Fetch account-wide aggregated Destiny 2 historical stats', specifying verb, resource, and scope. Differentiates from sibling 'historical_stats' by emphasizing account-wide aggregation across all characters.

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 on when to use this tool versus alternatives like 'historical_stats'. No mention of prerequisites or exclusions.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds context about cross-platform profiles and optional inactive memberships, but does not disclose additional behavioral traits such as error conditions or 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 a single, front-loaded sentence. It efficiently conveys the main action and key option, though it could be trimmed without loss of meaning.

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 and strong annotations, the description is functionally adequate but lacks example use cases or explanation of what 'linked profiles' entails. The optional parameter is mentioned, but not fully contextualized.

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 mentions 'membership_id/membership_type' and the optional flag, but fails to explain acceptable values for membership_type or the effect of get_all_memberships. Basic meaning is conveyed, but insufficient for full agent understanding.

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

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

The description uses a specific verb ('Fetch') and resource ('cross-platform Destiny 2 profiles linked to a Bungie.net membership_id/membership_type'), clearly distinguishing it from sibling tools like 'profile' or 'search_destiny_player' by focusing on linked profiles.

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

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

The description mentions the optional parameter to include inactive memberships, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when to prefer 'profile' for a single profile). No comparison or exclusions are provided.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the list of returned fields, which is useful but does not disclose additional behavioral traits beyond what annotations provide.

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

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

Three concise sentences front-load the purpose and return fields, with no extraneous content. Every sentence earns its place.

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

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

The description covers purpose, return fields, and usage context. It lacks details on pagination or limits, but given the simplicity of the tool (one optional param, no output schema), it is sufficiently complete.

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

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

Schema coverage is 100% for the single optional parameter. The description adds no information about the parameter beyond what the schema already provides, so baseline score of 3 applies.

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

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

The description states the tool lists 'active subscriptions' and specifies returned fields. However, it does not mention that include_inactive can also list cancelled subscriptions, creating a slight mismatch with the schema.

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

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

The description explicitly advises use before adding more subscriptions or to find an id to cancel, providing clear when-to-use context. It does not explicitly exclude other uses but implies the primary purpose.

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

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

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds no behavioral traits beyond what is already in annotations. It provides no additional context about performance, data freshness, or potential limitations.

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 with no extraneous content. It is front-loaded and efficiently communicates the core function. However, it could be more informative without sacrificing brevity.

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 parameters, rich annotations, and presence of an output schema, the description is adequate but minimal. It does not explain what the manifest metadata represents or how it might be used, leaving some gaps in context. The output schema may compensate, but the description itself is 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?

There are no parameters, so the schema coverage is effectively 100%. The description does not need to elaborate on parameter semantics. With zero parameters, a baseline of 4 is appropriate; the description correctly implies no input is needed.

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

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

The description states the tool returns 'Destiny 2 manifest metadata.' This is clear but vague; it does not specify what the manifest contains or how it might differ from other sibling tools. It avoids tautology but lacks sufficient detail for precise understanding.

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 on when to use this tool versus alternatives. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer context 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?

The description discloses rate limits ('Rate-limited to 5 per identifier per day'), free usage, the claim_token workflow ('Filing without an account returns a claim_token... pass it back later to read whether it was fixed'), and that 'The team reads digests daily.' These are behavioral details beyond the annotation flags.

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

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

The description is front-loaded with the core purpose and uses short, directive sentences. Though thorough, each piece of information (scope, exclusions, token flow, rate limit, quota) is actionable and non-redundant. The structure moves from what→when→how→boundaries.

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 adequately explains the return token and how to use it. It also covers rate limits, quota impact, and scope, making the tool fully self-explaining for the agent. It's complete for a feedback submission 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?

Although the schema covers parameters 100%, the description adds crucial flow semantics: the claim_token is explained as a returned token to later check status, and the message parameter is qualified with 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt.' The schema descriptions are enhanced by this practical usage guidance.

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 action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It distinguishes itself from sibling tools by explicitly limiting scope to 'tools served by this Pipeworx connection' and saying to file issues with other MCP servers elsewhere, making it distinct from ask_pipeworx and other query 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?

The description explicitly states when to use it with 'Use when a tool returns wrong/stale data...' and when not to use it: 'if the tool came from a different MCP server... file it with that server instead.' It also advises against pasting end-user prompts. This is explicit, actionable 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. The description adds behavioral context: data source ('CF analytics-engine'), no PII, and caching ('Cached 5min-1h depending on window'), which provides valuable transparency beyond annotations. No contradictions.

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

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

The description is concise (three sentences), front-loaded with purpose, and uses bullet points for use cases. Every sentence adds value without repetition or 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 optional parameter and no output schema, the description fully explains return values (top tools, packs, volume), data source, caching behavior, and multiple use cases. It is complete and self-contained.

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

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

Schema coverage is 100% for the single parameter 'window', with a full enum description. The description adds semantic guidance on window selection ('shorter for hot, longer for steady-state'), enhancing the schema's meaning. Baseline 3 is exceeded.

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

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

The description clearly states it returns 'top tools, top packs, and total call volume' over a recent window, using specific verbs and resources. It distinguishes itself from siblings by focusing on trending data from agent calls, not overlapping with other 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?

The description lists three explicit use cases (hot data discovery, canonical tool confirmation, alignment check) and provides guidance on window selection ('shorter windows surface what's hot right now; longer windows show steady-state demand'). It doesn't explicitly exclude scenarios but the context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds rich behavioral context: scanning top 200 markets, Jaccard similarity threshold, placeholder filter, fill check against CLOB depth. No contradictions.

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

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

Well-structured with front-loaded purpose and clear parameter breakdown. However, the description is dense and could be slightly more concise while retaining all 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?

No output schema, so description must cover return values. It does: lists fields of opportunities array and partition_check object, explains fill_check. For a 2-param tool, this is comprehensive.

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

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

Schema coverage is 100%, baseline 3. Description adds significant semantics: explains event slug/URL acceptance, topic as seed question, behavior for each mode (including default no-arg behavior). Provides recommendations and mode-specific outcomes.

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

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

The description states a specific verb and resource ('Find arbitrage opportunities on Polymarket') with clear method ('monotonicity violations + partition-sum checks'). It distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection via these specific checks.

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 each parameter: no args for trending scan, event for per-event partition check, topic for cross-event scan. Recommends event mode for specific markets. Warns against trading when realizable_edge_pp ≤ 0. Provides alternatives for custom sizing (polymarket_fill_risk).

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: caching (1h KV-level), the '24h-move warning', edge calculation net of slippage, and detailed explanation of model families and their limitations (e.g., Fed signal unreliable at meeting months). There is 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 verbose and could be more concise. It front-loads the main purpose but then dives into extensive technical details about model families, parameter knobs, and response structure. Some parameter explanations duplicate the schema. The logical structure is present, but the length may overwhelm agents.

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 compensates by detailing the response structure (by_segment with three segments, _diagnostics, fed_candidates) and the fields returned (edge_pp_net, kelly_fraction, market stats). The nine parameters are fully described. It is comprehensive but could benefit from a more structured format like bullet lists.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema: e.g., for min_kelly it explains skipping small opportunities, for slippage_pp it mentions Polymarket's zero fees and bid/ask depth, and for min_partition_leg_kelly it clarifies why min_kelly doesn't apply to partitions. Some redundancy with schema descriptions, but overall enhances understanding.

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

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

The description clearly states the tool's purpose: scanning Polymarket markets to find opportunities where Pipeworx data disagrees with market price. It uses specific verbs like 'Scan' and 'return opportunities' and distinguishes itself from sibling tools by grouping into three segments (model_driven, structural_arbitrage, concentrated_longshot).

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 positions the tool for the 'what should I bet on today' use case, avoiding paging through hundreds of markets. It provides guidance on when to use each segment (e.g., concentrated_longshot is rare-by-design) and explains tradeable-edge knobs (min_liquidity, max_spread_pp). It notes that Fed bets are excluded and why. However, it lacks explicit when-not-to-use guidance for specific scenarios.

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

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It explains the tool reads daily snapshots, details output fields (tracked, expired, snapshot_dates), covers limitations (60-day TTL, decay from daily closes), and notes that snapshot gaps occur on cache misses.

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 structured and front-loaded with the core question, but is somewhat dense with detailed output field explanations. Each sentence adds value, though it could be slightly streamlined while retaining completeness.

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 lack of an output schema, the description thoroughly explains all return fields (tracked, expired, snapshot_dates) with their sub-fields and meaning, along with limitations. This fully compensates for the absent output schema.

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

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

Schema coverage is 100%, and the description adds minor reinforcement (e.g., default 14, max 30 for days; default '1wk' for window). It does not add new meaning beyond what the input schema already provides, meeting the baseline for a well-described schema.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' from daily snapshots, answering a specific question about edge lifespan. It distinguishes itself from the sibling tool 'polymarket_edges' by focusing on historical time-series and decay metrics.

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

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

The description implies when to use this tool (to assess if an edge is fresh or stale) vs. a current edge snapshot tool. It states 'a fresh wide edge and a 3-week-old wide edge are different trades', providing context but lacking explicit exclusions or alternative tool names.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral details: walks the ladder, returns verdicts (clean|degraded|cannot_fill), and explains forced directional risk for baskets. No contradictions, and it enriches understanding beyond annotations.

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

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

The description is long but every sentence adds value, covering purpose, modes, parameters, returns, and usage guidance. It is front-loaded and information-dense. Could be slightly more structured (e.g., bullet lists) but remains concise 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?

No output schema, yet the description fully documents return values for both modes (e.g., theoretical_sum, realizable_sum, capture_ratio, thin_legs). It also explains the dominant loss mode (partial basket fills convert arb to directional position), making it complete for an agent to assess risk.

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

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

Input schema has 100% parameter descriptions. The tool description adds critical context: mutually exclusive requirement of 'market' or 'event', side defaults (auto for basket), and interpretation of size_usd (max spend vs target proceeds vs settlement notional). This adds value beyond the schema.

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

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

The description clearly states it performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' with distinct single-market and basket modes. It specifies exact outputs (top_of_book, vwap_fill_price, verdict, etc.) and differentiates from sibling tools like polymarket_arbitrage 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?

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

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

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

Annotations declare readOnly, idempotent, non-destructive. Description adds extensive behavioral details: compatibility_warning triggers, temporal alignment check, skipped cross-type/subtype counters. No contradictions.

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

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

Description is long (3 paragraphs) but each sentence provides essential context. Front-loaded with purpose and modes. Could be slightly more concise but acceptable given 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?

Without output schema, description explains response fields (top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). Covers safety fields and edge cases comprehensively.

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

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

Schema coverage is 100% with descriptions. Description adds meaning by explaining topic parameter's pre-mapped macros and how explicit params override, going beyond schema.

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

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

The description clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question, and distinguishes from sibling tools like polymarket_arbitrage by focusing on inter-venue 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?

It explains two modes (topic shortcuts vs explicit pairing) and warns that most pre-mapped topics return compatibility warnings, implicitly guiding users toward explicit pairing for reliable results. Could explicitly mention when not to use (e.g., single-venue arbitrage).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is clear. The description adds that the tool returns profile, characters, and inventory, which is helpful but doesn't disclose other behaviors like pagination or 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 a short phrase rather than a proper sentence. While concise, it lacks structure and misses key information, making it underspecified rather than efficiently compact.

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

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

With 3 required parameters, 0% schema coverage, and no explanation of the output schema, the description is completely inadequate. It fails to provide enough context for proper use.

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

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

Schema description coverage is 0%, and the description does not explain any of the three required parameters (components, membership_type, destiny_membership_id). This is a critical failure for agent invocation.

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

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

The description 'Profile + characters + inventory' lists the resource types returned but lacks a verb like 'get' or 'retrieve', making the purpose somewhat vague. It does distinguish from sibling 'character' by implying a broader 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?

No guidance on when to use this tool versus alternatives like 'character' or 'clan'. No explicit when-not or usage context is provided.

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

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

Annotations already declare readOnly and idempotent. Description adds beyond: scoping, behavior when key omitted, and relationship to siblings. No contradictions.

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

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

Concise, front-loaded with core action. Every sentence adds value with no waste.

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?

Complete for a simple read tool with good annotations. Covers purpose, usage, scoping, and sibling relationships.

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

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

Schema has 100% coverage with description of key. Description adds that omitting key lists all saved keys, which is critical usage info beyond schema.

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

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

Clearly states the tool retrieves a value saved via remember or lists all keys when no key is provided. Uses specific verb+resource and distinguishes from siblings like remember and forget.

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

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

Explicitly says when to use (look up stored context) and mentions scoping and pairing with remember/forget. Lacks explicit when-not-to-use, but context is sufficient.

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

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

Description contradicts annotations: readOnlyHint: true and idempotentHint: true, but mark_read:true modifies server state (flags events as read). This is a clear contradiction, so score 1 per rubric.

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?

Four sentences efficiently convey purpose, return format, filtering options, and additional usage notes. Front-loaded, 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?

Covers return fields, filtering, mark_read side effects, and alternative endpoint. Lacks details on response structure beyond mentioned fields and pagination behavior, but sufficiently complete for a read tool with rich annotations.

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

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

Schema covers 100% of parameters with descriptions. Description adds value by explaining mark_read's effect on subsequent calls and providing example for type filter. Does not mention unread_only 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 clearly states the tool pulls fired events from the subscription feed, specifies return fields (source, citation_uri, payload), and distinguishes from siblings by focusing on recent alerts. No tautology.

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 guidance on filtering, mark_read behavior, and polling. Mentions an alternative HTTP endpoint. Lacks explicit when-not-to-use or comparison with sibling tools, but adequate.

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

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

Annotations indicate a read-only, idempotent, non-destructive tool. The description adds detailed behavioral traits: parallel calls to multiple sources (SEC EDGAR, GDELT/GNews, USPTO), fallback mechanism (GNews when rate-limited), soft-failure for USPTO, date format acceptance, and return structure (changes grouped by source with citations). This goes well beyond the annotations.

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

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

The description is well-structured and front-loaded with example queries, but it is somewhat lengthy due to the inclusion of multiple source details and fallback behavior. While informative, it could be slightly more concise without losing 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?

Given the tool's complexity (multiple data sources, fallback, date variants, soft-failure), the description covers all necessary context. It mentions the return format (changes[], total_changes, citations) and limitations (USPTO soft-fail), making it complete without an output schema.

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

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

Schema coverage is 100%, providing a baseline of 3. The description significantly adds value by explaining the 'since' parameter with examples ('2026-04-01', '7d', '30d', '3m', '1y'), clarifying that 'type' only supports 'company,' and detailing that 'value' can be a ticker or zero-padded CIK. This goes beyond schema descriptions.

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

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

The description clearly states the tool's purpose as a 'change feed for a company in the last N days/weeks/months in ONE parallel call.' It lists illustrative queries like 'What's new with X' and 'latest on Y,' and explicitly distinguishes itself from the sibling tool 'entity_profile,' which handles static profiles.

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 guides when to use this tool by stating 'Use entity_profile instead when you want the static profile.' It also implies usage for dynamic change feeds and provides examples of appropriate queries.

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

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

Discloses scoping by identifier and retention differences between authenticated users (persistent) and anonymous sessions (24 hours). Annotations already indicate idempotentHint=true and non-destructive; description adds necessary behavioral details 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 concise (5 sentences) with no wasted words. Information is front-loaded: first sentence states core purpose, then usage guidance, then retention details. Every sentence adds value.

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

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

For a simple key-value store with no output schema, the description fully covers usage, scope, pairing, and retention. No gaps in context; the agent can confidently use the tool.

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

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

Schema has 100% coverage with descriptions for both parameters. Description adds meaning by providing naming conventions (e.g., 'subject_property') and clarifying value is 'any text'. Slight improvement over schema alone.

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

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

The description clearly states the tool saves data for reuse across conversations/sessions. It distinguishes from siblings like 'recall' and 'forget', making the purpose specific and unambiguous.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward'. Also provides alternatives: 'Pair with recall to retrieve later, forget to delete.' This guides the agent on tool 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?

Adds substantial behavioral context beyond the readOnly/idempotent annotations: identifiers are source-labelled, unresolved identifiers are explicitly stated under `unresolved`, LEI/FIGI enrichment degrades gracefully, and the tool cascades through several endpoints. No contradiction with annotations.

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

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

The description is a dense, long paragraph. It is front-loaded with examples but becomes verbose with parentheses and technical details. While every sentence adds value, structure could be improved with lists or headings for readability.

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

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

With no output schema, the description thoroughly explains what is returned for each type (CIK, ticker, LEI, FIGI, RxCUI, etc.), plus unresolved handling, source labelling, and graceful degradation. This covers the full complexity of the tool.

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

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

Schema description coverage is 100%, and the description does not significantly enhance parameter understanding. It restates accepted formats (ticker, CIK, name) already present in the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, with specific examples like "What's the ticker for…" and a clear verb+resource structure. It distinguishes itself from siblings by framing it as the first step when needing an ID from a name.

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

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

Explicitly says "Use FIRST whenever you have a name but need an ID," giving clear when-to-use guidance. It also lists supported types and mentions it replaces 2-3 manual lookups. However, it does not name specific alternatives or state exclusions, so it falls 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, idempotentHint, openWorldHint, and non-destructive. The description adds context: it explains the process of probing each entity with ai_visibility_check, ranking by score, and returning a ranked list. This goes beyond what annotations provide 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 two sentences plus a parenthetical example, all essential. It is front-loaded with the main action and contains no filler. Every sentence adds value, making it concise 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?

The description explains the return format (ranked list with score, confidence, signal density) and the internal process. While parameters are fully documented in schema and annotations cover safety, the description could mention error conditions or entity count limits (though schema covers 2-8). It is largely complete for this complexity level.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that the first entity in 'entities' is treated as the 'subject' for narrative, with the rest as competitors. It also provides usage context for 'models' and '_apiKey' parameters beyond schema descriptions.

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

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

The description clearly states the tool's purpose: compare AI visibility across multiple entities. It uses specific verbs like 'compare', 'probes', 'ranks', and 'surfaces'. It identifies the resource (AI visibility across entities) and distinguishes from sibling tools like ai_visibility_check which checks a single entity.

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

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

The description gives a clear use case: 'Useful for competitive AI-marketing audits' and provides a concrete example question. It implicitly distinguishes from single-entity checks by emphasizing multiple entities. However, it does not explicitly state when not to use or list alternative 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 indicate read-only, idempotent, non-destructive. Description adds key behavioral traits: fans out across two services, first measurement can take 5-30s, partial failures degrade gracefully with sources_failed listed. No contradiction with annotations.

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

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

Single, well-structured paragraph with every sentence adding value. Front-loaded with core purpose, then details on services, use cases, limitations, and edge cases. 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?

Despite no output schema, description comprehensively lists return fields (summary block, per-advisory, links, alternatives). Covers input constraints, behavior, failure modes, and timing. Sufficient for agent to understand 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 descriptions for both parameters. Description adds context: scoped packages accepted for 'package', and 'version' defaults to latest if omitted. This extra context raises value above 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 performs a composite check for adding an npm package, combining deps.dev and bundlephobia data. It distinguishes from siblings by specifying the exact scope and services involved.

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 (agent asks about safety/popularity/size/cost) and provides alternatives for other ecosystems (PyPI, Maven, etc. via deps.dev:version). Also mentions partial failure behavior.

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 the annotations, which already indicate read-only, idempotent, and non-destructive behavior. It fails to disclose any additional traits like authentication or 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 extremely concise (5 words), but it sacrifices necessary detail. It is front-loaded but lacks structure or additional information that would justify its brevity.

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

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

Given two required parameters with no schema descriptions and the existence of an output schema, the description is insufficient. It does not explain parameter constraints or values, leaving the agent ill-equipped to invoke the tool correctly.

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

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

With 0% schema description coverage, the description must explain the parameters. It only mentions 'display name with code' but does not clarify 'membership_type', leaving the agent without meaningful context for that parameter.

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

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

The description clearly states it finds a Destiny player by display name with code, which is specific. However, it does not explicitly differentiate from the sibling 'search_destiny_players_by_global_name', though the mention of 'with code' implies a distinction.

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 on when to use this tool versus alternatives, such as the sibling 'search_destiny_players_by_global_name'. An agent must infer usage from the description 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, openWorldHint, idempotentHint as true, establishing safety. The description adds behavioral context: pagination and the specific returned fields. No contradictions.

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

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

The description is a single, well-structured sentence that front-loads the key information (paginated, global search) and includes return fields. No redundant words.

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

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

Given that there is an output schema (not shown), the description need not fully detail return values. It covers pagination and result fields. However, more details on pagination limits or how to determine completion would enhance completeness.

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. It explains 'display_name_prefix' as the Bungie name prefix and 'page' as pagination, adding meaning beyond the raw schema. Examples in schema help, but more detail on page semantics (e.g., 0-indexed) would improve clarity.

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

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

The description clearly states it performs a paginated global search for Destiny players by Bungie name prefix and returns specific fields (membershipId, membershipType, bungieName). This distinguishes it from sibling tools like search_destiny_player by specifying prefix-based search and pagination.

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 finding players by name prefix with pagination. However, it does not explicitly state when to use this tool versus alternatives (e.g., search_destiny_player) or when not to use it.

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

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

Beyond annotations (readOnly, openWorld, idempotent), description discloses embedding model (BGE-base-en), chunking (500-char overlapping windows), similarity metric (cosine), and input cap (200K chars with truncation flag). No contradiction with annotations.

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

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

Two well-structured sentences. Front-loaded with core purpose, then usage guidance, then technical details. No wasted words.

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

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

Fully covers purpose, usage, internal mechanics, constraints (200K chars), and output characteristics. No output schema, but offset and similarity info is described. Annotations are rich; description complements them.

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

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

Schema has 100% coverage with descriptions. Description adds context for 'limit' (top-N passages) and provides natural-language query examples, helping agents understand parameter usage beyond schema.

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

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

'Semantic search INSIDE a fetched record' clearly states the action and resource. Examples (SEC 10-K, article) and output description (top-N passages with offsets) make it unambiguous. Differs from siblings by explicitly pairing with ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages'. Provides clear when-to-use and alternative strategy.

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

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

Annotations indicate idempotent, non-destructive, non-read-only. The description adds context beyond annotations: OAuth requirement, inability for anonymous users, webhook auto-disable after 10 failures, and HMAC signing details. No contradictions.

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

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

The description is well-structured, front-loads the core purpose, and uses efficient lists. Slightly long but each sentence adds value. Could be slightly trimmed, but no wasted content.

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

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

Given the complexity of subscription types and delivery options, the description covers prerequisites, type explanations, delivery mechanisms, and return value (subscription ID). No output schema exists, but the return is clearly stated. Handles all critical 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%, but the description adds extensive meaning: explains type enum options with examples, details the params object structure per type, and clarifies delivery constraints (phone verification, SMS cap, webhook signing).

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

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

The description clearly states the tool creates a proactive monitoring subscription and returns a subscription ID. It distinguishes from sibling tools like 'unsubscribe' and 'list_subscriptions' by focusing on creation, and provides a specific verb-resource pair.

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 describes when to use (live-data event monitoring), prerequisites (Pipeworx OAuth account), and limitations (10 SMS/day, email verification). It names alternative querying tools (recent_alerts) implicitly, and provides detailed type-specific parameter usage.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds useful behavioral context: it returns category-bucketed example questions with exact tool + argument shapes, drawn from a live catalog. 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 slightly verbose with many alternative phrasings, but it is well-structured with purpose front-loaded and usage guidance clear. It could be tightened slightly without losing meaning.

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 discovery tool with one optional parameter and no output schema, the description is complete. It explains the return format, when to use it, and how to focus the results. Annotations cover behavioral aspects adequately.

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

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

Schema coverage is 100% for the single optional parameter 'topic'. The description restates the schema's description exactly (optional focus area with listed categories). It does not add new semantic information beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool is an onboarding entry point that returns example questions, with multiple alternative phrasings. It distinguishes from siblings by explicitly saying 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-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?

The description provides explicit usage guidance: 'Call with no arguments for the full spread, or pass `topic` to focus.' and '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 indicates when not to use it (after initial onboarding).

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

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

Annotations provide idempotentHint=true and destructiveHint=false. The description adds critical behavioral details: the row is deactivated (not deleted) and historical events persist via recent_alerts. It also clarifies ownership enforcement, which annotations do not cover.

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, zero wasted words. The action is stated first, followed by key constraints and side effects. Optimal front-loading.

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

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

For a simple tool with one parameter, no output schema, and thorough annotations, the description covers all essential aspects: purpose, ownership constraint, data behavior, and impact on historical data. No gaps.

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

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

Schema coverage is 100% (one parameter with description). The description adds context beyond the schema by emphasizing that the id must belong to the user ('Ownership is enforced'), which is meaningful for correct invocation.

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

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

The description clearly states the action (cancel a subscription), the resource (subscription by id), and includes important behavioral details (ownership enforcement, deactivation vs deletion). It distinguishes itself from the sibling subscribe tool.

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

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

The description explicitly states ownership enforcement ('you can only cancel your own subscriptions'), implying it should not be used for others. It also mentions that historical events remain available via recent_alerts, providing context but no explicit when-not-to-use or comparison to alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. Description adds return field details (displayName, bungieNetUser, destinyMemberships) but no additional behavioral context such as authentication or 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?

Single sentence, front-loaded with verb and resource, no redundancy. Efficient and clear.

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

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

For a simple lookup tool with good annotations and an output schema, the description covers essential elements: purpose, parameters, and return fields. Could mention error conditions or valid membership_type values, but sufficient for basic understanding.

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

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

Schema description coverage is 0%, so description must compensate. It only restates parameter names ('by membership_id and membership_type') without explaining valid values or format (e.g., meaning of membership_type numbers). Examples exist but are not part of description.

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

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

The description clearly states the verb 'look up' and specifies the resource (Bungie.net user and Destiny memberships) and parameters. However, it does not differentiate from sibling tools like 'linked_profiles' or 'profile', which may have overlapping functionality.

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 on when to use this tool versus alternatives. While it implicitly suggests use when you have membership_id and membership_type, it does not provide context for when not to use it or which sibling tools to consider.

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

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

This is exemplary. The description discloses the two backend paths, the exact verdict enum, and the meaning of each result, especially the critical distinction between 'could_not_verify' (check did not happen) and 'unsupported' (no source exists). It also warns callers not to treat 'could_not_verify' as evidence for or against the claim. This goes far beyond the annotations, which already indicate a safe, read-only, idempotent 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?

Despite being longer than typical descriptions, it is well-structured and front-loaded: starting with natural-language triggers, then routing logic, return values, caller warnings, and an efficiency note. Every sentence adds value, and the density is appropriate for a tool with this complexity. The mention that it 'replaces 4–6 sequential calls' is a useful, non-redundant addition.

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 that there is no output schema, the description fully covers the return structure (verdict enum, actual value, citation, reasoning) and clarifies edge cases. It also provides enough context about the two processing pipelines and tolerance behavior. An agent can confidently select and invoke this tool based on the description alone.

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 thorough descriptions for both parameters, including examples for 'claim' and detailed override semantics for 'tolerance_pct' (range, default, use cases). The description itself adds no new parameter-specific information, so with 100% schema coverage 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 states the tool's purpose: natural-language claim verification against authoritative sources, with examples like 'fact check' and 'verify the claim that…'. It goes beyond a simple definition by describing the two processing paths (SEC EDGAR for financial claims, grounded pipeline for others) and the verdict-based output, which distinguishes it from general Q&A tools like ask_pipeworx.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct,' providing a clear invocation trigger. It also explains the routing logic for financial vs. non-financial claims, which helps the agent decide when to use it. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5 on this dimension.

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