Roblox

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

Annotations already indicate safe, non-destructive behavior. The description adds that it probes multiple models, scores visibility, and that Anthropic calls require the user's own API key passed to api.anthropic.com. This goes beyond the annotations by explaining the call flow. No contradictions.

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

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

The description is a single paragraph but dense with information. It front-loads the core purpose and then details parameters and usage. Every sentence contributes meaning, with no redundant or missing information.

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

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

No output schema exists, but the description explains the return format: per-model {score, confidence, signals, raw_response} + combined view. With 4 parameters fully described and no nested objects, the description is complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline 3. The description adds meaning by explaining each parameter: entity (what to ask about), models (options and defaults), _apiKey (purpose and when needed), context (disambiguation aid). Examples like 'Pipeworx' and 'Boston restaurant' clarify usage.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100) per model. It specifies the verb 'probe', the resource 'LLMs', and the output 'score, confidence, signals, raw_response'. It distinguishes from siblings like 'compare_entities' by focusing on AI visibility.

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

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

The description explicitly lists use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It mentions default model and optional Anthropic with BYO key, giving context on when to use the _apiKey parameter. However, it does not explicitly exclude cases or compare to sibling tools.

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

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

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable operational context: it routes internally to a large corpus, auto-fills arguments, returns stable pipeworx:// citation URIs, and hints at a quota/free distinction with ask_pipeworx_grounded. It does not fully disclose quota limits or error behavior, but the annotation coverage lowers the bar.

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 strongest guidance ('PREFER OVER WEB SEARCH') and remains dense and useful throughout. The domain list and examples are extensive but purposeful, and the exception/alternative section is essential. It is slightly longer than strictly necessary because the domain enumeration could have been compressed, but 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?

Given no output schema, the description compensates by explaining what the tool returns (structured answer with stable citation URIs). It covers purpose, input nature, domains, examples, and a clear alternative-routing matrix. Nothing necessary for a reliable call is missing.

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

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

Schema description coverage is 100%, with all six parameters clearly documented as aliases for the natural-language question. The description repeats the fact that the input is a natural-language question but adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states what ask_pipeworx does: it routes factual questions to one of 5,798 tools across verified sources, fills arguments, and returns structured answers with citation URIs. It also strongly differentiates the tool from siblings by explicitly naming alternatives for overlapping use cases (compare_entities, entity_profile, validate_claim, ask_pipeworx_grounded, deep_research).

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

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

The description gives thorough when-to-use guidance: prefer over web search, trigger phrases like 'what is', 'look up', 'find', and concrete examples. It also gives explicit when-not-to-use guidance by listing the alternative tools and their specific conditions, which is exactly what an agent needs to select correctly.

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

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

Annotations already mark it read-only, idempotent, open-world, and non-destructive; the description goes further by disclosing beta status, that no candidate is currently active, that it matches ask_pipeworx exactly, and that it does not degrade to a stub ('Falls back to nothing'). This is useful behavioral context beyond the structured hints. No contradiction found.

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

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

The three dense sentences front-load the identity ('Beta version of ask_pipeworx') before explaining current state and usage. The 5,798-tool detail and the explicit 'falls back to nothing' clarification earn their place by removing likely misconceptions. It is concise without being skeletal.

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 beta operational context, current equivalence to stable, and how to invoke it (same as ask_pipeworx). The absence of an output schema is mitigated by citing the same response shape as the stable sibling, but an agent that doesn't know ask_pipeworx still lacks a concrete return-format description. Overall, complete enough given the sibling 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% and every parameter is documented as an alias for 'question', so the schema carries the semantic weight. The description adds only that arguments are the same as ask_pipeworx, which is minor confirmation rather than new meaning. 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 identifies this as a beta variant of ask_pipeworx with an identical universal-routing behavior, so an agent can tell it is a router over the same 5,798 tools. It doesn't state the core outcome in a standalone verb phrase like 'answers questions', but the 'Ask' name, question parameter, and 'full working router' make the purpose recoverable. It differentiates from ask_pipeworx via the beta/experimental edge.

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

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

It explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing,' which gives a concrete selection condition. It implies the stable sibling is the alternative but does not spell out when NOT to use beta (e.g., production stability), relying on 'experimental edge' as the cue.

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

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

Annotations already establish read-only, idempotent, open-world, and non-destructive traits, so the baseline bar is lower. The description adds substantial behavioral context beyond annotations: it explains the extra LLM call cost, the strict grounding constraint ('using ONLY what the tool result contains'), the exact success return shape, and the specific refusal_reason enum values. This gives full visibility into how the tool behaves in edge cases, which annotations alone would not convey.

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

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

The description is compact but information-dense, starting with the most salient phrase ('Hallucination-resistant answer mode') and then layering routing, extraction, return values, refusal reasons, usage context, and cost trade-off. Every sentence serves a purpose — no filler, no repetition of schema fields. Despite its length, the structure makes the content scannable and front-loaded.

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

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

Because there is no output schema, the description fully explains return values and refusal reasons — that is essential context for an agent to interpret results. It also covers the routing rationale, cost, and use case boundaries. The only parameter is well-documented in the schema, and the behavioral traits are covered by annotations plus the description. Nothing critical is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100% — the question parameter is fully documented with aliases (question, query, q, prompt, text, input). The description adds no additional meaning about the parameter itself, which is acceptable because the schema already carries the burden. Per calibration, a baseline of 3 is correct when schema coverage is high and the description doesn't need to compensate.

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

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

The description opens with a concrete, distinctive purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It then details the behavior — routing to a source tool, fetching data, and extracting an answer strictly from results — which is far more specific than a generic 'answer questions' phrasing. It also explicitly contrasts with the sibling ask_pipeworx ('Same routing as ask_pipeworx'), so an agent can tell them apart immediately.

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

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

The description provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts (financial verdicts, legal claims, medical lookups, public statements).' It also gives a clear exclusion and alternative: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.' This is exactly what an agent needs to route between the two modes.

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, which the description matches. Beyond that, the description adds extensive behavioral detail: fan-out patterns per category, resolver contract with confidence levels, parent event extraction, news fallback mechanisms, safety short-circuits for low-confidence matches and closed markets, liquidity warnings, and cancellation rule parsing. 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 very verbose, at over 800 words, including many examples and edge cases. While structured into sections, it lacks conciseness—every sentence adds detail but could be trimmed. The length may hinder quick parsing by an AI agent.

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 response fields, resolution matching, parent events, news fallback, safety guards, cancellation rules), the description covers everything an agent needs to use it correctly. There is no output schema, so the description carries the full burden of explaining return values, which it does 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 covers all three parameters with descriptions. The description adds value by explaining the market parameter's flexibility (slug, URL, question text), the depth enum (quick vs thorough) with concrete evidence source counts, and include_raw with size implications. This goes beyond the schema descriptions.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, resolving the market, classifying, fanning out to data packs, and returning an evidence packet with market-vs-model comparison. It gives specific use cases, making the purpose unambiguous.

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

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

The description provides explicit usage scenarios: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It does not explicitly mention when not to use or alternatives, but the context is clear enough.

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

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

Annotations already mark it as read-only and non-destructive, and the description adds substantial detail: data sources (SEC EDGAR, FAERS, FDA, clinical trials), handling of fiscal year quirks, sorting by primary metric, and output format (paired data + citation URIs). No contradictions.

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

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

The description is a single, well-structured paragraph that front-loads common query patterns, then states the core function, data sources, and efficiency claim. Every sentence 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 no output schema, the description adequately explains what each type returns (specific financial metrics for companies, counts for drugs) and mentions sorting and citation URIs. Minor gap: exact output format structure not detailed, but sufficient for agent understanding.

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

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

Schema coverage is 100%, but the description adds meaning by explaining what each enum value returns (financials vs. regulatory data) and providing concrete examples for the values array (tickers/CIKs for companies, drug names). This helps the agent form correct inputs.

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 does side-by-side comparisons of 2-5 companies or drugs, with natural language triggers and explicit differentiation from sequential lookups. It unambiguously distinguishes from siblings like entity_profile.

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

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

The description explicitly says to prefer this tool over sequential single-pack lookups for comparisons and provides example queries. While it doesn't explicitly state when not to use it (e.g., for single entities), the context is clear enough to guide 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 declare readOnly/openWorld/idempotent, and the description adds a large amount of non-redundant behavioral context: account/paid-tier requirements, honest-gap semantics ("explicit gaps[] ... never invented"), contradiction[] behavior for standard/thorough, citation_uri fetchability guarantees, semantic excerpting of large records, and latency bounds (15-60s / ~90s). Nothing in the description contradicts the annotations.

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

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

The description is dense and front-loaded with the account requirement and sibling routing, but it is a ~400-word wall of text with visible redundancy: the latency expectation appears twice, depth behavior is fragmented across three separate sentences plus the schema, and one passage reads like an internal thought artifact ("depth:"standard" says: if you get gaps back, re-angular your question and try again"). Every sentence carries information, but the organization is loose and would benefit from clear sections.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does: findings packet fields (verbatim evidence, confidence, source, fetched_at), stable pipeworx:// citations, gaps[], contradictions[], hop field, and citation_uri resolvability. For a complex tool with 2 params and 3 depth modes, everything an agent needs to call it correctly — auth, alternatives, semantics, latency — is present.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds operational meaning beyond the schema's enum text — e.g., the consequence of choosing each depth (hop count, latency, paid plan for thorough) and the practical loop "If you get gaps after two hops you can refine or move to ask_pipeworx." It also confirms the question param tolerates broad/multi-part phrasing. Not a 5 because much of the depth detail restates the schema's enum descriptions rather than adding new parameter semantics.

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

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

The description states a specific verb and resource: "Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources ... in ONE call" and explicitly says "this is NOT open-web search," which disambiguates it from a generic web-research tool. It differentiates itself from siblings by name — "For a single lookup use ask_pipeworx instead" — so an agent can select it without opening 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?

Provides explicit when-to-use guidance: "Best for broad/multi-part questions over structured data" with concrete examples, and explicit when-not-to-use: "For a single lookup use ask_pipeworx instead," plus a prerequisite-based exclusion ("If you are not signed in, use ask_pipeworx instead — it works on every tier"). The alternative tool is named, so no inference is required.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: returns top-N tools with full schemas and curated examples, ready to call directly. 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 efficient, front-loaded with purpose, then usage, then benefits. It contains about 6-7 sentences with no wasted words. Minor improvement possible by tightening slightly.

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

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

Given the tool's complexity (6 parameters, no output schema, annotations present), the description explains the return format (top-N tools with schemas) and provides usage context. It is sufficiently complete for an agent to use 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% (all 6 parameters described). The description mentions aliases for 'query' but the schema already lists them. It adds no significant meaning beyond 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's purpose: 'Find tools by describing the data or task.' It lists many domains and distinguishes itself from sibling tools by being the sole discovery 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 when to use: 'Use when you need to browse, search, look up, or discover what tools exist for...' and 'Call this FIRST when you have many tools available.' It lacks explicit when-not-to-use guidance but is strong on positive 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?

The description adds extensive behavioral context beyond the readOnly/openWorld/idempotent annotations: it fans out across multiple upstream sources, returns sources_used/sources_failed, soft-fails on the USPTO PatentsView sunset, shows empty FDA sections for companies without biologics, and explicitly states that an empty section is real 'no data.' It also discloses the return structure for each section, including sorting and fallback behavior for news. All of this is consistent with the annotations, so there is 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 long, but every sentence earns its place for a tool with no output schema and a complex multi-source return contract. It is front-loaded with purpose and usage guidance before diving into the source/field breakdown, and it is internally organized by semicolons and return-field names. It loses a point only for being a dense wall of text that could benefit from more visual structure, but there is no fluff or repetition.

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

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

Given that there is no output schema, the description carries the full burden of explaining return values and behavior. It covers every major output section (cik/company_name, recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), each source's semantics, the sources_used/sources_failed signals, input resolution rules, and edge cases such as private companies and empty FDA sections. Nothing an agent would need to call the tool correctly and interpret its response is missing.

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

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

Schema coverage is 100%: both the `type` and `value` parameters already have detailed descriptions covering the accepted shapes ('ticker, CIK, or company name') and the interchangeability of 'company' vs 'ticker'. The description mostly restates this ('type accepts company or ticker interchangeably') and adds only a small extra note that names resolve via SEC EDGAR's company-name match. Baseline 3 is appropriate because the schema carries the heavy lifting and the description adds marginal value.

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

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

The description opens with concrete usage examples ('Tell me about X', 'research Acme', 'brief me on Tesla') and then states a specific verb-resource pair: 'full cross-source profile of a US public company in ONE parallel call.' It also differentiates itself from sibling-style alternatives by explicitly saying 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups.' This leaves an agent with no doubt what the tool accomplishes and how it differs from nearby 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 tells when to use this tool: when the user asks for a holistic view of a company, and explicitly tells it to be preferred over chaining single-source lookups. It also covers input variations (ticker, CIK, name) and the private-company edge case with 'resolved:false' and a notes line instead of a bare failure. This is far beyond the minimum viable guidance and provides clear when/when-not context.

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

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

Annotations already declare destructiveHint=true, so the deletion behavior is clear. The description adds context about clearing sensitive data and hints at irreversibility, which provides additional value 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 extremely concise, with two sentences that cover purpose, usage context, and sibling tools. Every sentence is necessary and front-loaded with the primary action.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description adequately covers its purpose, usage guidelines, and relationship to siblings. It could briefly mention the return behavior, but the context 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?

The input schema has 100% coverage, describing the 'key' parameter as 'Memory key to delete'. The description uses 'by key' but adds no further semantic details beyond what the schema provides. 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 clearly states that the tool deletes a previously stored memory by key, using a specific verb and resource. It distinguishes itself from siblings like 'remember' and 'recall' by explicitly pairing with them and mentioning use cases.

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: when context is stale, task is done, or to clear sensitive data. It also suggests pairing with 'remember' and 'recall', though it doesn't explicitly state when not to use.

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

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

While annotations indicate readOnlyHint and idempotentHint, the description adds no behavioral context beyond 'detail'. It does not describe what the tool returns or any side effects, which is insufficient even with annotations present.

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

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

The description is extremely short but under-specified. It lacks structure and front-loading of key information, making it ineffective despite 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 the complexity and many sibling tools, the description is incomplete. It does not explain what 'game' or 'universe' means, nor how this tool relates to others like user_games or entity_profile.

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%. The description implies universe_id is an identifier but adds no detail about its format, meaning, or relationship to the tool. It provides marginal value over 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 'Game (universe) detail.' is vague and barely states the tool's function. It reuses the tool name 'Game' without a clear verb or resource, and fails to distinguish it from siblings like user_games or entity_profile.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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

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

Annotations already mark this as read-only and idempotent, and the description goes well beyond them: it discloses exact return semantics for off-sale passes (is_for_sale:false and price_robux:null), cursor pagination capped at 100 per page, and the developer-products caveat to prevent misinterpreting empty results as tool failure. There is no contradiction with the annotations.

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

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

The description is dense but not bloated: four sentences cover purpose, resolution rules, return edge cases, pagination, and a common misinterpretation. It is front-loaded with the core action and 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?

This is a 5-parameter read tool with no required parameters and no output schema, so the description carries the burden of explaining behavior. It covers how to resolve the experience, the meaning of null prices, pagination behavior, and the primary false-negative scenario. An agent has enough context to select and invoke the tool correctly.

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

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

The input schema covers 100% of parameters, so the baseline is 3. The description adds meaningfully by stating that universe_id, place_id, and name are alternative resolvers and that exactly one must be passed, which the schema does not say. It also clarifies that pagination runs per page, supplementing the limit and cursor fields.

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: 'List the game passes ... sold in a Roblox experience, with their exact Robux price.' It also defines what game passes are via examples (VIP, 2x Money), which makes the tool's purpose unambiguous and distinguishable from related experience/player 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 explains how to target an experience: via universe_id, place_id, or name, and instructs the caller to pass exactly one. It also gives a 'when not to worry' signal by noting that many experiences sell developer products instead, so an empty or small result is a genuine answer. It stops short of naming alternative sibling tools, so it is not a full 5.

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

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

The description adds significant behavioral context beyond annotations: it fetches the page, extracts title/description/key links, and emits standard markdown. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description aligns perfectly with 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 three sentences, front-loading the core purpose, then process, then use cases. No extraneous words, highly efficient.

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

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

With high schema coverage, no output schema needed, and the description clearly states the output format ('single text blob ready to drop at site-root/llms.txt'). It covers all necessary aspects for the tool's simple function.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add new parameter-specific information beyond what's in the schema, earning the baseline score of 3.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb 'generate', the resource 'llms.txt file', and distinct use cases. It differentiates from siblings by mentioning AI crawlers and standard 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 lists three explicit use cases (client indexing, personal project, competitor audit) providing context. However, it lacks explicit when-not-to-use guidance or alternatives among siblings, so not a 5.

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

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

Annotations already indicate readOnlyHint, not destructive, and idempotent, providing a baseline for safety. The description adds no additional behavioral context (e.g., what is returned or any side effects), but does not contradict the annotations.

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

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

At two words, the description is overly terse and does not earn its keep. It lacks structure and omits essential information, making it ineffective despite being front-loaded.

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

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

Given the low complexity (one parameter, output schema exists), the description is still incomplete. It fails to define the tool's purpose, what it outputs, or any relevant context, leaving a significant gap.

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 should compensate but fails to explain the 'group_id' parameter's meaning or usage. The schema alone provides minimal guidance (number type), and the description adds nothing.

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 'Group detail' is vague, lacking a verb and not specifying what type of group or detail. It is almost a tautology, essentially restating the tool name without adding clarity. It does not distinguish from siblings like 'entity_profile'.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction.

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 value by listing return fields (id, type, params, timestamps, fire_count). No contradictions.

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

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

Two sentences, front-loaded with purpose and return fields, then usage guidance. 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 list tool: schema covers params, annotations cover behavior, description lists return fields. 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 described). Description does not add extra meaning beyond schema; 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?

Specific verb 'List', resource 'subscriptions', scope 'caller's active', and explicit return fields. Distinguishes from sibling subscribe/unsubscribe tools.

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

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

Explicitly states when to use: 'review what you're monitoring before adding more or to find an id to cancel'. No direct alternatives named, but context with siblings makes it 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?

Despite annotations being all false, the description richly discloses behavior: rate-limiting ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), the claim_token mechanism, and how reports are processed (daily digests, roadmap impact). This goes well beyond the annotations.

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

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

The description is long but every sentence earns its place: purpose, usage triggers, exclusions, content guidance, token behavior, rate limits, and cost. It is front-loaded with the core action and progressively builds context, making it an efficient and well-structured specification.

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

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

For a tool with 4 params, nested objects, and no output schema, the description is impressively complete. It explains the output behavior (claim_token returnable, status polling), the context fields implicitly, and the scope. The agent has enough to use the tool correctly without 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 description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: explains how claim_token is used to poll for resolution, and instructs not to paste end-user prompts. This justifies a 4, though it doesn't need to expand on each parameter given the schema's completeness.

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, specific action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates concrete feedback types (bug, feature/data_gap, praise) and clearly differentiates from sibling tools by scoping to Pipeworx tools only.

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

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

Provides explicit when-to-use guidance with examples ('tool returns wrong/stale data', 'tool you wish existed isn't in the catalog'), and strong when-not-to-use ('ONLY for tools served by this Pipeworx connection') with an alternative (file with that server instead). It also advises against pasting end-user prompts and clarifies what to describe.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and no destructive hint. The description adds valuable behavioral context: data source (CF analytics-engine), privacy (no PII), caching (5min-1h), and the self-aggregating nature. 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 structured with a main sentence followed by bullet-like use cases. It is concise without fluff, though slightly longer than minimal. 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?

Given the simplicity of the tool (1 optional parameter, no output schema, rich annotations), the description provides complete context: purpose, use cases, data source, privacy, caching. No gaps identified.

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

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

The input schema has 100% coverage with an enum and description for the 'window' parameter. The description adds context on how shorter vs longer windows affect results ('what's hot right now' vs 'steady-state demand'), which adds meaning beyond the schema.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' with specific time windows. It uses a specific verb ('Returns') and resource ('trending data on Pipeworx'), and distinguishes from siblings by focusing on aggregated trending signal.

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

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

The description explicitly lists three use cases (discovering hot data sources, confirming canonical choice, checking alignment). It does not explicitly state when not to use or name alternatives, but the use cases provide clear 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 provides extensive behavioral details beyond annotations (readOnlyHint, idempotentHint): explains algorithmic checks, semantic anchor, partition filter, fill check, and response structure, all of which help the agent understand execution.

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 thorough and front-loaded with the main purpose, but is lengthy with multiple paragraphs; however, the density of useful information justifies the length.

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

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

Although there is no output schema, the description fully explains the response fields for both modes and the fill check, making it complete for agent understanding.

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

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

The description adds significant meaning beyond the input schema: details on event slugs, full URL acceptance, scan scopes, and specific examples, compensating fully for the schema's brief 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 finds arbitrage opportunities on Polymarket using monotonicity violations and partition-sum checks, distinguishing it from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

The description explains when to use each mode (no args for trending scan, event for specific market, topic for cross-event) and mentions the fill check, but does not explicitly compare to sibling tools like polymarket_edge_tracker.

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

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

Annotations provide readOnlyHint, idempotentHint, and non-destructive nature. The description adds significant context: caching at KV level with 1h TTL, response structure (by_segment with diagnostics), edge calculation details (slippage, Kelly), and warnings about market movement. All consistent with annotations.

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

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

The description is very long and dense, covering model families, edge attributes, knobs, and response structure. Although well-organized and front-loaded, it sacrifices conciseness for completeness. Several details could be trimmed without losing clarity, e.g., repeating fractional Kelly explanations.

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 9 parameters, no output schema, and multiple model families, the description is remarkably complete. It explains each segment, the diagnostics section for empty results, caching behavior, and how to interpret edge attributes. All essential aspects for an agent to use the tool correctly are covered.

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 substantial value: explains min_kelly as 'half-Kelly fraction', slippage_pp context, tradeable-edge filters for max_spread_pp and min_liquidity, and nuances for min_partition_leg_kelly. Each parameter gets richer meaning beyond the schema.

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

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

The description clearly states the tool scans top Polymarket markets to return opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('scan', 'return') and distinguishes itself from siblings like 'polymarket_arbitrage' by focusing on a wide discovery across model families.

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 it is built for 'what should I bet on today' and for agents to 'discover opportunities without paging hundreds of markets.' It explains the 'tradeable-edge knobs' for filtering. However, it does not explicitly state when not to use it or provide direct comparisons to sibling tools like 'polymarket_edge_tracker' or 'polymarket_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?

The description discloses numerous behaviors beyond annotations: snapshot TTL (60 days), decay calculation from daily closes, snapshot generation triggers (cache-miss), and response fields. This provides rich operational context that annotations (readOnlyHint, etc.) 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?

The description is front-loaded with purpose and key question, then breaks down response structure. It is verbose but every sentence adds information. Could be slightly more concise, but overall well-organized.

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

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

Despite lacking an output schema, the description explains all response fields (tracked, expired, snapshot_dates) and their meanings. It also covers limitations (TTL, decay source). No critical missing context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds marginal value by explaining 'lookback' and 'snapshot family' in context, but mostly restates what the schema says (defaults, options). Baseline 3 is appropriate as the description does not significantly deepen parameter understanding.

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

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

The description states the tool provides 'edge persistence and decay telemetry' and answers a specific question about edge freshness. It clearly identifies the resource (edge time-series) and distinguishes from siblings like polymarket_edges and polymarket_arbitrage.

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 (to understand edge persistence and decay) and gives a concrete motivation (fresh vs old edge difference). However, it does not explicitly exclude scenarios or name alternative tools for comparison, missing the 'when-not' guidance for a top score.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context, such as the return fields (top_of_book, vwap_fill_price, slippage_pp, etc.) and the risks of thin books and partial fills, without contradicting any annotation.

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

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

The description is fairly long and includes some repetitive details (e.g., reiterating the modes). While it is front-loaded with the main purpose, the length could be trimmed without losing essential information. It earns its place but could be more 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 complexity of two modes and numerous return fields, the description covers all essential aspects. It explains the return values (verdict, slippage, profit_usd, thin_legs, forced_directional_risk) and provides context for when to use it, making it complete even 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%, so baseline is 3. However, the description adds significant meaning beyond the schema by explaining the dual modes, default sides, and the interpretation of size_usd (max spend on buys, target proceeds on sells; settlement notional for baskets). This enriches parameter understanding beyond the basic 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 'Realizable-vs-theoretical edge check against live CLOB order-book depth,' providing a specific verb and resource. It distinguishes between single-market and basket modes 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?

The description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', giving clear when-to-use guidance and explaining why partial basket fills convert arb into directional risk, the dominant loss mode.

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 is exceptionally transparent: it discloses that compatibility_warning and compatibility_codes can be non-empty even when matched_pairs>0, that unknown metric_type/match_subtype legs are never paired, that pairing_unverified is always set, and that fees are gross not net. It also explicitly clarifies that temporal_alignment null means 'not computed', not 'aligned'. This adds substantial context beyond the readOnly/idempotent annotations and never contradicts 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 long and dense, but nearly every passage carries operational value, especially given there is no output schema to document return fields. All-caps emphasis and some repetition add minor noise, but the critical warnings are front-loaded and clearly sectioned.

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

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

With no output schema, the description carries the full burden of explaining return semantics, and it does so thoroughly: top_spreads_pp, compatibility codes, skipped_unclassified, low_confidence_pairs, temporal_alignment, fees_note, and skipped_cross counters are all described. It also covers edge cases like null alignment meaning and pairing_unverified, making the tool safely callable by an agent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant semantic value: it explains the auto-fetch behavior behind topic, the override relationship of ticker/slug, the two-mode mutual-exclusivity, and that both modes run the same token-overlap matcher. It also lists the exact topic enum and warns that shortcuts are not inherently tradeable.

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 opening sentence names the resource ('Cross-venue spread between Kalshi and Polymarket') and the operation ('spread') for the same resolving question. It also distinguishes itself from sibling tools like polymarket_arbitrage by specifying the two venues and the outcome-comparison nature.

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 defines TWO MODES — topic shortcuts vs explicit kalshi_event_ticker + polymarket_event_slug — and explains when each is appropriate, including that both run the identical matcher. It also warns that pre-mapped topics generally return compatibility warnings and 'pre-mapped ≠ tradeable'. It does not explicitly name sibling alternatives or exclusion conditions, but mode-level guidance is strong.

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. Description adds scoping detail: 'Scoped to your identifier (anonymous IP, BYO key hash, or account ID)' which provides valuable behavioral context beyond annotations.

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

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

Concise single paragraph, front-loaded with core purpose, then usage, scoping, and pairing. Every sentence adds value; 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?

Covers purpose, usage, scoping, pairing. With high schema coverage and good annotations, description is sufficiently complete. Could mention return value format but not required given no output schema.

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

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

Only one parameter (key) with 100% schema coverage. Description restates schema info ('omit the key argument to list all keys'), adding no new meaning. Baseline 3 due to high schema coverage.

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

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

Description clearly states the verb (retrieve/list), resource (saved values/keys), and distinguishes from siblings (remember, forget). It specifies both retrieving a specific key and listing all keys.

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

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

Explicitly states when to use: 'to look up context the agent stored earlier... without re-deriving it from scratch.' Provides scoping context and pairing with remember/forget, though no explicit when-not-to-use.

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

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

The description states that setting mark_read:true flags events as read, which modifies server state. This directly contradicts the readOnlyHint=true annotation, which claims no modifications. Per scoring rules, contradiction yields a score of 1.

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

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

Four sentences, front-loaded with the main action, no wasted words. The description is well-structured and easy to 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?

Covers all parameters, return fields, and alternative access. With no output schema, the description adequately explains what is returned. Mentions polling behavior and applicability.

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 examples (e.g., 'sec_8k' for type, ISO timestamp for since) and clarifies the effect of mark_read. This enhances understanding beyond the schema.

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

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

Highlights the specific verb 'pull' and resource 'fired events from your subscription feed', clearly distinguishing it from siblings. The description explains what is returned (source, citation_uri, raw payload) and supports filtering.

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

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

Provides explicit guidance on filtering by type and ISO timestamp, and mentions an alternative GET endpoint for scripts/dashboards. Does not explicitly state when not to use the tool, but 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?

Disclosures read-only nature, parallel fan-out to SEC EDGAR, GDELT→GNews fallback, and USPTO soft-fail. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and description adds specific behavioral context beyond 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?

Front-loaded with example queries. Single paragraph is dense but not verbose. Could be slightly more structured, but every sentence adds value. Very efficient overall.

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 states return format: structured changes grouped by source, total_changes count, pipeworx:// citation URIs. Covers all necessary context: sources, parameters, fallback, sibling differentiation. 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% but description adds meaning: explains since formats and typical values, clarifies value can be ticker or CIK, and notes type only supports company. Adds significant value beyond schema.

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

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

The description starts with example queries that mirror natural language, then explicitly states it's a change feed for a company in the last N days, fanning out to multiple sources. It differentiates from sibling entity_profile by specifying that tool is for 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?

Provides explicit guidance: 'Use entity_profile instead when you want the static profile'. Includes examples of when to use and explains parameter formats (ISO date or relative shorthand) with typical values like '30d' or '1m'.

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

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

Description discloses key behavioral traits: key-value pair scoped by identifier, persistent vs 24-hour retention, and aligns with annotations (write, idempotent, non-destructive). 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?

Concise with no waste. Front-loaded with the main action, each sentence earns its place, and structure is logical.

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

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

For a simple 2-parameter tool, the description covers purpose, usage, persistence, and sibling relationships. Missing output schema is acceptable as return value is likely straightforward.

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. The description adds semantic examples for both key and value, enhancing understanding beyond what schema alone provides.

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 ('save') and resource ('data') and clarifies the scope (across conversations/sessions). It also distinguishes from sibling tools 'recall' and 'forget'.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward' with concrete examples. Also mentions pairing with recall and forget, and differentiates persistence behavior for authenticated vs anonymous users.

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

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

The annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description goes well beyond that by disclosing graceful degradation when GLEIF/OpenFIGI are unavailable, explicit unresolved-identifier reporting, candidate-returning behavior for ambiguous matches, and the internal cascading lookup behavior.

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

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

The description is long but dense with necessary edge-case guidance, and the opening examples immediately communicate intent. It is structured as one continuous block with heavy parentheticals, which slightly hurts scannability, but every sentence contributes useful information about when and how to call the tool.

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

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

With no output schema, the description carries the burden of explaining return behavior, and it does: expected identifiers per type, unresolved fields, figi_candidates on ambiguity, optional enrichment, and degradation semantics. The agent has enough information to invoke the tool correctly and interpret its response.

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

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

Even though schema coverage is 100%, the description adds crucial guidance not present in the schema: pass the entity name only, never the full noun phrase, with the concrete counterexample 'NEW YORK ST DORM AUTH revenue bonds'. It also enriches value semantics by listing accepted input forms per type (ticker, CIK, ISIN, name; brand or generic drug name) and the ISIN-to-LEI resolution path.

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

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

The description opens with concrete user phrasings and states the core verb: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It covers supported entity types (company, drug) and the specific identifiers (CIK, LEI, FIGI, RxCUI), making it clearly distinct from siblings like entity_profile or compare_entities.

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

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

It explicitly says 'Use FIRST whenever you have a name but need an ID', which gives a strong when-to-use directive. It does not explicitly name sibling tools as alternatives, but it explains edge cases like ambiguous names resolving to figi_candidates, so the agent understands when not to expect a single assertion.

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, etc. The description adds non-obvious behavioral details: it probes each entity with ai_visibility_check, ranks results, and surfaces score, confidence, and signal density per entity. No contradiction with annotations.

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

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

Three sentences, front-loaded with the primary action, no fluff. Every sentence adds value: purpose, method, use case, and output format.

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

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

No output schema is provided, but the description explicitly states the return format (ranked list with score, confidence, signal density). For a tool with 4 parameters and 1 required, this is sufficient for an agent to use 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 all parameters. The description adds significant meaning: the first entity is treated as the subject, models default to workers-ai, and context disambiguates common names. This goes 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 compares AI visibility across multiple entities side-by-side, using ai_visibility_check and ranking by score. It distinguishes itself from sibling tools like ai_visibility_check (single entity) by specifying batch comparison.

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

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

The description explicitly frames the tool for competitive AI-marketing audits with a concrete example. It implies when to use (multiple entities) but does not explicitly state when not to use or mention alternatives beyond the sibling list.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed field lists any timeout. 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 dense but well-structured, starting with the composite nature, then usage, then return structure, and finally caveats. It could be slightly more concise, but 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?

Given no output schema, the description fully details what the tool returns (summary block, per-advisory detail, links, alternative versions). It also covers critical context: NPM-only scope, partial failure behavior, timing, and field listing. Complete for a tool with two simple parameters.

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% description coverage for both parameters. The description adds that scoped packages (e.g., '@types/node') are accepted and that version defaults to latest. This extra information enhances understanding beyond the schema.

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

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

The description clearly defines the tool as a composite check for npm packages, covering license, advisories, version history, and bundle size. It specifies the exact resource (npm package) and actions, and distinguishes from sibling tools by limiting to NPM ecosystem and mentioning fallback for other ecosystems.

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

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

Explicitly states when to use: when an agent asks about safety, popularity, or size of an npm package. Also clarifies that it's NPM-only and provides alternatives for other ecosystems (PyPI, Maven, etc. under deps.dev:version).

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

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

Discloses embedding model, similarity metric, window size, character cap (200K), truncation behavior, and that passages include offsets. Annotations confirm safe, read-only, idempotent behavior; description adds valuable technical 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?

Three sentences, no filler. Front-loaded with the core action, then use-case, then technical 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 tool with 3 params, no output schema, and annotations present, the description fully covers purpose, usage, technical limitations, and integration pattern. No gaps for agent decision-making.

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

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

Schema coverage is 100%; schema already describes each parameter. Description adds example queries and mentions truncation flag but does not substantially enhance semantic understanding 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 it performs semantic search inside a fetched record, explicitly distinguishing from siblings by mentioning it pairs with ask_pipeworx_grounded. The verb 'search within' and resource 'source' are specific.

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

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

Explicitly states when to use: when record is too big for prompt. Describes pairing with sibling tool. Lacks explicit when-not or alternatives to other search 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 include idempotentHint=true and destructiveHint=false. The description adds behavioral detail beyond annotations, such as the need for an OAuth account, SMS phone verification, and a 10/day SMS cap. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and well-structured with clear sections. While it is relatively long, each sentence adds value; minor redundancy could be trimmed but overall it remains efficient.

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

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

Given the tool has no output schema, the description appropriately includes the return value ('Returns the new subscription id'). It covers prerequisites, types, delivery options, and constraints, making it complete for a complex tool.

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

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

Schema coverage is 100%, and the description adds substantial meaning beyond the schema by providing concrete examples (e.g., 'items:["5.02"] = officer change') and clarifying the 'params' structure for each type. This significantly aids parameter understanding.

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

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

The description clearly states the tool creates a 'proactive monitoring subscription' and returns the subscription id. It distinguishes itself from siblings like 'unsubscribe' and 'list_subscriptions' by specifying the creation action on a live-data event stream.

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 context on when to use the tool, including the requirement for a Pipeworx OAuth account and specifying supported types and delivery channels. While it does not directly state when not to use, the detailed examples and constraints implicitly guide appropriate 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 declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds value beyond these by detailing the output structure (category-bucketed questions), the source (live catalog), and the optional parameter behavior. 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 moderately long but each sentence adds value: it enumerates triggering queries, explains the output, and provides usage advice. It is front-loaded with the key queries and essential info. Some minor redundancy could be trimmed but overall efficient for an onboarding tool.

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

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

Given that the tool has only one optional parameter and no output schema, the description fully explains what the tool does and what to expect. It covers input possibilities, output structure, and when to use it, making it self-sufficient for an agent.

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

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

The input schema covers the single optional parameter 'topic' with a description. The description adds meaning by listing example values (finance, pharma, etc.) and explaining that omitting it returns a cross-category spread, which goes beyond the schema's generic description.

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

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

The description clearly states the tool's purpose: returns category-bucketed example questions with exact tool+argument shapes, serving as an onboarding entry point. It distinguishes itself from sibling tools like ask_pipeworx or discover_tools by specifying its role as the first stop for users unfamiliar with 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 when to use the tool: 'first when you do not yet know what Pipeworx can do', and provides example queries. While it does not explicitly state when not to use it, the context makes the use case clear. The mention of optional topic focusing adds practical 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 provide idempotentHint and destructiveHint. Description adds ownership enforcement and deactivation behavior, which is beyond the annotations. No contradiction.

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

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

Two sentences with no wasted words. Front-loaded with the core action. Every sentence is meaningful.

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

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

Given the tool's simplicity (1 param, no output schema), the description is complete: it explains behavior, limitations, and side effects.

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

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

Only one parameter 'id' with a description linking to 'subscribe' output. Schema coverage is 100%, and the description adds context about the id's origin.

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 'Cancel' and resource 'subscription by id'. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Specifies ownership enforcement ('you can only cancel your own subscriptions') and explains that the row is deactivated, not deleted, so historical events remain. No explicit when-not-to-use but sufficient guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's behavioral burden is reduced. The description adds value by listing the returned fields (display name, username, description, account creation date, ban status), which is not in annotations.

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

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

The description is a single sentence that packs essential information (verb, resource, parameter, return fields) with no extraneous content. It is highly efficient and front-loaded.

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

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

Given the simplicity of the tool (one parameter, no nested objects), the description is reasonably complete, listing key return fields. However, it could mention potential error conditions or authentication requirements, and the output schema is not explicitly shown but the description compensates.

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 clarifies that the user_id parameter must be numeric, but does not provide additional constraints or format details. This minimal addition meets the baseline for a single 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 the verb 'Fetch', the resource 'a Roblox user's public profile', the required parameter 'numeric user_id', and lists the specific fields returned. It distinguishes itself from siblings like 'user_by_username' by specifying the identifier type.

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 when a numeric user_id is available ('by numeric user_id') but does not explicitly state when to use this tool versus alternatives like user_by_username, nor does it provide exclusion criteria 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?

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds no behavioral context beyond what annotations declare, such as rate limits, data freshness, or ordering behavior. It fails to leverage the opportunity to disclose additional traits.

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

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

Extremely concise (one word) but at the expense of usefulness. This is under-specification, not efficient communication. Every sentence should earn its place, but here there is no sentence.

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 3 parameters, 0% schema coverage, and an output schema that exists but is not mentioned, the description is completely inadequate. An agent cannot determine how to use this tool effectively.

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

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

Schema description coverage is 0% and the tool description does not explain any parameter. What does 'limit' do? What values are valid for 'sortOrder'? The examples in the schema offer minimal hint, but no textual clarification is provided.

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 is just 'Badges.' – a noun, not a verb phrase. It vaguely indicates the topic but does not state what the tool does (e.g., retrieve badges for a user). Compared to sibling tools like 'user' or 'user_followers_count', it lacks a clear action or 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. The sibling list includes many user-related tools, 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool resolves to a user id, confirming the output. No contradiction; the description is consistent with the safe, idempotent nature.

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

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

The description is a single sentence that directly conveys the core functionality. It is front-loaded and contains no unnecessary words.

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

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

Given the simplicity of the tool (1 param, output schema present), the description is minimally adequate. However, it does not address edge cases like non-existent usernames or behavior when username is ambiguous.

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

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

The single parameter 'username' is self-explanatory by name, but the schema has 0% description coverage. The description does not add any constraints, format hints, or examples beyond the schema's example.

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 'Resolve username to user id' uses a specific verb-action (resolve) and clearly states the mapping from username to user id. It distinguishes this tool from sibling tools like 'user' which likely return full user 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 provides no information on when to use this tool versus alternatives (e.g., 'user', 'entity_profile'). There is no guidance on prerequisites, context, 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds no additional behavioral context beyond what is already in annotations, so it provides minimal value.

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

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

The description is a single focused sentence with no unnecessary words. It is appropriately concise for a simple tool.

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

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

For a simple read-only tool with a single parameter and output schema, the description covers the core function. However, it lacks explanation of the user_id parameter and does not mention the return value format, making it just adequate.

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

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

Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description only says 'numeric user_id', which repeats the schema's type (number) without adding semantics like expected format, range, or examples. It fails to compensate for the schema gap.

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

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

The description clearly states it returns the total number of followers for a Roblox user using a numeric user_id. It uses a specific verb ('Return') and resource ('total number of followers'), and distinguishes from sibling tools like 'user_followings_count' which would return followings count.

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 this tool versus alternatives is provided. The usage is implied: when you need the follower count for a user. However, it does not mention exclusions 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds only that it returns a count by numeric user_id, which is already in the schema, but does not disclose error behavior or edge cases (e.g., invalid user_id).

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 the key action and resource, zero wasted words.

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

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

Given the simplicity of the tool (one parameter, output schema present), the description is mostly complete. It could briefly mention edge cases or the nature of the count (e.g., live value), but it is sufficient for a straightforward query.

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 should compensate but only restates the type ('numeric') of user_id, adding no additional context about constraints, range, or expected format beyond the schema's examples.

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

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

The description clearly states it returns the total number of accounts a Roblox user is following, using a numeric user_id. The verb 'return' and resource 'followings count' are specific, and it naturally distinguishes from the sibling 'user_followers_count'.

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 this tool versus alternatives like 'user_followers_count'. The description focuses solely on what it does, leaving the agent to infer usage context without direct comparisons or exclusion criteria.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint as true/true/true/false, indicating a safe, idempotent read operation. The description adds value by specifying returned fields and presence status, which goes 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?

A single sentence that conveys purpose, input, and output with no unnecessary words. Front-loaded with 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 presence of an output schema and comprehensive annotations, the description covers all needed aspects: input, output, and behavior. No further details are necessary for a simple list tool.

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

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

The schema has one parameter 'user_id' with type 'number'. The description restates 'numeric user_id' but adds no additional constraints, format, or examples beyond the schema. With 0% schema description coverage, the description does not compensate significantly.

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 'List', the resource 'friends', the required input 'numeric user_id', and the output fields (user ID, username, display name, presence status). It is distinct from siblings like 'user_followers_count' which count followers.

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 use for listing friends of a user, but does not explicitly state when not to use or provide alternatives. However, the context of sibling tools (e.g., user_badges, user_games) makes the purpose clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description adds no behavioral context. It omits details about sorting, limit behavior, or authentication requirements.

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

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

While extremely short (two words), the description is under-specified for a tool with 3 parameters and an output schema. It sacrifices informativeness for brevity, failing to convey 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?

Given the tool's complexity, the description is severely incomplete. It does not explain what the tool returns, how parameters influence results, or how it differs from sibling user-related tools. Output schema presence does not compensate for the lack of narrative.

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 0% description coverage, and the description 'Created games' provides no meaning for the three parameters (limit, user_id, sortOrder). Examples in schema offer minimal context but are not part of the 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 'Created games' is a tautology that restates the tool name without specifying an action or resource scope. It does not clarify whether the tool lists, creates, or manages games, leaving purpose ambiguous.

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 siblings like user_badges or user_followers_count. The context of sibling tools suggests it retrieves user-specific data, but usage context is entirely implied.

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, covering safety and idempotency. The description adds the input limit of 100 user IDs, but does not explain what 'presence' means or any responses.

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, concise but not front-loaded with a clear action. It could be restructured to start with a verb. No wasted words, but under-specified.

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 output schema exists (but unavailable to the agent via description) and no detail on presence semantics, the description leaves the agent without enough context to use the tool effectively. It does not define presence states or provide example 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?

With 0% schema description coverage, the description must compensate. It specifies the user_ids parameter is for 'up to 100 user ids', clarifying a constraint not in the schema, but fails to explain what presence data is retrieved or the output structure.

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 'Presence for up to 100 user ids' is a noun phrase without an explicit verb, making the action unclear (is it 'get', 'check', 'update'?). It barely distinguishes from siblings like 'user' or 'user_badges', which also relate to users.

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. It does not mention context (e.g., checking online status) or exclusion conditions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context: the two pipeline paths (SEC EDGAR fast path vs grounded fallback), the meaning of each verdict (especially could_not_verify vs unsupported), the presence of verification_error details, and the fact that could_not_verify must not be shown as evidence. This is rich disclosure beyond annotations and no contradiction exists.

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

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

The description is long but highly information-dense. Every sentence contributes: trigger phrases, routing logic, verdict taxonomy, error semantics, and performance benefit. It is front-loaded with the most important usage cue and structured logically. No redundant or filler content exists. Despite its length, it is concisely written for the complexity it covers.

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 carries the full burden of explaining return values: verdicts, actual value, citation, reasoning, and error behavior (verification_error with stage/detail). It also explains the two failure modes (could_not_verify vs unsupported) and when to use the fast path vs grounded pipeline. For a complex tool with two parameters and no output schema, this is impressively 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%, so baseline is 3. The description adds real value by explaining tolerance_pct behavior: it overrides the tolerance implied by claim wording and recommends 1–2 for hallucination detection. It also clarifies the default cap of 5. The claim parameter is well exemplified in the schema (e.g., "Apple's FY2024 revenue was $400 billion"), so the description's marginal addition is sufficient to warrant a 4.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with a specific verb ('validate') and resource ('claim'). It distinguishes itself from siblings by explicitly mentioning it replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison), which no other sibling description does.

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

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

The description states 'Use whenever the agent needs to check whether something a user said is factually correct' and provides a clear routing rule (company-financial vs other claims). It does not explicitly name sibling alternatives to avoid, but the mention of replacing sequential calls implies the added value over general-purpose tools like ask_pipeworx. Slightly more explicit contrast with ask_pipeworx_grounded would push it to 5.

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