Onedrive

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

Annotations already indicate readonly, idempotent, non-destructive. The description adds context about model options, free vs. BYO key, and cost implications. This goes beyond annotations without contradiction.

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

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

The description is four sentences with no redundancy. First sentence states core purpose and output. Second explains model options. Third describes return format. Fourth lists use cases. Ideal front-loading.

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

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

For a tool with 4 parameters and no output schema, the description covers inputs, behavior, and output structure well. Returns are described per-model. Missing details like rate limits or pagination are not critical given annotations. Adequate for effective invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value with examples for 'entity', clarifies when '_apiKey' is needed, and explains the 'context' parameter for disambiguation. This enhances understanding beyond schema alone.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and returns a visibility score (0-100). It specifies the default model and optional Anthropic integration, and gives concrete examples. This is specific and distinguishes from broader search tools, though not explicitly differentiating from sibling 'scan_competitor_ai_presence'.

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

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

The description provides clear use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not explicitly exclude alternatives or say when not to use, but the context is sufficient for appropriate 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?

The annotations already declare readOnly/openWorld/idempotent behavior, and the description adds meaningful context beyond that: it routes across 5,798 tools, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. This helps set expectations about latency, indirection, and output format, though it doesn't detail failure modes or edge cases.

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 and information-dense, but it is also redundant: the alternative-tool guidance is repeated ('For grounded answers...', 'Upgrade only if needed: ...'), and the long category list plus repeated examples make it longer than necessary. Every sentence does not earn its place.

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

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

For a broad router tool with no output schema, the description conveys enough to understand what will happen: a question goes in, routing occurs, and a structured cited answer returns. It also covers alternatives and usage scope. It doesn't specify the exact response shape, but the high-level explanation is sufficient for correct invocation.

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

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

Schema coverage is 100% since the only real parameter is a natural-language question with aliases. The description reinforces how to use that parameter through trigger phrases and six concrete examples, which adds practical value beyond the schema's terse 'Your question or request in natural language.'

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 clear, specific function: route natural-language factual questions to the appropriate tool among thousands of verified sources and return a cited, structured answer. It also differentiates itself from siblings by explicitly billing itself as the default routing entry point and telling the agent not to hand-pick specific tools.

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

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

It gives explicit when-to-use guidance: prefer over web search, use for factual/current/historical questions, and lists trigger phrases plus concrete examples. It also names alternatives (ask_pipeworx_grounded, deep_research, compare_entities, ask_pipeworx_beta) with conditions, so an agent can select correctly among siblings.

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

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

The description adds substantial behavioral context beyond the read-only, open-world, and idempotent annotations: it discloses that candidate routing improvements are live only when under test, notes the current inactive state, and clarifies that this beta does not fall back to a stub but is a fully working router. This is exactly the kind of non-obvious behavior an agent needs to know.

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 information-dense without being bloated: each sentence adds context about relationship to ask_pipeworx, current experimental state, usage, and fallback behavior. The most defining characteristic (beta version of ask_pipeworx) is front-loaded. The date and tool count are specific but justified.

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

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

Given there is no output schema, the description compensates by specifying that the response shape matches ask_pipeworx. It also covers the tool's current state and how results are used. It does not describe possible routing outcomes or error behavior, but for a variant router whose stable counterpart is a sibling, the provided context is largely sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail. The description only says 'same arguments' as ask_pipeworx and does not add new semantic meaning beyond what the schema already provides for the question parameter and its aliases. Thus the schema carries the load adequately.

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 a clear verb and resource: it is a beta version of ask_pipeworx, a universal router over 5,798 tools with the same arguments and response shape. It differentiates itself from the stable ask_pipeworx sibling by emphasizing the experimental routing improvements. The scope is unambiguous.

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

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

It explicitly states to use this tool 'exactly like ask_pipeworx when you want the newest routing.' It also frames the tool as the experimental edge whose results are compared against the stable router. There is a clear usage context, though it stops short of explicitly naming conditions where ask_pipeworx should be preferred.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: it discloses the extraction-only behavior, the exact success return shape, the refusal mechanism, and the specific refusal_reason values. This gives an agent a clear model of what the tool will and will not do.

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 key behavioral promise, and every sentence adds value: mode, routing behavior, return/refusal structure, usage triggers, and cost tradeoff. It is somewhat long, but the length is justified by the amount of decision-relevant information it packs in.

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

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

Despite having no output schema, the description fully covers the return contract, refusal reasons, intended use cases, alternative routing, and cost implications. An agent has everything needed to decide when to invoke this tool and to interpret its result.

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 input schema fully documents the question parameter and its aliases, so the description does not need to repeat it. The description adds context that the question is routed across many sources and used to fill arguments, but it does not add meaning beyond the schema for the single parameter itself.

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

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

The description states a specific, differentiated purpose: a hallucination-resistant, grounded answer mode that extracts answers only from tool results. It distinguishes itself from ask_pipeworx by naming the shared routing and the key behavioral difference, so an agent can tell them apart without inspecting schemas.

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 ('whenever an answer will be quoted, cited, or acted on'), provides concrete high-stakes examples, and names the alternative with a cost-based preference rule: prefer ask_pipeworx for casual lookups because this tool costs an extra LLM call. This is explicit selection guidance.

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

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

The description goes far beyond annotations by detailing resolution handling (low_confidence_match, market_closed_or_inactive), tradeability warnings, cancellation rules, fallback behavior, parent event extraction, and safety features. Annotations already indicate read-only/idempotent, and the description adds extensive context without contradiction.

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

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

The description is very long (multiple paragraphs) and includes extensive detail that could be relegated to reference docs. However, it is well-structured with section headings and front-loaded purpose, making it navigable despite verbosity.

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 absence of an output schema, the description thoroughly explains the return structure (result.market, analysis, evidence, resolver contract, parent event, etc.) and covers edge cases like low confidence, closed markets, and wide spreads. It is remarkably 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?

All three parameters are described in the schema with 100% coverage. The description adds context like market format flexibility, depth choices, and include_raw behavior, plus examples. This adds moderate value over the schema alone.

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

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

The description clearly states the tool researches a Polymarket bet into a single call, specifying inputs (slug, URL, question text) and outputs (evidence packet + comparison). It distinguishes itself from simpler queries by emphasizing the 'one call' and 'fan-out' behavior, differentiating it from sibling tools like ask_pipeworx.

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

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

The description provides explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It includes classifiers and fan-out examples to guide selection. However, it does not explicitly state when not to use the tool or directly compare to alternatives, leaving slight ambiguity.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint—all true/false appropriately. The description adds crucial details: handling of off-calendar fiscal years, specific financial fields pulled, and citation URIs returned. No contradictions with annotations.

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

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

The description is a single dense paragraph; it is efficient but could benefit from slight structuring (e.g., separate bullet for company vs drug). All sentences earn their place, and the key usage examples are 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 tool's complexity (two entity types, multiple data points, cross-entity comparison), the description covers all essential aspects: data sources, sorting behavior, off-calendar handling, and return format. No gaps remain for an agent to understand usage and output.

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 enriches parameter semantics by explaining how 'values' should be formatted per type (tickers/CIKs vs drug names) and that 2–5 items are expected. It clarifies the 'type' parameter's effect on data sources.

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

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

The description opens with natural language examples that instantly convey the tool's purpose: side-by-side comparison of 2–5 companies or drugs. It specifies the data sources (SEC EDGAR/XBRL for companies, FAERS for drugs) and metrics, clearly distinguishing it from siblings like entity_profile or sequential lookups.

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

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

Explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving a clear directive on when to use this tool. It also explains the behavior for each entity type and that results are sorted by primary metric, providing practical guidance for interpreting output.

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

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

Beyond the readOnly, openWorld, and idempotent annotations, the description reveals authentication and paid-tier requirements, latency expectations, structured-source grounding, never-invented gaps[], contradictions[], stable citation behavior, and semantically excerpted records. This materially helps an agent trust and invoke the tool correctly.

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

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

The description is dense and long, but the critical access gate is front-loaded and nearly every sentence adds behavioral or routing value. It loses one point for run-on parenthetical structure and for repeating depth details that already appear in the input schema.

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 thoroughly: findings packet contents, confidence/source/fetched_at, citation_uri fetchability, gaps[], contradictions[], semantic excerpting, and expected latency. Nothing essential to correct invocation 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%, so the baseline applies: the schema already documents the question parameter and the depth enum including the paid thorough tier. The description adds latency context and access constraints, but no meaningful per-parameter semantics beyond what the schema already 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 names a specific action, grounded multi-source research, a concrete resource, Pipeworx's 1517 structured data sources, and the decomposition-and-parallel-routing behavior. It explicitly differentiates from open-web search and from the ask_pipeworx sibling, so confusion between nearby tools is unlikely.

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

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

It gives direct routing rules: use ask_pipeworx when not signed in, use deep_research for broad or multi-part structured-data questions, and use ask_pipeworx for a single lookup. It also explains depth-tier selection including paid restrictions, making when-to-use guidance explicit and practical.

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

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

Annotations declare readOnlyHint, idempotentHint, and no destructiveness. The description adds that results are 'ready to call directly, no second schema lookup needed,' which provides useful behavioral insight beyond the annotations. However, it does not elaborate on rate limits or pagination.

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

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

The description is dense but well-structured. It starts with a concise purpose statement, then details return value, usage context, and parameter aliases. A minor improvement could be splitting into two shorter paragraphs, but it's informative without redundancy.

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

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

Given the complexity of tool discovery, the description covers all necessary aspects: what it does, what it returns, when to use it, and parameter details. The absence of an output schema is adequately compensated by explaining the result format (names, descriptions, full schemas).

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by listing aliases for the query parameter (task, q, description, search) and explaining the limit parameter. This clarifies the flexible input format.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It specifies the return value (top-N tools with full schemas) and distinguishes itself from sibling tools by being the discovery gateway to call first.

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

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

Explicit guidance to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This tells the agent when to use the tool and provides context for prioritization.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses a rich set of behaviors: parallel fan-out across many sources, resolved_from/resolved_to behavior, sources_used/sources_failed semantics, the meaning of empty sections, name resolution via SEC EDGAR, and private-company handling. This is substantial context an agent needs to interpret results correctly.

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

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

The description is long but information-dense, with essentially every sentence contributing distinct value about sources, return fields, parameter shapes, or edge cases. It is front-loaded with user-intent examples and a clear purpose, though the single dense paragraph format could be better structured with separation between invocation, behavior, and parameter handling.

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

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

Given there is no output schema, the description does an excellent job explaining return contents: CIK/company_name, resolved_from/to, recent_filings with URIs, fundamentals, sources_used/sources_failed, LEI, and the semantics of empty sections. It also covers valid input formats and private-company behavior, making it nearly self-sufficient for correct invocation and interpretation.

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

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

The input schema already describes both parameters thoroughly, including accepted formats, examples, and interchangeable type behavior, so the baseline is 3. The description mostly repeats the same examples and details rather than adding new parameter-level semantics, though it does reinforce the 'value' can be a ticker, CIK, or name.

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

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

The description clearly states a specific verb-resource pair: producing a 'full cross-source profile of a US public company' in one parallel call. It also distinguishes this from chaining single-pack SEC/XBRL/news lookups and provides representative user phrasings, making the tool's scope immediately recognizable.

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 chaining single-source lookups when a holistic view is requested, which is strong usage guidance. It also states that private companies return resolved:false rather than a bare failure. However, it does not explicitly call out comparison or entity-resolution sibling tools like compare_entities or resolve_entity, leaving some boundary cases to inference.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. The description adds context about clearing sensitive data but does not elaborate on side effects beyond deletion.

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 action and resource.

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

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

Single parameter fully documented in schema. Description covers purpose, usage, and relationships. No output schema needed for this straightforward tool.

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

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

The schema already describes the 'key' parameter as 'Memory key to delete' (100% coverage). The description adds no additional semantic 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 verb 'Delete' and resource 'previously stored memory by key'. It distinguishes from sibling tools by mentioning pairing with 'remember' and 'recall'.

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

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

Explicitly provides when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also suggests pairing with other tools for 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 indicate readOnlyHint, idempotentHint, and nondestructive behavior. The description adds process details: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' This goes beyond annotations by explaining what happens during invocation.

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

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

The description is two concise sentences followed by a bullet list of use cases. It is front-loaded with the main purpose and contains no unnecessary words or redundancy.

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

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

Given the tool has only 2 parameters, full schema coverage, and rich annotations, the description covers the essential aspects: what it does, how it works, and when to use it. The output format is described as 'a single text blob', which is adequate for a tool 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% with both parameters fully described. The description mentions 'for any URL' and implies default/max for max_links through context, but does not add significant new semantics beyond the schema. Baseline of 3 is appropriate.

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

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

The description explicitly states the tool generates a 'production-ready llms.txt file for any URL', clearly identifying the verb (generate), resource (llms.txt), and scope (any URL). This distinguishes it from siblings like 'ai_visibility_check' or 'scan_competitor_ai_presence', which have different purposes.

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 use cases: 'getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.' While it doesn't explicitly state when not to use it or name alternatives, the context is clear and sufficient for an agent to decide.

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

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

Annotations already indicate safe read operation; description adds value by specifying return fields and default behavior (active only). 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 action, no wasted words. Every sentence earns its place.

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

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

Despite no output schema, description fully explains return fields and typical usage, making it 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 covers 100% of parameters with descriptions, so description doesn't need to add more. 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 'List the caller's active subscriptions' and specifies the exact fields returned, distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

Explicitly guides when to use: 'review what you're monitoring before adding more or to find an id to cancel.' Could more directly state when not to use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the returned metadata fields (id, name, size, etc.), providing context beyond annotations without contradiction.

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

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

Two concise sentences that front-load the action and key details, with no extraneous information.

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

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

For a simple read-only tool with one parameter and good annotations, the description covers purpose, usage context, and return fields completely.

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 a clear description for the 'id' parameter. The tool description restates that it identifies the item by ID, but adds no additional 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 retrieves full metadata for a single OneDrive file or folder by ID, listing specific fields returned. It distinguishes from siblings by advising use after listing or searching to inspect one document.

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

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

The description explicitly guides when to use this tool ('Use after listing or searching to inspect one document'), but does not provide a when-not-to-use or mention alternatives like onedrive_get_file_content for content retrieval.

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. The description adds critical behavioral traits: content is capped at ~100,000 characters and flagged when truncated; binary formats return unreadable bytes. This provides complete transparency beyond annotations.

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

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

Two sentences, front-loaded with the core action, no redundancy. Every word adds value: usage context, format warnings, and size limit. 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?

Given a single required parameter and no output schema, the description fully covers input (id), output behavior (text content, truncation, binary issues), and limitations. 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 has 100% coverage with one parameter 'id' described as 'The OneDrive drive-item id of the file to read.' The description repeats 'by its item id' but adds no new semantics. Baseline 3 applies as schema already fully documents the 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 tool downloads and returns text content of a OneDrive file by item id, specifying compatible formats (plain-text, Markdown, CSV) and distinguishing from binary files. This differentiates it from siblings like onedrive_get_file (metadata) and onedrive_list_files (list).

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

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

The description explicitly indicates best use cases (plain-text files) and warns against binary formats. It also notes content cap and truncation flag, enabling informed selection. While it doesn't name sibling alternatives, the guidance is sufficient for correct 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 indicate read-only, idempotent, non-destructive behavior. Description adds the return fields and confirms it's for profile info, which is consistent and adds value without contradiction.

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

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

Two concise sentences covering purpose and usage with zero wasted words. Front-loaded with the key action and resource.

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

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

Despite lacking an output schema, the description enumerates the return fields, making the tool's behavior fully understandable. No gaps for a simple profile retrieval tool.

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

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

No parameters, so no need for additional explanation. Baseline score of 4 applies as the description doesn't need to compensate for missing parameter info.

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

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

Clearly states the verb 'Get' and the resource 'user's OneDrive drive profile', listing specific return fields (drive type, storage quota used/total, owner display name). Distinguishes from siblings like onedrive_get_file which focus on files.

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

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

Provides explicit use cases: 'report storage usage or confirm the connected account'. While it doesn't mention when not to use, the context is clear given the narrowly scoped purpose.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds that the tool returns a list with specific fields (id, name, size, isFolder, last-modified time, web URL), which is useful but does not provide further behavioral context like authentication or rate limits. The description does not contradict annotations.

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

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

The description is extremely concise: two sentences covering purpose, usage, return fields, and use case. No redundant or filler words. Every sentence contributes actionable information.

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

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

Given the tool has 2 parameters, no output schema, and annotations providing safety context, the description covers the core functionality, usage instructions, and return fields. It lacks mention of the 'top' parameter for pagination, but the schema covers that. Overall, it is mostly complete for a browsing tool with good schema and annotations.

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

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

Schema coverage is 100% with both parameters described. The description adds extra value by stating 'Pass a folder path relative to the drive root' and providing concrete examples ('Documents', 'Documents/Reports'), which aids understanding beyond the schema's formal descriptions. This clarifies the relative path 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 clearly states the tool lists files and folders in a OneDrive folder, specifying the verb and resource. It provides example paths and distinguishes from siblings like onedrive_get_file (which retrieves a specific file) and onedrive_search_files (which searches across folders). The purpose is specific and unambiguous.

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

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

The description explains how to use it: pass a folder path relative to the root, or omit for root. It states 'Use to browse a user's OneDrive documents,' giving a clear usage context. However, it does not explicitly mention when not to use it or contrast with alternative sibling tools, though sibling names are available in the 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 read-only, non-destructive, idempotent, and open-world behavior. The description adds value by specifying exactly what is returned (name, web URL, who shared it), which is not in annotations. 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 consists of two efficient sentences: the first states purpose and output, the second gives a use case. No fluff, no repetition, and the key information is front-loaded. Every sentence carries weight.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and strong annotations, the description covers purpose, output, and usage. It could mention that results are limited by the 'top' parameter, but that is already in the schema. Overall, it provides sufficient context for correct invocation.

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

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

The only parameter 'top' is fully described in the input schema (max items, default 25). The description does not add any additional meaning or constraint beyond what the schema provides. With 100% schema coverage, scoring 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 lists files and folders shared with the user (Shared with me), identifies returned fields (name, web URL, sharer), and gives a specific use case (find documents shared by colleagues). This distinguishes it from sibling tools like onedrive_list_files (user's own files) and onedrive_search_files (search).

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

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

The description provides a clear use context ('find documents shared by colleagues'), but does not explicitly state when not to use this tool or name alternative tools. However, the intended usage is clear enough that an agent can infer appropriate vs inappropriate scenarios given the sibling tool names.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds search scope and return fields, which is useful context without contradicting annotations.

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

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

Two concise sentences: first explains operation and output, second provides usage advice. 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?

For a simple search tool with well-annotated safety and complete schema, the description provides sufficient behavioral and usage 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 covers both parameters with descriptions. The main description rephrases the query parameter's purpose without adding new meaning.

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 searches OneDrive files and folders by keyword across names and content, lists return fields, and is distinct from sibling tools like onedrive_get_file or onedrive_list_files.

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 keyword-based document finding but does not explicitly state when not to use or compare to alternatives.

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

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses important behaviors: filing without an account returns a claim_token for later status checks, the rate limit (5 per identifier per day), that it's free/doesn't count against quota, and that reports are read daily. It also instructs not to paste end-user prompts, adding workflow context.

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

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

The description is dense but purposeful; every sentence contributes (purpose, when to use, exclusion, claim_token flow, rate limit, cost). It is front-loaded with the main action and then details, though slightly long, it reads efficiently for a tool with these nuances.

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 covers the claim_token return behavior, the only output-relevant detail. It covers prerequisites (tool must be from this connection), rate limits, and how to structure the report, making it complete for an agent to invoke correctly.

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

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

The schema already describes all params at 100% coverage, including enum meanings and nested context. The description adds a concrete usage example for claim_token (pipeworx_feedback({claim_token:"pwfb_…"})) and guidance to describe issues in terms of Pipeworx tools/packs, which helps with the context/message. This goes beyond the schema but is not exhaustive.

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

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

The description opens with a specific verb+resource ('Tell the Pipeworx team something is broken, missing, or needs to exist') and immediately enumerates use cases (bug, feature/data_gap, praise), distinguishing it from sibling tools like ask_pipeworx or suggest_questions. It makes clear this is the feedback channel for this MCP connection 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: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a clear exclusion: do not report issues for tools from a different MCP server, file with that server instead, and clarifies Pipeworx tool identification.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by revealing caching behavior (5min-1h), data source (CF analytics-engine), and privacy (no PII). This fully discloses what the tool does behind the scenes.

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

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

The description is one paragraph but uses clear bullet points for use cases. It is concise yet covers purpose, usage, data source, and caching. No superfluous sentences; every sentence adds value.

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

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

Despite lacking an output schema, the description fully explains what is returned (top tools, top packs, total call volume), how it is computed, and its freshness. Given the tool's simplicity, this is sufficiently complete for an agent to understand the tool's functionality.

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

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

The schema already covers the 'window' parameter with enum descriptions. The description adds extra semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This adds value beyond the schema, justifying a 4.

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

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

The description clearly states the tool returns trending data (top tools, top packs, call volume) over specified windows. It distinguishes itself from siblings by focusing on aggregated usage statistics rather than direct queries or entity lookups.

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

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

The description enumerates three explicit use cases (discovering hot data sources, confirming canonical tools, aligning use cases with agent demand), providing strong context for when to use the tool. It does not explicitly list when not to use it, but the positive use cases are sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context: details on partition checks, semantic anchor for similarity, placeholder filtering, and the fill check that determines realizable edge. 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 relatively long but front-loads the purpose in the first sentence. Every sentence adds value, covering modes, semantic anchor, partition filter, response structure, and fill check. A bit dense but appropriate for the tool's complexity; could be slightly more structured with bullet points.

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

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

Despite no output schema, the description thoroughly explains the response format (opportunities[] with gap_pp, suggested_trade, etc.) and even covers edge cases like fill check and placeholder filtering. It also references related tool polymarket_fill_risk for custom sizing, ensuring the agent knows where to go for more.

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% (both event and topic have descriptions), and the tool description greatly enriches understanding. It explains the purpose of each parameter in detail, provides example values ('fed-decision-may-2026'), and describes the behavioral difference between event and topic modes.

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 a clear verb-resource statement: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes itself from sibling tools (e.g., polymarket_edges) by focusing on arbitrage detection, making its unique purpose immediately evident.

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 each argument: no args for trending, event for specific market, topic for cross-event. It also gives recommendations (e.g., 'event (recommended for a specific market)'). While it mentions a fill check filter to avoid non-realizable trades, it does not contrast with alternatives like polymarket_fill_risk in terms of when to use this tool vs. others.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds extensive detail: explains three model families, caching at KV level keyed on all knobs, and computation details like slippage subtraction and Kelly capping. 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 long (over 400 words) and dense, but it is front-loaded with the main purpose. Some sections could be more concise or structured with bullet points, but it remains informative. Given the complexity, it is acceptable but not optimally 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?

No output schema is provided, but the description details the response structure including by_segment segments, fed_candidates, and _diagnostics. It covers all aspects of the tool's behavior, parameters, and response format, making it complete for an agent to use effectively.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond the schema. For example, it explains why slippage_pp default is 0.3, what min_partition_leg_kelly does for partitions, and provides practical guidance like 'Bump for very thin partitions; drop to 0 if you have a smarter fill model.'

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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, and the first sentence 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price' provides a specific verb-resource pair. It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on disagreement scanning rather than pure arbitrage or tracking.

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 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets,' providing clear usage context. It also notes Fed bets are excluded from ranking, but does not explicitly state when NOT to use it. However, the differentiation from siblings implies usage boundaries.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral details: response structure (tracked, expired, snapshot_dates), limits (60-day TTL), and that decay is based on daily closes. 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 appropriately sized given the complexity. It fronts the core purpose, then describes args, response, and limits. Every sentence adds value, though the response section is somewhat lengthy but necessary due to lack of output schema.

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

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

With no output schema, the description fully explains the return fields (tracked, expired, snapshot_dates) and their subfields (trend, decay_pp_per_day, lifespan_days). It also notes limitations (60-day TTL, daily closes). Minor improvement would be to explicitly state the response is JSON.

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

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

Input schema coverage is 100% with descriptions for both parameters. The description repeats and slightly expands on the schema (e.g., 'clamp 2-30' is already in schema). It adds no critical 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 provides 'edge persistence and decay telemetry' and answers 'how long has this edge existed and is it shrinking?' It distinguishes itself from sibling polymarket_edges by focusing on historical tracking rather than current edges.

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

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

The description gives context on when to use the tool ('a fresh wide edge and a 3-week-old wide edge are different trades'), implying it's for evaluating edge age and decay. It does not explicitly list exclusions but the sibling tools provide alternatives.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds behavioral specifics: walks the order book ladder, returns verdicts (clean/degraded/cannot_fill), and describes basket fill risks. 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?

Description is thorough but somewhat lengthy. However, it is well-structured with uppercase mode labels and clear separation of single-market vs basket details. The first sentence captures purpose, and information is front-loaded. Could be trimmed slightly, but remains effective.

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?

Compensates for missing output schema by detailing return fields for both modes (e.g., top_of_book, vwap_fill_price, capture_ratio, per-leg detail). Covers edge cases like thin_legs and forced_directional_risk. Complete enough 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%, but description adds significant modal context: explains how 'side' and 'size_usd' differ between single-market and basket modes. This goes beyond the schema descriptions, providing clear usage 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?

Description clearly states the tool's purpose as a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It explicitly differentiates from siblings like polymarket_arbitrage by advising to use this tool before acting on arb signals.

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

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

Provides explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains consequences of not using it (unhedged directional positions), effectively serving as a best-practice advisory.

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 only establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds substantial beyond-schema behavior: what compatibility_codes mean, that `temporal_alignment_unknown` is not confirmation of alignment, that unclassified legs are never paired, that fees are gross not net, and which comparisons are skipped and why. This is exactly the behavioral depth an agent needs.

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

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

The description is long and dense, but it is front-loaded with the core purpose before moving to modes, response shape, safety fields, and fees. Some redundancy exists, such as repeating 'BOTH modes' and 'in EITHER mode' across adjacent sentences, which keeps it from a 5, but every section carries needed information for correct invocation and result interpretation.

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

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

There is no output schema, so the description must carry the return-contract burden. It does: leg-by-leg prices, `top_spreads_pp`, per-entry `flags[]`, `skipped_unclassified`, `low_confidence_pairs[]`, `temporal_alignment`, `fees_note`, and skipped-cross counters are all explained with their edge cases. An agent can safely call the tool and interpret its results without further documentation.

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

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

Because the schema already covers all three parameters at 100%, the baseline is high. The description still adds meaningful semantics: `topic` triggers auto-fetching on both venues, while the explicit ticker/slug parameters override the topic-mapped side, and both modes run the same matcher. The field meanings are richer in the description than in the schema, though the schema already did most of the work.

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 exact resource and function: a cross-venue spread between Kalshi and Polymarket for the same resolving question. The two-mode explanation (topic shortcuts vs explicit ticker/slug) and the token-overlap matcher further differentiate it from nearby siblings like polymarket_arbitrage and polymarket_edges, even though no sibling is named explicitly.

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

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

The description gives clear mode-selection guidance: use `topic` for the ten pre-mapped shortcuts, or provide explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings. It also warns that pre-mapped topics are often not tradeable and that compatibility fields must be read. It stops short of explicit when-to-use-versus-alternative routing to siblings like polymarket_arbitrage, so it does not earn a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds scoping detail and dual behavior (retrieve vs. list). No contradictions.

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

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

Three sentences, front-loaded with action, each sentence adds necessary information: action, use case, scoping, and pairing. No wasted words.

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

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

Given the tool's simplicity and rich annotations, the description is complete. It could optionally mention the return format, but not essential.

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 value by explaining the optional key parameter and its effect (omit to list all keys). This clarifies behavior beyond the schema's definition.

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 retrieves a value by key or lists all saved keys, distinguishing it from siblings 'remember' and 'forget'. It uses specific verbs and provides examples like 'user's target ticker'.

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

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

Explicitly says when to use: 'look up context the agent stored earlier... without re-deriving it from scratch'. Implicitly excludes alternatives by mentioning 'pair with remember to save, forget to delete'.

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 the mark_read side-effect, which is critical for agent understanding. But this directly contradicts the annotations' readOnlyHint: true, creating a factual conflict. The description adds context beyond annotations but at the cost of inconsistency.

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

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

Three sentences covering purpose, return fields, filters, side effects, and alternatives. Front-loaded with critical info, 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?

Describes return values, filtering, side effects, and alternative endpoint. No output schema, but covers key agent needs. Could mention pagination or rate limits, but overall adequate for a read-like tool with 5 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 coverage is 100%, so baseline is 3. The description adds extra value by explaining mark_read's effect on subsequent calls and providing examples for type and since, raising the score to 4.

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

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

The description clearly states it pulls fired events from the subscription feed, listing specific returned fields (source, citation_uri, raw payload). This verb+resource distinction sets it apart from siblings like list_subscriptions.

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

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

Provides explicit filtering options (type, since), mark_read behavior, and notes that polling works and an alternative endpoint exists. However, it does not explicitly state when to avoid this tool or compare to siblings like list_subscriptions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds valuable context: data sources (SEC EDGAR, GDELT/GNews fallback, USPTO), window format, and return structure (changes[] grouped by source, total_changes, 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 fairly long but every sentence adds value. It is front-loaded with usage examples. Minor room for trimming but not wasteful.

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 required parameters and no output schema, the description fully covers input semantics, output format, alternative tool, and behavioral traits. Complete for correct invocation.

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

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

Schema coverage is 100%, but the description adds significant meaning: explains type is only company, value can be ticker or CIK with example, since accepts ISO date or relative shorthand examples. Exceeds baseline.

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

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

The description clearly states the tool aggregates changes (SEC filings, news, patents) for a company over a time window. It provides specific examples like "What's new with X" and explicitly distinguishes from sibling tool 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 gives explicit when-to-use guidance with examples, explains the supported entity type (company only), and contrasts with entity_profile for static profiles. No ambiguity.

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

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

Description adds context beyond annotations: key-value scoping by identifier, session vs persistent memory, 24-hour retention for anonymous. Does not contradict idempotentHint or other 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?

Four well-structured sentences, front-loaded with purpose, no wasted words. Efficiently covers purpose, usage, and behavior.

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

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

Given no output schema (write tool), description fully covers storage behavior, persistence, and pairing with recall/forget. Complete for all relevant aspects.

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

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

Schema coverage is 100% with clear descriptions. The description adds practical examples of key values (e.g., 'subject_property'), providing extra semantic guidance beyond the schema.

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

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

The description clearly states the tool saves data for reuse across conversations/sessions with specific examples (ticker, address, preference, research subject). It distinguishes from siblings 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 says when to use: when discovering something worth carrying forward. Provides context on persistence (authenticated vs anonymous) and mentions paired tools recall and forget.

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

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

Despite already having readOnly, openWorld, idempotent, and non-destructive annotations, the description adds substantial behavioral context: graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` reporting instead of omission, returning `figi_candidates` when a name matches multiple instruments, source-labeling of every identifier, and internal cascade replacing 2-3 manual lookups. This far exceeds what annotations alone convey.

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

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

The description is long but front-loaded with the core purpose and trigger, and most of its length earns its place given the tool's complexity and absence of an output schema. Some repetition and exhaustive parenthetical examples could be trimmed, but the structure keeps the immediate 'when to use' information first.

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

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

With no output schema, the description carries full responsibility for explaining return semantics, and it does so thoroughly: resolved identifiers, unresolved items, multiple-candidate handling, source attribution, graceful degradation, and input formats. Nothing essential for an agent to call this tool correctly 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?

Although schema coverage is 100%, the description significantly enriches both parameters: it enumerates accepted identifier forms (ticker, CIK, ISIN, name), explains ISIN-to-LEI entity resolution, and provides critical usage guidance such as passing the issuer name exactly as printed for bonds and never appending trailing security-class words. This is materially more than 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 states a precise verb and resource: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It clearly scopes supported types (company, drug) and positions itself as the prerequisite ID-resolution step, differentiating it from sibling tools like entity_profile that operate on already-resolved 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?

The description gives an explicit trigger: 'Use FIRST whenever you have a name but need an ID,' along with numerous real-world phrasings ('What's the ticker for…', 'find the CIK for…'). However, it does not explicitly state when not to use this tool or name alternative tools that might be more appropriate for later steps, so it stops short of full when/when-not coverage.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds behavior: probes each entity with ai_visibility_check, ranks by score, and treats first entity as subject. No contradictions.

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

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

Three sentences with front-loaded purpose, method, and use case. Every sentence adds value; no fluff.

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

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

Given no output schema, the description explains the return value (ranked list with score, confidence, signal density). It covers all parameters' behavior and expected output format completely.

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 significant meaning: entities first is subject, models default to workers-ai, context disambiguates. This goes beyond schema and aids correct 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 compares AI visibility across multiple entities, using ai_visibility_check, and ranks results. It distinguishes from sibling ai_visibility_check (single entity) and provides a concrete use case example.

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 recommends use for competitive AI-marketing audits and gives an example question. However, it does not explicitly state when not to use or list alternatives like compare_entities or single-entity checks.

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

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

Annotations already declare safe, read-only, idempotent behavior. Description adds critical details: composite fan-out, partial failures, bundlephobia timing (5-30s), graceful degradation with sources_failed field. 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?

Well-structured, front-loading composite nature then usage then returns. Every sentence is valuable. Slightly lengthy but justified by the tool's complexity.

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

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

Despite no output schema, description details return fields (summary, advisories, links, alternative versions). Covers parameters, behavior, failure modes, ecosystem constraints. Complete for a complex composite tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor context: scoped packages are accepted, version defaults to latest. Does not add significant meaning beyond schema, but adequately compensates.

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's a composite check for npm packages, combining deps.dev and bundlephobia. It answers 'is X safe / popular / small' or 'what does adding lodash cost me'. This distinctly separates it from other tools like resolve_entity or validate_claim.

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

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

Explicitly says 'Use whenever an agent asks...' and limits to NPM ecosystem, mentioning alternatives for other ecosystems. Provides concrete when-to-use guidance.

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

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

Beyond annotations (readOnlyHint, etc.), description adds implementation details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation flag. 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?

Four dense sentences, each with purpose: defining action, use case, pairing info, and technical details. No redundancy. Front-loaded with core purpose.

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

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

Despite no output schema, description explains return format (passages with offsets and scores), covers truncation behavior and cap. All parameters are fully described. Complete for a search tool.

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

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

Schema description coverage is 100%. Description enhances parameter understanding: clarifies text max chars, gives query examples, explains limit default and range. Adds moderate value beyond schema.

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

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

Description clearly states it performs semantic search inside a fetched record, with specific examples like SEC filings and articles. It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly states when to use: when the record is too large for the prompt. Provides guidance on saving context and verifying quotes via offsets. Does not explicitly say when not to use, 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds behavioral details: requires authenticated account, webhook auto-disabled after 10 failures, return of subscription id. No contradictions with annotations.

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

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

Description is dense but well-organized: front-loaded with purpose and return, then requirements, types, delivery. Every sentence adds value. Could benefit from bullet points for readability, but current structure is 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?

Covers purpose, requirements, types, delivery options, and limitations. Missing details on return format beyond 'id', and no error cases. For a subscription creation tool with no output schema, it is fairly complete but could improve.

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 significant meaning: explains each subscription type, provides concrete parameter examples (e.g., ticker, items), and elaborates on delivery options (sms verification, webhook signing secret, auto-disable). Greatly enhances agent understanding.

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

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

The description clearly states the verb 'Create' and resource 'proactive monitoring subscription', with explicit return value 'Returns the new subscription id'. It distinguishes from siblings like 'list_subscriptions' and 'unsubscribe' by focusing on creation.

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 clear context: requires Pipeworx OAuth account, lists supported types with examples, and delivery channel limitations (phone verification, 10/day cap). Does not explicitly state when not to use or name alternatives, but context is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds context about returning example questions drawn from a live catalog and calling behavior (no args vs topic). 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 somewhat long but well-structured: starts with example queries, explains return type, then usage instructions. Every sentence is informative, but minor redundancy could be trimmed.

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

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

Given the tool's role (onboarding with example questions) and minimal schema, the description adequately covers purpose, input, and output nature (category-bucketed examples with tool shapes). No output schema, but 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 100% for the optional topic parameter. Description adds meaning by listing example values ('finance', 'pharma', etc.) and explaining the effect ('focus on that area') and the default behavior ('omit for cross-category spread').

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

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

The description explicitly states it is the onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It uses specific verbs ('Returns category-bucketed example questions') and clearly distinguishes from sibling meta-tools like ask_pipeworx.

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

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

The description advises to 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also explains when to pass a topic (to focus) and when to omit (for full spread). No explicit when-not-to-use 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?

Beyond annotations (readOnlyHint: false, destructiveHint: false, idempotentHint: true), the description adds key behaviors: the row is deactivated not deleted, and historical events remain available via recent_alerts. This provides valuable behavioral context.

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

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

Two sentences with zero waste. The critical information is front-loaded (cancel, ownership, deactivation) and efficiently communicated.

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

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

For a simple one-parameter tool with no output schema, the description covers purpose, ownership, side effects, and connects to related tools (subscribe, recent_alerts). It is fully 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?

With 100% schema description coverage, the schema already documents the id parameter as a UUID from subscribe. The description does not add extra parameter information, so it meets the baseline expectation.

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 'Cancel a subscription by id' with a specific verb and resource. It also explains ownership enforcement and the deactivation vs deletion distinction, distinguishing it from siblings like subscribe and recent_alerts.

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

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

The description explicitly mentions that ownership is enforced ('you can only cancel your own subscriptions'), guiding the agent on when it's appropriate. It does not explicitly state when not to use or mention 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 provide readOnly/openWorld/idempotent hints, and the description enriches them with concrete behavioral details: the two execution paths, the exact verdict vocabulary, the inclusion of a pipeworx:// citation, and the crucial caller-facing warning that could_not_verify is not evidence. This adds significant value beyond structured hints, with 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 densely packed. It is front-loaded with trigger examples and core purpose, then logically flows through routing, return values, and caveats. Each sentence contributes operational value, so the length is justified for a multi-path, high-stakes verification 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 fully enumerates the possible verdicts (confirmed, approximately_correct, refuted, inconclusive, unsupported, could_not_verify), explains the difference between unsupported and could_not_verify, and describes the error object. It also positions the tool as a replacement for a multi-step pipeline, offering complete context for an agent.

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

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

Schema descriptions cover both parameters at 100%, and the description goes further by explaining tolerance_pct semantics: it overrides the wording-implied tolerance, recommends 1–2 for hallucination detection, and notes the default cap of 5. This practical guidance is exactly the kind of meaning the schema alone cannot convey.

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

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

The description immediately provides natural-language trigger phrases and states 'natural-language claim verification against authoritative sources', clearly specifying the tool's function and unique role. It also distinguishes between financial and non-financial claims, which sets it apart from sibling tools like ask_pipeworx_grounded or 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 explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct' and gives routing rules for company-financial vs. other claims. It also explains that it replaces 4–6 sequential calls, providing clear context on when to prefer this composite tool over chaining simpler lookups.

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