Texas DMV

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. Description adds valuable behavioral context: it discloses that the default model is free (Workers AI) and that Anthropic probing requires a BYO key (with cost implications). Also outlines the return structure per model, enhancing transparency beyond annotations.

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

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

Description is concise (three sentences) with no wasted words. Front-loaded with action, then details, then use cases. Each sentence adds value, and the structure is easy to parse.

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

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

Despite lacking an output schema, the description explains the return format (per-model object with score, confidence, signals, raw_response plus combined view). Parameters are fully covered, and the moderate complexity (4 params, 1 required) is adequately addressed. Minor gap: no mention of error handling or rate limits, but not critical given 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%, but description adds meaning beyond the schema: it explains the default model and free usage, clarifies the API key's purpose, and provides examples for the 'context' parameter (e.g., 'Boston restaurant'). This helps the agent understand how to use parameters effectively.

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 probes LLMs for knowledge about an entity and scores visibility on a 0-100 scale per model. It specifies the return format and use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring), making the purpose unambiguous and distinct from sibling 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?

Provides clear context on when to use (brand audits, competitive monitoring) and details like default model and API key requirement for Anthropic. Lacks explicit when-not-to-use or direct comparison to siblings, but the guidance is sufficient for most scenarios.

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

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

Annotations already establish readOnly/openWorld/idempotent behavior, so the description's main job is to add behavioral context. It does this by explaining that the tool fills arguments automatically, routes across 5,798 tools / 1,517 sources, and returns stable pipeworx:// citation URIs. Nothing contradicts the annotations.

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

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

The description is front-loaded with its most important guidance and uses examples well. However, it is verbose and repeats the same default-message several times ('PREFER OVER WEB SEARCH', 'START HERE for most questions', 'ask_pipeworx is the default'), so not 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?

Even without an output schema, the description conveys what the tool returns (structured answer with citation URIs) and covers a broad set of use cases plus alternatives. For a complex router tool, this is nearly complete, though the tail guidance about ask_pipeworx_grounded could be tightened to avoid confusion.

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

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

Schema description coverage is 100%; the 'question' parameter is documented with its aliases in the schema. The description reinforces natural-language questions with examples but adds no new parameter-level semantics, so the baseline 3 is appropriate.

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

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

The description opens with a strong directive — 'PREFER OVER WEB SEARCH' — and names a concrete resource: questions about current or historical data that route to one of 5,798 tools and return structured answers with citations. This clearly distinguishes ask_pipeworx from generic web search and from sibling tools like ask_pipeworx_grounded and 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?

It explicitly lists trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current') and gives multiple concrete examples. It also specifies when to choose alternatives: ask_pipeworx_grounded for speed/ad-hoc queries, deep_research for breakthrough questions, and a custom pipeline for high-stakes cases. This is as explicit as routing guidance gets.

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?

With annotations already covering the safety profile (readOnlyHint, idempotentHint, non-destructive), the description adds the critical dynamic behavior: candidate routing improvements are 'enabled live' and can change behavior between calls. It gives a precise current state with a timestamp ('No candidate is active right now... retired on outcome evidence 2026-07-26, so this currently matches ask_pipeworx exactly') and reassures that 'Falls back to nothing — this IS a full working router,' preventing the agent from treating it as a stub.

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

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

A single ~90-word paragraph where every sentence earns its place: identity, current state, usage direction, and functional reassurance. It is front-loaded with the most decision-relevant fact (a beta variant of ask_pipeworx with identical behavior), and the precise current-state disclosure appears early.

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 schema (one required string plus aliases) with rich annotations, this is nearly complete: identity, current state, usage condition, and relationship to the stable version are all covered. It doesn't elaborate on what kinds of questions the universal router handles, but 'same 5,798 tools' and the pointer to using it exactly like ask_pipeworx give the agent a path to the full behavioral contract.

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

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

Schema coverage is 100% — all six parameters (question plus five aliases: q, text, input, query, prompt) are documented in the schema. The description adds the useful meta-context that arguments are identical to ask_pipeworx's and the response shape is the same, which helps an agent who knows the sibling's contract, but it doesn't add per-parameter semantics. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The description clearly identifies this as the beta variant of ask_pipeworx — an identical universal router over 5,798 tools with candidate routing improvements — and explicitly frames it as 'the experimental edge' of the stable version. It distinguishes from the sibling ask_pipeworx (stable) and ask_pipeworx_grounded by naming the exact relationship, so an agent can tell them apart without opening either tool's schema.

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

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

The description gives an explicit selection condition — 'Use it exactly like ask_pipeworx when you want the newest routing' — and explains that results are compared against the stable router to decide what merges. It names the direct alternative (ask_pipeworx) and clarifies this is not a fallback, though it doesn't state when not to use it or address how it competes with ask_pipeworx_grounded.

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 richly discloses behavior beyond annotations: it only extracts from the fetched tool result, returns verbatim evidence, and emits explicit refusal reasons when the data doesn't answer. Annotations already mark it read-only and idempotent, and the description does not contradict them.

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

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

The description is front-loaded with purpose, then behavior, usage guidance, and cost tradeoff. Every sentence carries useful information, and the detailed return/refusal format earns its place because there is no 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?

Despite lacking an output schema, the description fully documents the success return shape and the explicit refusal_reason enum. It also provides routing context, scale, usage constraints, and cost guidance, making it 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?

Parameter semantics are fully covered by the schema, which documents the question parameter and its aliases. The description adds no additional parameter-specific meaning, so the baseline of 3 applies.

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

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

The description clearly identifies the tool as a hallucination-resistant, grounded answer mode, with a specific behavior: extract the answer only from the tool result. It also differentiates itself from ask_pipeworx by naming the sibling and describing the grounded/refusal behavior.

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

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

Explicitly states when to use the tool: when answers will be quoted, cited, or acted on and invention is unacceptable. It also gives the alternative: prefer ask_pipeworx for casual lookups, including the cost tradeoff of one extra LLM call.

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

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

The description discloses extensive behavioral traits beyond the annotations (readOnlyHint, openWorldHint, etc.). It details how the tool resolves markets, classifies bets, fans out to data packs, and handles various edge cases like low-confidence matches, closed markets, wide spreads, and resolution rule risks. This adds significant transparency.

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

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

The description is long but well-structured, starting with a summary and then breaking down into sections for classifiers, fan-out examples, response shapes, etc. While it could be slightly more concise, the length is justified given the tool's complexity and the information density.

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

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

Given the tool's complexity (3 parameters, no output schema), the description is remarkably complete. It covers inputs, behavior, response structure, safety checks, and edge cases. Without an output schema, the detailed description of the response shape compensates 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?

With 100% schema coverage, the description still adds value by providing examples (slug, URL, question text), explaining the depth parameter (quick vs thorough), and detailing when to use include_raw. This enhances understanding beyond 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 by pulling Pipeworx data. It specifies the verb 'Research', the resource 'Polymarket bet', and the action 'pulling the relevant Pipeworx data'. This distinguishes it from sibling tools like polymarket_edges or polymarket_arbitrage which have narrower scopes.

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

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

The description explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"', providing clear usage scenarios. However, it does not explicitly state when not to use this tool versus alternatives, though the specificity of the use cases implies its appropriate 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?

Beyond annotations (readOnly, idempotent), it discloses that company data comes from SEC EDGAR/XBRL with correct fiscal year handling, and drug data from FAERS/FDA. It also states results are sorted by primary metric, and returns citation URIs.

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

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

Description is front-loaded with key purpose and trigger examples, then follows with parameter details. Each sentence adds value, no wasted words.

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

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

Given the tool's complexity (two entity types, multiple data sources), the description fully explains what each type retrieves, how results are sorted, and why it replaces multiple lookups. No output schema needed; the summary of return format is sufficient.

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

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

Schema coverage is 100%, but description adds significant extra meaning: for each enum value it explains what data is pulled, and for values it specifies tickers/CIKs for company and drug names, with cardinality constraints.

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

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

The description clearly states it performs side-by-side comparison of 2-5 companies or drugs in one parallel call. It provides concrete trigger phrases like 'Compare X and Y' and 'which is bigger', and distinguishes itself from 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 says 'ALWAYS PREFER over sequential single-pack lookups' and gives clear guidance on when to use company vs drug type. The trigger examples help the agent decide when to invoke this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description goes far beyond that by disclosing authentication needs, paid-tier requirements, latency, parallel decomposition, gap handling, contradiction findings, citation fetchability, and the never-invents-answers guarantee.

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

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

The description is dense and front-loaded with the account gate and core purpose. It is long and somewhat redundant with the schema's depth enum, but the additional details about latency, citation semantics, and excerpting behavior justify most of the length.

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

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

This is a complex tool with no output schema, so the description carries the full burden of explaining what the agent can expect. It covers input, output shape, gaps, contradictions, citations, latency, auth, and return-value semantics, making it complete enough 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?

Schema coverage is 100%, so the schema already documents question and depth thoroughly. The description still adds meaningful context by noting that depth:'thorough' requires a paid plan, giving latency guidance per depth, and providing concrete example questions, though most depth mechanics are already in the enum description.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources'. It also differentiates itself clearly with 'this is NOT open-web search' and says 'For a single lookup use ask_pipeworx instead.'

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 — 'Best for broad/multi-part questions over structured data' — and names the alternative, ask_pipeworx, for single lookups or unsigned-in users. It also states the account requirement and the fallback if not signed in.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining that results include full schemas with curated examples and are ready to call without a second lookup. This goes beyond the annotations without contradicting them.

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

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

The description is front-loaded with the core purpose and usage guidance. It lists many example domains, which is slightly lengthy but still useful for context. Overall, it is well-structured and each sentence contributes 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 explains that the tool returns top-N relevant tools with names, descriptions, and full input schemas with examples. This sufficiently informs the agent about the return format. Given the complexity (30 siblings), the description adequately covers what the tool does and when to use it.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions that 'query' accepts natural language and that limit controls 'top-N,' which adds slight context beyond the schema. However, it does not provide detailed semantics beyond what the schema already describes.

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 'Find tools by describing the data or task,' specifying the exact resource (tools) and action (discover). It lists numerous example domains (SEC filings, financials, etc.), making the purpose unmistakable. No sibling tool performs tool discovery, so it is well-distinguished.

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

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

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for' and 'Call this FIRST when you have many tools available.' This provides strong positive guidance on when to use it, though it does not explicitly state when not to use it or name 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 carry readOnlyHint/openWorldHint/idempotentHint/destructiveHint, and the description adds substantial behavior beyond that: the fan-out across eight named sources, USPTO PatentsView soft-fail semantics, the GDELT→GNews fallback chain, empty-section-means-real-no-data, and private-company resolved:false behavior. No contradiction with annotations.

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

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

The description is front-loaded with query examples and every clause carries substantive information, but it is a single dense run-on paragraph of semicolon-separated items with no bullets or breaks. It is wordy for an agent to parse, though none of the content is filler.

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

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

With no output schema, the description must explain return structure — and it does, enumerating cik, resolved_from/resolved_to, recent_filings with URIs, fundamentals fields, and each source section. It also covers failure semantics (sources_failed, soft-fails, empty as real no-data) and edge cases (private companies, name vs ticker vs CIK input). For a tool this complex, nothing essential is missing.

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

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

Schema coverage is 100% — both `type` and `value` are fully described, including the ticker/CIK/name forms and the SEC EDGAR name-resolution note. The description reinforces that 'company' and 'ticker' are interchangeable, but this duplicates what the schema enum description already states. The schema does the heavy lifting; the description adds no new parameter syntax or format details.

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 concrete user intents ('Tell me about X', 'research Acme', 'brief me on Tesla') and states a specific scope: 'full cross-source profile of a US public company in ONE parallel call.' It differentiates from siblings by declaring 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups,' which distinguishes it from single-purpose lookup tools.

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

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

The description gives explicit trigger conditions (holistic-view requests about a company) and an explicit routing rule ('ALWAYS PREFER over chaining single-pack... lookups'). It also covers a key exclusion case: a private company returns resolved:false with a notes line rather than a profile. However, it never names nearby siblings like compare_entities or resolve_entity to say when to choose them instead.

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

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

Annotations already declare destructiveHint: true and idempotentHint: true. The description adds context about clearing 'sensitive data' but does not elaborate on behavior like idempotency or error handling for missing keys. It adds some value but not rich 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?

Three concise sentences: purpose, usage guidelines, and sibling tool mention. Every sentence adds value, and the key information is front-loaded.

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

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

For a simple single-parameter tool with annotations, the description covers purpose, usage context, and behavioral implications (clearing sensitive data). It lacks details on return values or error cases, but given the tool's simplicity, it is fairly complete.

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

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

Only one parameter 'key' with complete schema description ('Memory key to delete'). The tool description adds no additional semantic meaning beyond what the schema provides, 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 action: 'Delete a previously stored memory by key.' It uses a specific verb and resource, and distinguishes itself from sibling tools like 'remember' and 'recall' by implying a deletion action.

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 scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' It also mentions pairing with 'remember' and 'recall,' offering guidance on alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds process details (fetches page, extracts title/description/key links) and output format 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?

Four sentences, front-loaded with purpose, then details, then use cases. No wasted words.

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

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

For a two-parameter tool with full schema coverage and annotation safety profile, the description provides all necessary context including process, output, and use cases.

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

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

Schema has 100% coverage with descriptions for both parameters. Description adds minimal extra value beyond schema, primarily context on output 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?

Description clearly states verb (generate), resource (llms.txt file from any URL), and distinguishes from sibling tools like scan_competitor_ai_presence by specifying the output format and use cases.

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

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

Explicitly lists three use cases (client site indexing, own project drafting, competitor auditing) but does not mention when not to use or name alternative siblings directly.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the exact return fields (id, type, params, etc.), which is helpful beyond the safety profile.

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, no wasted words. The first sentence states the action and output, the second provides usage guidance. Ideal conciseness.

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

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

For a simple list tool with one optional parameter, the description covers purpose, return structure, and usage context. No output schema exists, but the description explicitly lists the returned fields, so completeness is high.

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

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

Schema coverage is 100% (one parameter with a description). The description does not add meaning beyond the schema: it mentions 'active' as default, which aligns with the parameter description, but no extra parameter context is provided.

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

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

The description clearly states it lists the caller's active subscriptions and enumerates the returned fields (id, type, params, etc.), distinguishing it from sibling tools like subscribe or 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 tells the agent when to use the tool: 'to review what you're monitoring before adding more or to find an id to cancel', providing clear use cases and avoiding 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?

Despite all-false annotations, the description discloses meaningful behavior: filing returns a claim_token, passing it later lets you read whether the issue was fixed, and it is rate-limited to 5 per identifier per day. There is no contradiction with annotations; readOnlyHint=false is consistent with submitting new feedback.

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?

Although the description is long, every sentence earns its place: the core purpose is front-loaded, then it expands with exclusions, claim-token usage, rate limits, and impact. There is no filler or redundancy.

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

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

The tool has two modes (submitting feedback and checking status via claim_token), and both are explicitly explained, including what the token returns. With no output schema, the description provides enough return-value semantics, and the schema covers parameter details, making the package complete.

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

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

Since the input schema covers all parameters, the baseline is 3, but the description adds workflow meaning beyond the schema: how a returned claim_token is used (pipeworx_feedback({claim_token:'pwfb_…'})) and the instruction to frame feedback around Pipeworx tools/packs rather than pasting user prompts. This enriches parameter understanding beyond the schema entries.

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

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

The description opens with a specific verb and resource ('Tell the Pipeworx team something is broken, missing, or needs to exist') and enumerates the feedback categories (bug, feature/data_gap, praise). This clearly distinguishes it from the research and visibility sibling tools.

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

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

It explicitly states when to use the tool (bug, feature gap, praise) and gives an important exclusion: tools from other MCP servers should be reported there instead. It also helps disambiguate with 'Not sure? Pipeworx tool names are the ones this connection lists.'

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

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

Annotations indicate read-only, idempotent, non-destructive. The description adds caching behavior (5min-1h depending on window), data origin (CF analytics-engine), and privacy assurance (no PII), going beyond annotations.

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

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

The description is well-structured with use case bullets and concise sentences. Slightly verbose but information-dense and front-loaded with 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?

For a simple tool with one param and no output schema, the description covers purpose, use cases, parameter semantics, caching, and privacy, leaving no critical 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?

The description explains the enum values in terms of trade-offs (short window for hot trends, long window for steady-state), providing meaning beyond the schema's enum list. Schema coverage is 100%, and the description adds value.

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

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

The description clearly states that the tool returns top tools, top packs, and call volume over a specified window, using the verb 'returns' and specific resource. It distinguishes itself from sibling tools by focusing on trending aggregation.

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

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

Three explicit use cases are provided (discovering hot data sources, confirming canonical tool choice, aligning use case). While it does not list when not to use, the guidance is clear and context-rich.

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

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

The description discloses key behavioral traits beyond annotations: threshold for similarity (Jaccard >= 0.30), partition filter for placeholders, fill check against live CLOB depth, and when signals should be ignored. Annotations already mark the tool as read-only and non-destructive, and the description reinforces this with details about the analysis process.

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

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

The description is thorough but verbose, containing many detailed technical explanations that could be streamlined. It is front-loaded with the main purpose and modes, but the dense paragraph structure reduces readability. Every sentence adds value, but the overall length impacts conciseness.

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 the tool (multiple modes, arbitrage detection, fill check, thresholds), the description is highly complete. It explains edge cases, response structure, and provides enough context for an agent to use the tool correctly without needing external documentation.

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

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

Schema coverage is 100% (both parameters documented), so baseline is 3. The description adds significant meaning by explaining the two modes, accepted input formats (slug or URL for event, seed question for topic), and the behavioral differences between them.

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: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk by specifying the core mechanisms and mentioning fill risk separately.

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 mode: no args for trending scan, 'event' for specific event, 'topic' for cross-event scan. It also explains when not to trade (realizable_edge_pp <= 0) and references an alternative tool for custom sizing (polymarket_fill_risk).

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

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, etc.), revealing caching behavior ('Cached 1h at the KV level'), detailed response structure with diagnostics, and the 24h-move warning. It explains how edge is computed net of slippage and the Kelly sizing caps, providing transparency about potential pitfalls.

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

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

The description is well-structured with clear sections for model families, tradeable-edge knobs, and response format. It is front-loaded with the core purpose. However, it is somewhat verbose—some details about model formulas could be moved to the output schema or a separate doc without losing essential guidance.

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

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

Despite having no output schema, the description comprehensively explains the response structure (by_segment, _diagnostics, per-opportunity fields). It covers all relevant behavioral aspects, caching, and edge cases (e.g., empty segments explained via diagnostics). The tool's complexity is fully addressed.

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

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

Although the input schema already has 100% description coverage, the tool description adds significant meaning to parameters. For example, it explains why min_kelly doesn't filter partition arbs and how min_partition_leg_kelly compensates. It also elaborates on the purpose of slippage_pp, min_edge_pp, and tradeable-edge knobs, helping agents set them correctly.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It distinguishes from siblings by focusing on Pipeworx edge detection and structured segments, and explicitly frames it for 'what should I bet on today.'

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

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

The description provides strong usage guidance, explaining when to use each segment (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) and how to use tradeable-edge knobs. It notes that Fed bets are excluded from ranking, adding clarity. However, it lacks explicit comparisons to sibling tools like polymarket_arbitrage or polymarket_edge_tracker, which could help agents decide between them.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context about snapshot gaps, TTL (60-day), and that decay is computed on daily closes not intraday, enhancing transparency beyond annotations.

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

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

The description is detailed but well-structured, starting with a clear intro, then a question format, followed by bullet-like explanation of response fields. It is front-loaded with the core question and includes necessary details without excessive wordiness.

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 and the tool's complexity (time-series decay analysis), the description fully explains the output structure (tracked[], expired[], snapshot_dates[]) and behavioral nuances (gaps, decay computation). It is complete for an agent to understand tool 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% with parameter descriptions. The description restates defaults and constraints (days: default 14, max 30; window: default '1wk'), adding marginal value. No enum or nested objects to further explain.

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: providing edge persistence and decay telemetry. It uses a specific verb 'answers' and resource 'edge persistence and decay telemetry', distinguishing it from sibling 'polymarket_edges' which generates the snapshots.

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

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

The description explains when to use the tool via the example comparing a fresh edge versus a 3-week-old edge, implying it's for assessing edge age and decay. It also describes the response structure and limits, but does not explicitly mention alternative tools or when not to use it.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context like return fields (top_of_book, slippage, etc.) and risk warnings. No contradictions, but could mention any limits or side effects 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?

Description is detailed (~150 words) but well-organized with uppercase markers for modes. Every sentence adds value, though could be slightly more compact without losing clarity.

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 both modes, return fields, defaults, and risk warnings despite no output schema. Lacks explicit statement of no mutations, but annotations cover that. Comprehensive for the complexity.

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

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

Schema coverage is 100%, and description enriches each parameter with mode-specific interpretations (e.g., side defaults, size_usd meaning for buys vs sells, market vs event requirement).

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 tool checks realizable vs theoretical edge against live order book depth for both single-market and basket modes. It distinguishes from siblings like polymarket_arbitrage and polymarket_edges by specifying when to use this tool before acting on their signals.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why (theoretical overround not capturable on thin books, partial fills create directional risk).

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

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

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: compatibility_warning/codes semantics, temporal alignment interpretation, unknown legs never being paired, skipped comparison counters, and the gross-vs-net fee disclaimer. This is exactly the kind of behavioral nuance an agent needs and it does not contradict the annotations.

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

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

The description is long but information-dense, with no apparent filler. It front-loads the core purpose and mode distinction, uses clear uppercase section labels, and ends with a practical caveat about pre-mapped topics; still, a structured bullet format would improve scannability.

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

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

With no output schema, the description carries the full burden of explaining the response shape, safety fields, flags, skipped counters, and fee treatment. It even tells the agent to read non-empty compatibility fields even when matched_pairs is positive, which is critical for correct interpretation. Nothing essential appears missing for a tool this complex.

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

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

Schema coverage is 100%, so the schema itself already documents each parameter's name and example values. The description adds real value by explaining that topic auto-fetches the mapped event on both venues, that the explicit params override the topic-mapped side, and that all modes share the same token-overlap matcher.

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 line unambiguously defines the resource: a cross-venue spread between Kalshi and Polymarket for the same resolving question, with two clear modes of operation. It does not explicitly contrast itself with sibling tools like polymarket_arbitrage or polymarket_edges, so it stops short of the highest clarity bar.

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

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

The description gives strong operational guidance: when to use the pre-mapped topic shortcuts versus explicit event ticker/slug params, and that both modes run the same matcher. It also warns that most pre-mapped topics are not currently tradeable, but it never names alternative sibling tools or says when this tool should not be chosen.

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 and idempotentHint. Description adds behavioral context beyond annotations: scoping to user identifier and behavior when key is omitted. No contradictions.

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

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

Description is front-loaded with the core action and use case. Slightly verbose but every sentence adds value (scoping, pairing with siblings). 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?

Despite no output schema, the description explains purpose, usage, scoping, and relationships with siblings. For a simple read/list tool, this is complete enough for an agent to understand and invoke correctly.

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

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

Schema covers the single parameter fully (100% coverage). The description echoes the schema's note about omitting key to list all. Baseline of 3 is appropriate; description adds no new parameter-level 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 verb ('retrieve' or 'list') and resource ('value previously saved' or 'saved keys'), and distinguishes from sibling tools remember and forget by naming them 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?

Description explains when to use (look up stored context) and implies when not to (use remember to save, forget to delete). Could explicitly mention alternatives, but the sibling context provides that.

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 states mark_read:true flags events as read, implying a write side effect. This contradicts the annotation readOnlyHint=true, which marks the tool as read-only. Such inconsistency undermines trust and could mislead an AI agent.

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

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

Concise paragraph with clear front-loading of main purpose, followed by relevant details. No redundant sentences.

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, description adequately lists returned fields (source, citation_uri, payload) and covers key behaviors (filtering, mark_read). Lacks pagination details but sufficient for a list tool.

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

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

Schema covers 100% of parameters with descriptions. The description adds value by giving examples (e.g. 'sec_8k'), explaining mark_read behavior, and noting ISO timestamp format, enriching parameter understanding beyond schema.

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

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

Description clearly states the tool pulls fired events from subscription feed, specifying fields returned (source, citation_uri, payload). It distinguishes from sibling tools by focusing on recent alerts and subscription feed context.

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

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

Provides guidance on polling, filtering options, and mentions an alternative access method (GET registry.pipeworx.io/alerts.json). Does not explicitly exclude usage scenarios but gives enough context for typical use.

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

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

Annotations indicate readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral details: fans out to multiple sources, fallback behavior, soft-fail for USPTO, and date shorthand acceptance. 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?

Description is detailed but front-loaded with examples. Every sentence contributes useful information. Slightly verbose but well-structured.

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

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

No output schema, but description describes return structure (changes[] grouped by source, total_changes, citation URIs). Covers multiple data sources, fallback, and date formats. 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 all 3 parameters with descriptions and enum. Description reinforces 'since' shorthand and provides usage recommendation ('30d' or '1m'). Adds extra context beyond schema, earning a score above 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 it provides a change feed for a company in a time window, with example queries and explicit distinction from sibling tool entity_profile. The verb 'change feed' and listing of sources (SEC, GDELT, USPTO) make the purpose unambiguous.

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

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

The description gives explicit 'when to use' with example queries and 'when not to use' with a direct instruction to use entity_profile for static profiles. It also explains fallback logic between GDELT and GNews.

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

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

Discloses key behavioral traits beyond annotations: key-value pairing, scoping by identifier, persistence differences (authenticated vs anonymous). No contradiction with annotations (idempotentHint=true is consistent with overwriting).

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?

Highly concise: three sentences covering purpose, usage, and behavior. Front-loaded with the core action, no redundant words.

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

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

For a simple key-value tool with no output schema, the description provides complete context: purpose, when to use, scoping, retention, and sibling relationships. 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 covers both parameters with descriptions (key: example patterns, value: any text). Description does not add new parameter info, 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 starts with a specific verb 'Save data' and resource 'the agent will need to reuse later', clearly stating the tool's purpose. It distinguishes itself from sibling tools like recall and forget by positioning remember as the store operation.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward'. Mentions pairing with recall and forget, but does not explicitly state when not to use. Still, provides sufficient context for correct invocation.

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

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

Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior, so the description goes well beyond that by disclosing internal cascading through multiple lookup endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, and the explicit handling of unresolved identifiers under `unresolved`. This is valuable behavioral context a caller would not otherwise 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 long and dense, but the length is justified by the tool's dual entity types and multiple lookup sources. It is front-loaded with query examples and the core directive, though some nested parentheticals make scanning harder than it could be.

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 and two complex entity types, the description covers return fields, provider sources, input edge cases, and failure behavior. An agent has nearly everything needed to decide when to call it and how to format both `type` and `value` correctly.

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

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

Schema coverage is 100%, but the description adds substantial parameter meaning: it lists accepted formats (ticker, CIK, ISIN, company name), distinguishes drug brand vs generic input, and gives a critical warning about bond issuer names needing exact printed name without trailing security-class words. This goes far beyond the schema's basic descriptions.

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

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

The description opens with concrete natural-language queries and states a precise verb-resource relationship: resolving user-spoken names to canonical/official identifiers that other tools require. It enumerates supported entity types and distinguishes this from siblings like entity_profile or validate_claim by framing it as the ID-lookup entry point.

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

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

It explicitly instructs 'Use FIRST whenever you have a name but need an ID,' which gives the agent a clear routing rule. It does not name alternative sibling tools or provide explicit 'when not to use' conditions, but the main usage context is unmistakable.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds how it works (probes, ranks) and what it returns (score, confidence, density). No contradictions, but doesn't discuss potential side effects like API key requirements or rate limits.

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

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

Three sentences: action, method, use case. Every sentence adds value. 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?

Given no output schema, the description adequately explains the return format (ranked list with fields). It covers the tool's scope and limitations (2-8 entities mentioned in schema). Could mention behavior when API key is missing for anthropic model, but not critical.

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 does not add information beyond what the schema provides for parameters; the schema already explains the 'first entry' treatment and allowed values.

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 compares AI visibility across multiple entities, mentions probing with ai_visibility_check, and ranks results. It distinguishes itself from siblings like ai_visibility_check (single entity) and compare_entities (generic comparison) by focusing on AI presence metrics.

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

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

Provides a concrete use case: 'competitive AI-marketing audits' and quotes a relevant question. Implicitly suggests using ai_visibility_check for single entities, but does not explicitly list alternatives or when to avoid this tool.

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

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

Annotations indicate readOnly, openWorld, idempotent, non-destructive. Description adds behavioral context: fans out across two services, bundlephobia first measurement can take 5-30s, sources_failed lists timeouts, partial failures degrade gracefully. No contradictions.

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

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

Well-structured: first sentence states purpose, then sources, usage, output summary, scope, failure handling. Front-loaded with key verb and resource. Every sentence adds value despite length.

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

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

No output schema exists, so description must cover output format. It does: summary block with specific fields, per-advisory detail, links, and recent alternatives. Also covers ecosystem limitation and partial failure behavior.

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

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

Schema describes both parameters (package, version) with 100% coverage, including default behavior. Description adds minimal extra parameter info (scoped packages accepted) but confirms schema details. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool performs a composite check for npm packages combining deps.dev and bundlephobia data, answering questions about safety, popularity, and size. It distinguishes from siblings by noting other ecosystems use deps.dev:version directly.

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

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

Explicitly states when to use: when asked 'is X safe/popular/small' or 'what does adding lodash cost me'. Also specifies when not to use: for non-NPM ecosystems (PyPI/Maven/Cargo/Go) use deps.dev:version directly.

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 technical details (BGE-base-en, 500-char windows, 200K cap with truncation flag) and return format (offsets, similarity), going well beyond annotations.

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

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

Single well-structured paragraph, front-loaded purpose, no wasted words. All technical details are relevant and earned.

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

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

No output schema, but description fully explains return values (passages with offsets and scores), cap, encoding, and pairing. Complete for a single-tool search operation.

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 100%, baseline 3. Description adds example queries for 'query' and clarifies return structure (offsets, similarity). Provides more context than 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?

Clearly states 'semantic search INSIDE a fetched record' with specific verb and resource. Distinguishes from siblings by emphasizing context-saving and offset-based verification, and explicitly pairs with ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and explains benefits. Mentions pairing with ask_pipeworx_grounded, providing clear context. 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?

Adds significant behavioral details beyond annotations: requires OAuth, returns id, delivery channel behaviors (feed always on, email/sms/webhook specifics, webhook auto-disable, sms cap). No contradictions with annotations.

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

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

Well-structured with front-loaded purpose, requirements, types, delivery. Each sentence adds value, but could be slightly more concise.

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

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

Covers return value, requirements, type-specific params, delivery channels. Missing error scenarios or duplicate behavior, but idempotent hint covers that. Mostly complete.

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

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

Schema coverage is 100%, but description adds extensive examples and clarifies structure for each type and delivery channel, e.g., items array for sec_8k, webhook secret handling.

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

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

Clearly states it creates a proactive monitoring subscription, returns subscription id. Differentiates from sibling tools like list_subscriptions and unsubscribe. Provides examples of supported types.

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

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

Specifies when to use (proactive monitoring), requirements (Pipeworx OAuth), and lists supported types with examples. Does not explicitly state 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 already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by explaining return content (category-bucketed example questions with tool+argument shapes), that it draws from live catalog, and effect of topic parameter. No contradictions.

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

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

Description is moderately long but well-structured, starting with common queries, then explaining return format and usage. Every sentence adds value. Could be slightly more concise but still 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?

For a simple tool with one optional parameter and no output schema, the description is very complete: it covers purpose, return content, usage, and when to use it. No gaps given the tool's role as an onboarding entry point.

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

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

Schema coverage is 100% with the single optional parameter described. Description adds examples of topic values ('finance', 'pharma', 'betting') and explains focusing effect, going beyond schema description. Good value added.

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 explicitly states it's an onboarding entry point to discover what questions to ask Pipeworx, listing example categories and return format. Title 'What Can I Ask Pipeworx?' clearly conveys purpose. Siblings like ask_pipeworx are for actual querying, distinguishing this tool.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools...' providing clear context for use. No explicit when-not-to-use, but the guidance is clear and specific.

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 read-only, open world, idempotent, non-destructive. Description adds that data is one row per fiscal year, covers 2001–2021, and responses include vintage, providing behavioral context beyond annotations.

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

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

The description is front-loaded with the main purpose, includes examples and alternatives, and every sentence adds value without unnecessary fluff.

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

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

Given no output schema, the description adequately covers data source, time range, granularity, response contents, and alternative tool, making it fully complete for a simple count tool.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds context about response structure (fiscal year, vintage, shares) but does not significantly enhance parameter understanding beyond schema.

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

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

The description clearly states the tool counts vehicles registered in Texas with breakdowns by type and provides example questions. It distinguishes itself from the California breakdown tool mentioned in the description.

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

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

The description explicitly states the tool answers specific questions about Texas registrations and directs users to ca_dmv_vehicle_registrations for granular data, providing clear when-to-use and when-not-to-use guidance.

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

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

Discloses that the row is deactivated not deleted and historical events remain available via recent_alerts, adding context beyond the annotations (which only indicate non-destructive).

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, front-loaded with purpose, no unnecessary words.

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

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

Given the tool's simplicity (single required param, no output schema), the description fully explains behavior, ownership, and side effects.

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

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

Schema coverage is 100% with clear parameter description. The description adds no additional semantic meaning beyond what the schema provides.

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

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

The description uses specific verb 'Cancel' and resource 'subscription by id', clearly distinguishing from sibling tools like subscribe and list_subscriptions.

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

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

States ownership enforcement ('you can only cancel your own subscriptions'), providing clear usage context. Does not explicitly mention alternatives or when not to use, but the constraint 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 readOnly/openWorld/idempotent, but the description adds substantial behavioral context: the two distinct execution paths, the return verdicts with citations, and the critical nuance that 'could_not_verify' means no check happened and carries a verification_error, distinguishing it from 'unsupported'. This goes beyond the annotations to explain error handling and caveats, 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 fairly long but information-dense, with clear structure: trigger phrases, usage rule, path breakdown, return value, and an IMPORTANT caller note. Every sentence contributes, though the opening examples could be trimmed without losing much. It earns a 4 for being organized and useful 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?

Without an output schema, the description fully specifies the return shape: verdicts, actual values, citation, and reasoning. It also covers both claim types, the tolerance override, and error semantics. For a tool with two parameters and complex routing, this description gives the agent everything needed to select and invoke correctly.

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

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

The input schema already fully describes both parameters (claim and tolerance_pct) with examples and constraints, so schema coverage is 100%. The description repeats the tolerance advice but does not add meaning beyond the schema; it mainly reinforces the schema's details. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with a specific verb ('verify', 'fact check') and resource ('authoritative sources'). It distinguishes from sibling tools by explicitly scoping to factual claim checking and even mentions it replaces sequential pipeline calls.

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

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

It states explicitly: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates between two paths (SEC EDGAR for company-financial claims vs grounded pipeline for all others), giving clear when-to-use context. Additionally, it advises on interpreting 'could_not_verify' versus 'unsupported', which guides callers on when to rely on the result.

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