Leadconnector

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

Annotations indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context: the default free model, the need for an API key for Anthropic, cost implications, and a summary of the return structure (score, confidence, signals, raw_response). No contradiction with annotations.

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

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

The description is four sentences, front-loaded with the core purpose, and every sentence adds value. No redundancy or unnecessary details.

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

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

Despite no output schema, the description summarizes the return structure per model and combined view. For a tool with 4 parameters and optional configurations, the description is fully adequate.

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

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

Schema coverage is 100%, but the description goes beyond: it gives examples for 'entity', explains default and options for 'models', describes the key format and pass-through for '_apiKey', and clarifies disambiguation for 'context'. This is highly informative.

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: to probe LLMs for knowledge about an entity and score visibility from 0-100. It uses specific verbs ('probe', 'score') and distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on per-model scoring.

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

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

The description provides concrete use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains the default model and BYO key option. However, it does not explicitly mention when to avoid using this tool or differentiate from very similar siblings like 'scan_competitor_ai_presence'.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral detail: it routes to one of 5,743 tools, fills arguments automatically, returns structured answers with stable citation URIs, and is a single call with no multi-step research loop. It also notes cost/risk differences for alternatives ('deep_research costs more', 'ask_pipeworx_beta more experimental'). 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 long but front-loaded with the most important directive ('PREFER OVER WEB SEARCH') and then organizes supporting details: domain list, routing behavior, trigger phrases, examples, and alternative tool guidance. Each sentence contributes functional value. Slightly more verbose than strictly necessary, particularly the parenthetical notes, but every part aids tool selection and invocation.

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

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

Given the tool's role as a router across thousands of sources, the description is thoroughly complete. It tells the agent what the tool does, what input to supply, what the output will contain (structured answer with stable citation URIs), when to prefer it, and exactly when to choose each named sibling. There is no output schema, so the description's statement of return format is essential and 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%, so the parameter semantics baseline is 3. The description goes slightly beyond the schema by providing a rich set of example questions and explaining that the parameter is a natural-language question ('even if web search could also answer it'), which clarifies what kind of input is appropriate. The schema already documents the aliases, so the description does not need to repeat that.

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

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

The description states a clear verb and resource: it routes a natural-language question to the right specialized tool and returns a structured answer with stable pipeworx:// citation URIs. It also explicitly differentiates itself from siblings by naming ask_pipeworx_grounded, ask_pipeworx_beta, and deep_research and describing how each is used. The scope ('SEC filings, FDA drug data, FRED/BLS economic statistics...') makes the purpose concrete and non-tautological.

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 direction: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', then lists the exact alternative tools with their selection conditions (ask_pipeworx_beta for iterative research, deep_research for multi-part questions, ask_pipeworx_grounded for a single grounded answer). It also provides query trigger phrases ('what is', 'look up', 'find', 'get the latest') and real examples, giving an agent unambiguous guidance on when to invoke this tool versus its siblings.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable state context: no candidate is currently active, it currently matches ask_pipeworx exactly, and it is a full working router with no fallback. This goes beyond the structured hints and gives the agent an accurate current-behavior picture.

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 beta relationship and includes useful state details, but it is slightly verbose with specifics like the retired date and 5,743-tool count. Each sentence does contribute to setting expectations, and there is no redundant restating of schema information.

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

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

For a simple one-required-parameter tool with strong annotations and no output schema, the description provides enough to invoke it correctly: purpose, relationship to ask_pipeworx, current routing state, and response-shape parity. It does not enumerate possible return contents, but no output schema exists and the reference to the sibling response shape covers the main need.

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

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

Schema coverage is 100%, with all six parameters documented as aliases for the question field, so the schema carries the full parameter-semantic burden. The description adds only that the tool uses the same arguments as ask_pipeworx, which is useful context but not detailed parameter semantics. A baseline 3 is appropriate given the high schema coverage.

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

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

The description opens by defining the tool as a beta version of ask_pipeworx with the same universal router, same 5,743 tools, same arguments, and same response shape, which clearly identifies what it does and how it differs from its stable sibling. The mention of candidate routing improvements and the experimental edge distinguishes it from ask_pipeworx without requiring schema inspection.

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

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

The description explicitly says to use it like ask_pipeworx when you want the newest routing, and notes that results are compared against the stable router. It names the primary comparison tool but does not discuss exclusions or when to prefer the other sibling ask_pipeworx_grounded, so it is clear but not fully exhaustive.

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

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

Beyond the readOnly, openWorld, idempotent, and non-destructive annotations, the description discloses the exact success return shape, refusal reasons, and the behavior of refusing rather than inventing answers. It also reveals the cost tradeoff of one extra LLM call, adding valuable context not present in annotations.

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

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

Every sentence earns its place: purpose, routing, output structure, refusal structure, usage guidance, and cost comparison. The description is dense but well-organized and front-loaded with the key differentiator.

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

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

With no output schema, the description fully covers the success and refusal payloads, evidence behavior, and practical usage tradeoffs. Combined with the rich annotations, an agent has everything needed to decide when to invoke this tool and what to expect.

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 every property already documented as an alias for 'question.' The tool description adds general context about routing and filling arguments, but offers no per-parameter details beyond what the schema already provides, 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 answer mode for high-stakes reads' with a specific behavior: it extracts answers using only tool result content. It also distinguishes itself from the sibling ask_pipeworx by emphasizing its grounded, evidence-backed nature.

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

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

The description explicitly states when to use this tool: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' It also names the alternative ask_pipeworx and advises preferring it for casual lookups due to the extra LLM call cost.

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, and non-destructive. The description adds significant detail: resolver contract, parent event extractor, news fields, safety mechanisms (low-confidence short-circuit, closed market handling), wide-spread market warnings, and resolution-rule risk. 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 thorough but lengthy, containing many details in dense paragraphs. It is front-loaded with essential info but could be more concise. Structure via section headers helps, but brevity is sacrificed for completeness.

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

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

Without an output schema, the description fully explains response shapes (market, analysis, evidence), resolver confidence, parent event extraction, news fallback mechanisms, and safety/edge cases. It covers what agents need to handle responses 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 all 3 parameters with descriptions (100% coverage). The description adds context (e.g., depth fan-out explanation, include_raw behavior), improving understanding beyond schema. However, the schema already provides the core meanings.

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: researching a Polymarket bet by pulling Pipeworx data. It specifies multiple input formats (slug, URL, question text) and targets specific use cases like 'should I bet on X'. It distinguishes from siblings by focusing on single-bet 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?

Explicitly states when to use the tool (e.g., 'should I bet on X', 'what does the data say'). Provides examples of fan-out per category, giving context but not explicit exclusion of alternatives. Sibling tools like polymarket_edges serve different purposes (edge tracking), so guidance is adequate.

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

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

Annotations indicate read-only and idempotent, and the description adds behavioral details: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), correct handling of off-calendar fiscal years, sorting by primary metric, and return of citation URIs. No contradictions.

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

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

The description is well-structured with usage patterns first, then entity-type specifics. While it is relatively long, every sentence adds useful information. A minor reduction could improve conciseness, but it remains clear and efficient.

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

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

Given the tool's complexity (two entity types, multiple data sources, no output schema), the description adequately covers what data is pulled and how results are sorted. It mentions 'paired data + citation URIs' but could be more explicit about the output structure. Overall, it provides sufficient context for correct usage.

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

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

Schema already covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying that values should be tickers/CIKs or drug names and reinforces the 2–5 range, but does not add substantial new semantics beyond the schema.

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

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

The description starts with specific usage patterns like 'Compare X and Y' and 'which is bigger,' then clearly states the tool performs side-by-side comparison of 2–5 companies or drugs. It differentiates from sibling tools by explicitly mentioning it replaces 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 instructs 'ALWAYS PREFER over sequential single-pack lookups' and states it replaces 8–15 sequential lookups, providing clear when-to-use guidance. Implicitly excludes single-entity queries, which are handled by sibling entity_profile.

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

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

Despite annotations already marking readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral context: account requirement, paid tier for depth:'thorough', latency expectations (15-60s, up to ~90s), the gap recovery mechanism, the contradictions[] field, hop field semantics, semantic excerpting behavior, and the guarantee that it 'never invented' data. One possible concern is that the description mentions 'decomposes your question' and 'routes to 5,743 tools' which sounds like stateful orchestration, but the annotations say readOnly and idempotent; the description explicitly describes a non-mutating research operation, so 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 information-rich but dense and monolithic. It front-loads the account requirement and alternative routing, which is good, but then packs depth mechanics, citation semantics, excerpting behavior, latency, and contradictions into a long multi-clause paragraph. Every sentence earns its place, but the overall structure is hard to parse quickly. A breakdown into a one-line summary plus shorter sections would improve scanability.

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

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

Given there is no output schema, the description thoroughly compensates by describing the return shape: findings packet, verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, gaps[], contradictions[], hop field, citation_uri. It covers latency, auth prerequisites, tier differences, and points to the alternative tool. For a complex tool with 2 params and no output schema, this is complete.

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

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

Schema coverage is 100%, so the schema already fully documents both parameters (question and depth). The description adds nuance to the depth parameter by explaining the hop mechanics and paid plan requirement, and gives a natural-language example for the question parameter. That is useful value, but because schema coverage is 100%, a baseline of 3 is appropriate; the extra behavioral color is a bonus, not a necessity.

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

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

The description clearly states what the tool does: it performs grounded multi-source research across 1,500 structured data sources, decomposes questions into facets, routes them across 5,743 tools, and returns a findings packet with evidence, confidence, source, and citations. It uses a specific verb ('research'), names the resource domain, and contrasts itself with 'open-web search' and 'ask_pipeworx.' However, it lacks a one-line crisp sibling-differentiating summary statement early on; the differentiation from ask_pipeworx is embedded in a longer paragraph.

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

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

The description gives explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data,' gives examples, and explicitly says for single lookups use ask_pipeworx instead. It also tells users without an account to use ask_pipeworx. This is exactly the kind of when/when-not/alternatives guidance that helps an agent select the right 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavior: returns schemas with curated examples, results ready to call directly, and covers a wide range of data sources. No contradictions with annotations. A 4 is appropriate as it provides useful 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 concise yet comprehensive: first sentence states purpose, second lists domains, third explains return value, fourth gives usage guideline. Every sentence adds value, and the most important info is front-loaded. 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 (meta-discovery across many domains), the description covers purpose, usage, return format, and domain scope. No output schema is needed because the description already explains the return. All relevant aspects are addressed for a discovery tool.

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

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

Schema coverage is 100%, and all parameters have descriptions. The description explains the query parameter as 'natural language description' and mentions acceptable aliases, which adds marginal value. The examples in the schema provide concrete usage. Baseline 3 raised to 4 due to the examples and alias clarification.

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.' It specifies many domains (SEC filings, FDA, etc.) and explains that it returns top-N relevant tools with full schemas. This distinctly differentiates it from sibling tools, which are domain-specific.

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

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

The description explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear context for when to use. However, it does not explicitly state when not to use or mention alternatives, though the sibling list implies this is the discovery entry point.

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

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

The description goes well beyond the readOnly/idempotent annotations by disclosing parallel fan-out, per-source fallbacks (GDELT→GNews), soft-fail behavior, and the meaning of 'sources_used'/'sources_failed' including that empty sections indicate real absence of data. It also explains private-company behavior with resolved:false and a notes line. These are genuinely useful behavioral details not visible from annotations alone.

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

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

The description is front-loaded with purpose and trigger phrases, but it quickly becomes a dense wall of text with multiple parenthetical lists and repeated input-shape details already present in the schema. It contains a lot of valuable detail, but it would benefit from bullet points or clearer segmentation, and some example phrases are redundant.

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

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

With no output schema, the description carries the burden of explaining return semantics, and it does so thoroughly: CIK/company name, resolved_from/resolved_to, recent_filings URIs, fundamentals, patents, federal contracts, FDA biologics, H-1B data, news fallback, LEI, and source success/failure reporting. It also covers input edge cases, private companies, and soft-fail behavior, making it effectively complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter nuance: examples of ticker, zero-padded CIK, and company name, plus the note that 'type' accepts 'company' or 'ticker' interchangeably and that names resolve via SEC EDGAR. It also clarifies the private-company outcome, which is not in the schema. This is a clear value-add beyond the schema.

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

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

The description clearly states the tool's function: 'full cross-source profile of a US public company in ONE parallel call.' It names the resource (a US public company), the verb (profile/brief/research), and the cross-source fan-out behavior. It also distinguishes itself from chained single-pack SEC/XBRL/news lookups by saying 'ALWAYS PREFER' this tool for a holistic view.

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

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

The description gives explicit when-to-use guidance with trigger examples and says to prefer this over chaining single-pack lookups for a holistic view. It also clarifies scope ('US public company') and edge cases like private companies and name resolution. However, it does not explicitly contrast with sibling tools such as compare_entities or resolve_entity, so the routing guidance is strong but not exhaustive.

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, which the description aligns with by stating it deletes a memory. However, the description does not add new behavioral details beyond what the annotations provide.

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

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

The description is two sentences, front-loading the action and following with usage guidance. No unnecessary words or repetitions.

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

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

The description covers purpose, usage, and parameter context. Given the simplicity (one required param, no output schema), it is sufficiently complete. It does not explain what happens if the key is missing, but idempotentHint suggests it's safe.

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 parameter 'key' described as 'Memory key to delete.' The tool description adds only 'by key,' which does not enhance meaning beyond the schema. 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 'Delete a previously stored memory by key,' which is a specific verb+resource combination. It also distinguishes the tool from siblings by referencing 'remember' and 'recall' as paired operations.

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

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

Explicit usage guidance is provided: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' This gives clear criteria for when to invoke the tool.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail: fetches page, extracts title/description/key links, emits standard markdown format. No contradictions.

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

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

The description is front-loaded with purpose and well-structured, but slightly longer than necessary. Every sentence adds value, so minor deduction for 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 the simple tool (2 params, no output schema), the description covers input, output format, and use cases. It doesn't mention error handling or rate limits, but annotations handle safety. Adequate for its complexity.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description only repeats 'for any URL' and does not add new semantics beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the verb ('Generate') and resource ('llms.txt file for any URL'), and distinguishes itself by listing specific use cases. No sibling tool has a similar purpose, so differentiation is not needed.

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

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

The description provides explicit context ('so AI crawlers can index the site cleanly') and lists three concrete use cases. It lacks explicit when-not-to-use or alternatives, but the unique function makes this less critical.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value beyond those by specifying the returned fields (name, email, phone, tags, source, custom fields, timestamps) and explaining the BYO-token requirement and v1/v2 authentication nuance. No contradiction with annotations.

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

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

Three sentences, each earning its place: the core action, the return payload, and the auth prerequisite. The most important scoping phrase ('single CRM contact by its contact ID') 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 read-only single-resource fetch with fully documented parameters and safety annotations, the description covers the action, return content, and auth requirements. No pagination or output schema is needed here, and no critical invocation detail is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description summarizes the token and locationId relationship but does not materially add meaning beyond the already-detailed parameter descriptions in the schema.

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

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

The description uses a specific verb ('Fetch') and resource ('single CRM contact by its contact ID'), and explicitly contrasts with list-style siblings by emphasizing 'single' and 'full detail.' An agent can distinguish this from leadconnector_list_contacts before inspecting parameters.

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 clearly states the prerequisite of a BYO GoHighLevel token and the conditional locationId requirement for v2 pit- tokens, which is critical operational guidance. It doesn't explicitly name alternatives for when to use list_contacts instead, but the 'by its contact ID' scoping makes the intended usage 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?

Adds context beyond the readOnly/idempotent annotations: the returned envelope shape, the BYO-token requirement, and the v2 token needing locationId. No contradiction with annotations, and the auth behavior is useful for correct invocation.

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

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

Three sentences with no filler: purpose, return shape, use case, and auth requirement are all covered. The most decision-relevant 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 two-parameter read-only list tool, the description is complete: it explains the return envelope, the reason to use it, and the authentication nuances. The absence of an output schema is compensated by the explicit return description.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's token/locationId mention mostly repeats the schema, adding no meaningful parameter semantics beyond what is already documented.

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

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

States a specific verb and resource: 'List marketing/automation campaigns in the account.' It also clarifies the return shape (envelope with IDs, names, status), which clearly distinguishes it from sibling tools like leadconnector_list_contacts, leadconnector_list_opportunities, and leadconnector_list_pipelines.

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 clear use case: 'Useful for finding a campaign to attribute or enroll contacts.' It does not explicitly name alternatives or exclusion conditions, but the campaign-specific purpose is enough to guide selection among the sibling list tools.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds valuable context beyond those annotations: the BYO token requirement, the v2 `pit-` token plus locationId distinction, and the concrete return envelope with contact fields. It does not mention rate limits or pagination details, but those are partially covered by the limit parameter.

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 tight sentences with no filler: purpose first, then query behavior and return format, then auth requirements. Every sentence earns its place, and the most important scoping 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?

There is no output schema, but the description compensates by naming the return envelope and its key fields. Combined with the rich parameter schema and annotations, the agent has enough to call the tool correctly. A minor gap is that the `meta` object's contents are not described, but that is not critical for invocation.

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

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

Schema description coverage is 100%, and the schema already documents query, limit, _apiKey, and locationId in detail. The description only reinforces the locationId requirement for v2 tokens, adding little meaning beyond the schema. A 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 verb and resource: 'Search or list CRM contacts in a GoHighLevel/LeadConnector account.' It also explains the free-text query scope across name, email, or phone. It does not explicitly distinguish itself from the sibling leadconnector_get_contact, so it stops short of a 5.

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

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

There is no guidance about when to choose this tool over alternatives such as leadconnector_get_contact or other leadconnector list tools. The auth prerequisite and locationId note are useful, but they are invocation requirements, not usage-selection guidance. No exclusions or 'use this when...' framing is present.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful behavioral context beyond the annotations: it requires the user's own GoHighLevel token via _apiKey and notes the locationId requirement for v2 `pit-` tokens. It also states what the response contains (monetary value, stage, status, associated contact), which is valuable given no output schema.

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 carry the full purpose, prerequisite, return fields, and auth requirement without redundancy. The main action is front-loaded, and every clause 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?

For a list tool with 4 well-documented params and strong annotations, the description is complete enough: it names the prerequisite, the auth model, and the key return fields. Since there is no output schema, the explicit statement of returned deal attributes helps. It could mention pagination/limit behavior, but the schema already documents limit, so the gap is minor.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already provides (pipelineId from leadconnector_list_pipelines, _apiKey auth, locationId for v2 tokens) rather than adding new parameter-level meaning. It is consistent and sufficient, but does not go beyond the schema.

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

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

The description opens with a specific verb and resource: 'List opportunities (pipeline deals) for a given pipeline.' It distinguishes this from sibling list tools by scoping to pipeline deals and requiring a pipelineId, while also pointing to leadconnector_list_pipelines as the source for that ID.

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

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

The description gives clear context: this tool lists deals for a specific pipeline and requires a pipelineId, explicitly directing users to leadconnector_list_pipelines to obtain one. It does not spell out when-not-to-use scenarios or compare with list_contacts/list_campaigns, but the resource scoping and prerequisite are enough to route selection.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond the annotations by specifying the response envelope and, importantly, the authentication prerequisite: users must bring their own GoHighLevel token via _apiKey, and locationId is required for v2 pit- tokens. No contradiction with annotations.

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

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

Three sentences, each earning its place: what the tool lists, what it returns, and how to chain/authenticate. The most important details are front-loaded, and there is no filler or repetition beyond a necessary auth reminder.

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

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

The description is complete for a simple read-only list tool. It names the output envelope and fields, explains how to use the result downstream, and covers the token/locationId requirements. With no output schema present, it supplies the essential return-value information inline.

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

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

Schema description coverage is 100%, so the schema fully documents _apiKey and locationId, including the v1/v2 distinction. The description only restates the auth requirement rather than adding new parameter semantics, which is acceptable at the baseline given the high schema coverage.

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

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

The description opens with a precise verb and resource: 'List all sales pipelines and their stages in the account.' It also clarifies the output envelope (pipelines with IDs, names, ordered stages) and explicitly connects it to leadconnector_list_opportunities, making it easy to distinguish from sibling listing 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 clear context for when this tool is useful: when the agent needs pipeline IDs and stage structure, and it explicitly instructs to pass the returned pipeline ID into leadconnector_list_opportunities. It does not explicitly enumerate alternatives or when-not-to-use conditions, but the usage context is clear and actionable.

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

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

Annotations already declare the tool safe (read-only, idempotent, non-destructive). Description adds value by detailing return fields and scoping to caller's subscriptions, but lacks mention of potential pagination or rate limits, which are absent due to simplicity.

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-load purpose and return info, then usage guidance. No superfluous content.

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

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

For a simple list tool with one optional parameter and no output schema, the description fully covers purpose, return shape, and usage context. 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?

The single parameter include_inactive is fully documented in the schema. The description adds no additional meaning beyond what the schema provides, meeting but not exceeding expectations with 100% coverage.

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

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

The description clearly states the tool lists the caller's active subscriptions and specifies returned fields. However, it does not explicitly differentiate from sibling tools like subscribe or unsubscribe, though the purpose is distinct.

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 advises when to use the tool: to review monitored items before adding more or to find an ID to cancel. This is clear and actionable.

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

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

While annotations only set hints to false, the description discloses important behavioral details: filing without an account returns a claim_token, the token can be used later to read resolution status, rate-limiting to 5 per identifier per day, free usage, and that feedback directly affects roadmap. 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?

Although the description is relatively long, every sentence earns its place: it covers purpose, scope, exclusions, claim_token usage, rate limits, and roadmap impact. The content is dense and well-structured, with 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?

Given the tool's complexity (4 parameters, nested context object, no output schema), the description fully covers all necessary aspects: what to report, how to report, what happens with/without an account, rate limits, and how to check resolution. It is complete for the agent to use effectively.

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

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

The schema already provides 100% parameter descriptions, so the baseline is 3. The description adds extra value by explaining the claim_token workflow ("pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})") and instructing users to describe issues in terms of Pipeworx tools/packs rather than pasting prompts. This goes beyond the schema.

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

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

The description clearly states the tool's purpose: "Tell the Pipeworx team something is broken, missing, or needs to exist." It specifies the verb (tell/feedback), the resource (Pipeworx team), and distinguishes from sibling tools by focusing exclusively on feedback about Pipeworx tools, not general questions or research.

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

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

The description gives explicit when-to-use scenarios (bug, feature/data_gap, praise) and a clear when-not-to-use: "ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead." This is model guidance with exclusions and alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: data source (CF analytics-engine), no PII, cached 5min-1h, and self-aggregating signal. No contradictions.

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

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

Two concise sentences plus a bullet list of use cases. Front-loaded with the core function, no wasted words. Every sentence adds value.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description fully covers purpose, parameters, use cases, caching, and data provenance. No gaps.

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

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

Schema coverage is 100% with enum descriptions. The description adds contextual guidance on window choice (short vs long windows surface different trends), which adds meaning beyond the enum 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 explicitly states the tool returns top tools, top packs, and total call volume over a specified window, with specific use cases. It clearly distinguishes from sibling tools like discover_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?

Three explicit use cases are provided, and the parameter description gives guidance on window choice. However, it does not explicitly state when not to use this tool 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 indicate safe/read-only. Description adds extensive behavioral details: no-arg trending scan, event/topic behavior, semantic anchor similarity, partition placeholder filtering, fill check against live depth, and response structure. 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?

Long but well-structured with clear sections. Each sentence adds value given tool complexity. Could be slightly shorter but justified by depth of information.

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

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

Despite no output schema, description fully explains response structure including arrays and objects. Covers error conditions (low similarity, placeholder filtering) and trade decisions. References sibling tool for custom sizing. Complete for an agent to use.

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

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

Schema coverage is 100%, but description adds significant meaning: explains event parameter expects slug or URL for single-event mode, topic expects seed question for cross-event mode, and provides examples. Also explains how each parameter changes tool behavior.

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

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

Clearly states it finds arbitrage opportunities via monotonicity violations and partition-sum checks. Distinguishes two modes (event/topic) and explains each, differentiating from siblings like polymarket_edges.

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

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

Explicitly says when to use no args (trending scan), event (specific market), or topic (cross-event). Recommends event for specific markets, warns about cross-event catching single-event misses. Provides conditions for trade signals and references polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, conveying safe, read-only, and non-destructive behavior. The description adds useful context: caching (1h at KV level), diagnostic info (_diagnostics), edge calculations net of slippage, Kelly cap at 0.25, and a 24h-move warning. No contradictions with annotations.

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

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

The description is highly informative but very dense and lacks clear structure (e.g., bullet points or sections). It front-loads the purpose, but the technical details on model families and diagnostics make it lengthy. Could be more scannable for an AI agent.

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

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

Given 9 parameters, no output schema, and complexity, the description is complete. It explains the output structure (by_segment with segments, fed_candidates, _diagnostics), what fields each opportunity carries (edge_pp_net, kelly_fraction, market info, 24h-move warning), and the tradeable-edge knobs. Caching is noted. This provides sufficient context for an agent to understand and use the tool.

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

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

Input schema covers all 9 parameters with descriptions (100% coverage), so baseline is 3. The description adds significant value by explaining how parameters like min_kelly, min_partition_leg_kelly, and slppage_pp work in context (e.g., 'skips opportunities that are too small to bet sensibly', 'tradeable-edge filter'). This goes beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It uses specific verbs ('scan', 'return') and identifies the resource (Polymarket markets). The detail on three model families (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) distinguishes it from sibling tools like polymarket_arbitrage and polymarket_edge_tracker.

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 use case: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It provides context for when to use (daily discovery) and describes knobs for filtering (min_liquidity, max_spray_pp). However, it lacks explicit 'when not to use' or direct comparisons to alternative tools among siblings.

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

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

Annotations already declare idempotent and read-only behavior. The description adds rich behavioral detail: response structure (tracked, expired, snapshot_dates), meaning of fields (trend categories, decay computation), and edge cases (negative values for SELL YES, gaps in snapshots, limits on history depth). This goes well beyond the annotations.

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

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

The description is front-loaded with the core purpose and uses clear sections (Args, RESPONSE, LIMITS). It is efficient but slightly verbose in the RESPONSE section, where it lists fields in a paragraph instead of a more structured format. Still, nearly every sentence adds value.

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

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

Given no output schema, the description thoroughly explains the return structure and edge cases. It covers data sources, decay computation, and limitations. Could be enhanced with a concrete example or more direct guidance on interpreting results, but overall it is quite complete for a specialized telemetry 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 detailed descriptions for both parameters. The tool description essentially repeats this information (days, window, defaults, constraints) without adding new meaning. Per guidelines, baseline is 3 when schema coverage is high.

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 from daily snapshots. It explicitly answers the question it addresses and distinguishes itself from the sibling tool `polymarket_edges` by focusing on time-series analysis rather than a current snapshot.

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

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

The description implies when to use this tool (to differentiate new vs. old edges) and provides context on limits (60-day TTL, snapshot gaps). It does not explicitly mention alternatives, but the sibling list is available and the description's framing makes its unique value 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, and destructiveHint=false, so the description's primary job is to add behavioral context beyond these. It does so by detailing the check process (walks the ladder, returns metrics like top_of_book, vwap_fill_price, slippage_pp, verdicts) and explicitly warns about thin books and directional risk. This adds significant value beyond the safety profile provided by annotations.

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

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

The description is a single paragraph with clear section breaks (e.g., 'SINGLE-MARKET:', 'BASKET:') and uses bold for emphasis. It covers all necessary details without redundancy, though it is somewhat lengthy due to the tool's complexity. Every sentence adds value, and the structure is logical.

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

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

Without an output schema, the description fully explains the return values for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp for single-market; theoretical_sum, realizable_sum, capture_ratio, thin_legs for basket). It also addresses edge cases like forced_directional_risk, making the tool highly understandable for correct agent invocation.

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

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

Schema description coverage is 100%, but the description adds meaning beyond the schema: it clarifies the dual mode (single-market vs basket), explains default side selection for basket, and elaborates on the interpretation of size_usd for both modes (spend vs target proceeds vs settlement notional) and the clamp range. This enriches parameter understanding.

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

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

The description specifies the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes, and explicitly contrasts with sibling tools like polymarket_arbitrage and polymarket_edges by advising use before acting on their signals or trades above ~$500.

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

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

Provides explicit when-to-use guidance: before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500. Warns about the risks of partial basket fills converting arb into unhedged directional positions, which clearly indicates when not to use or to proceed with caution.

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

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

The description goes well beyond the readOnly/idempotent annotations by explaining non-obvious behaviors: pairing_unverified is set whenever pairs are returned, unclassified legs are never paired, temporal_alignment null means unknown rather than aligned, and all spreads are gross because Kalshi fees are not modeled. No contradiction with the annotations exists.

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

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

The description is front-loaded with the core purpose and uses clear labels (TWO MODES, RESPONSE, SAFETY FIELDS) to organize a large amount of operational detail. It is verbose and repeats some temporal-alignment concepts, but nearly every sentence carries useful information for correct tool use.

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

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

There is no output schema, so the description compensates fully by covering the response shape, compatibility codes, per-entry flags, unclassified/skipped data, temporal alignment semantics, fee disclosure, and the caveat that pre-mapped shortcuts are not automatically tradeable. An agent has enough to invoke the tool and interpret results correctly.

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

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

Schema description coverage is 100%, so the schema already documents the parameters, their types, and their override semantics. The description adds context about both modes running the identical matcher and topic auto-fetching matching events, but this is supplementary rather than essential parameter meaning.

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

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

The description states a specific operation: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question, and immediately scopes it with two modes (topic shortcuts vs explicit ticker/slug). This clearly distinguishes it from the Polymarket-only siblings by emphasizing 'cross-venue' and 'two venues' throughout.

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

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

It gives clear context for when to use each mode: topic shortcuts for pre-mapped events and explicit ticker/slug for custom pairings, and explicitly warns that most pre-mapped topics currently return compatibility warnings and are not tradeable. It does not name specific sibling alternatives or formulate hard exclusion rules, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds scoping details (identifier-based) and explains the listing behavior when key is omitted, providing beyond-annotation context.

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

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

The description is three sentences, front-loaded with the main function. Every sentence adds value without redundancy. It is concise and well-structured.

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

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

Given no output schema, the description covers retrieval and listing behavior but does not explicitly mention the return format (e.g., value or list of keys). It is nearly complete but could be slightly more explicit.

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 a parameter description. The description adds significant meaning by clarifying the dual functionality (retrieve vs. list) and scoping, which is not in the schema itself.

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

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

The description clearly states the tool retrieves values saved via remember or lists all keys when omitted. It specifies the verb (Retrieve/list) and resource (saved values), differentiating it from siblings like remember and forget.

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

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

The description explains when to use: to look up previously stored context without re-deriving. It mentions pairing with remember/forget but doesn't explicitly state when not to use. The context is clear enough for correct selection.

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

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

Beyond annotations, it describes the return shape (source, citation_uri, raw payload) and the mark_read behavior, adding significant context for the 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?

Four sentences, front-loaded with purpose, each sentence adds value without redundancy. Well-structured for quick parsing.

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

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

The description covers all parameters, explains the return shape, and gives usage context. Without an output schema, it could be more explicit about all possible fields, but it is sufficient.

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

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

Schema coverage is 100%, and the description adds examples (e.g., 'sec_8k' for type) and clarifies mark_read semantics, providing extra value beyond the schema.

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

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

The description uses a specific verb ('pull') and resource ('fired events from your subscription feed'), clearly distinguishing it from sibling tools like subscribe or 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?

It explicitly mentions filtering by type and since, the mark_read effect, and gives polling advice with an alternative REST endpoint, telling the agent when and how to use the tool.

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

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

Beyond annotations (readOnly, idempotent), description reveals parallel execution, fallback logic (GDELT preferred, GNews on rate limits/5xx), PatentsView soft-fail post-May 2025, and output structure. No contradiction with annotations.

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

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

Description is roughly 5 sentences, front-loaded with examples, and every sentence serves a purpose (behavior, parameters, sibling reference). 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?

Despite no output schema, description adequately explains returns (structured changes[], total_changes, citation URIs). For a multi-source tool with fallback, this provides sufficient guidance for an agent.

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

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

Schema already covers parameters with descriptions (100% coverage). Description adds value by giving concrete examples for since, value (ticker/CIK), and suggesting typical monitoring windows. It does not rely on 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 it provides a change feed for a company over a time window, listing specific sources (SEC, GDELT/GNews, USPTO). It contrasts with sibling entity_profile (static profile vs. dynamic changes), making its purpose distinct.

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 includes example queries and suggests typical since values ("30d" or "1m"). It also directs users to entity_profile for static profiles. Although it doesn't exhaustively list when not to use, the sibling distinction 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 show idempotentHint=true, but no other hints. Description adds critical behavioral details: memory is key-value scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous sessions. No contradiction with annotations.

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

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

Three sentences, front-loaded with main purpose. Efficient but includes some redundancy (e.g., 'so you don't have to look it up again' slightly wordy). Overall well-structured.

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

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

For a simple write tool with no output schema, the description sufficiently covers usage context, storage behavior, and tool linkages. Complete enough for effective use.

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

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

Schema description coverage is 100% and both parameters are well-described in the schema. The description adds minimal extra value beyond schema (e.g., naming examples) but is not needed for understanding.

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

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

The description clearly states 'Save data the agent will need to reuse later' with specific verb (save) and resource (data stored as key-value pairs). It distinguishes from siblings 'recall' and 'forget' by focusing on the writing 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 describes when to use: 'when you discover something worth carrying forward' and mentions complementary tools 'recall' and 'forget'. However, does not explicitly state when not to use or contrast with other storage mechanisms.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes far beyond these by disclosing internal cascading lookups, graceful degradation when GLEIF/OpenFIGI unavailable, explicit handling of unresolved identifiers, and returning figi_candidates for ambiguous matches. This enriches the behavioral model substantially without contradicting the annotations.

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

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

The description is long but densely informative, front-loading the core purpose and examples. It is organized into clear sections (supported types, input instructions, degradation policies). While a bit verbose, every sentence contributes functional guidance, so the length is justified rather than wasteful.

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

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

The description is comprehensive for a tool with no output schema. It covers input specifics, output characteristics (labeled sources, unresolved list), edge cases (ambiguous matches), failure modes (degradation), and performance expectations (replaces multiple lookups). Given the tool's complexity, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. However, the description adds substantial meaning: for 'type' it explains what each enum value resolves and the data sources; for 'value' it gives precise examples, warns against full noun phrases, and clarifies that for bonds it expects the issuer name. This is material guidance beyond the schema's bare property definitions.

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

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

The description clearly states the tool resolves a user-spoken name to canonical identifiers, enumerates supported types (company, drug) and specific identifiers (CIK, ticker, LEI, FIGI, RxCUI). It gives concrete query examples ("What's the ticker for…") that anchor the purpose. It distinguishes itself as the go-to for name-to-ID mapping, which separates it from sibling tools like entity_profile or compare_entities.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID,' establishing a clear trigger condition. It provides detailed input formatting rules (e.g., pass issuer exactly as printed, avoid trailing security-class words) and explains that it replaces 2-3 manual lookups. However, it does not mention alternative tools or when not to use it, so it stops short of full exclusivity 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?

Adds significant behavioral context beyond annotations: probes each entity with ai_visibility_check, ranks results, returns score/confidence/signal density. Mentions API key requirement for Anthropic model. No contradictions with annotations.

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

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

Four sentences, efficient and well-structured. Front-loaded with main action, then details. No filler.

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

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

Given no output schema, description adequately explains return format. Covers probing mechanism, ranking, and API key usage. Sufficient for agent to understand tool's capabilities and outputs.

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

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

Schema coverage is 100%, but description adds meaning: explains 'entities' first entry treated as subject, 'context' is shared across probes, and 'models' default behavior. Enriches 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 it compares AI visibility across multiple entities, ranks them by score, and surfaces most/least recognized. It distinguishes from sibling 'ai_visibility_check' by being a side-by-side comparison 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 it's useful for competitive AI-marketing audits and gives an example question. Lacks explicit when-not-to-use or alternative tools, but context is clear.

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

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

Beyond the annotations (readOnlyHint, etc.), the description adds critical behavioral details: composite call fan-out, partial failure handling, bundlephobia timeout (5-30s), and return structure, all without contradicting annotations.

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

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

The description is front-loaded with purpose and usage, then progressively detailed with technical notes. It is slightly verbose but each sentence adds value, earning a high but not perfect score.

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

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

Despite lacking an output schema, the description enumerates all return fields, explains partial failure, and sets expectations for timing and ecosystem scope, making it fully actionable for the agent.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description does not add significant new meaning beyond confirming scoped package acceptance, which is already in the schema.

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

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

The description uses a specific verb ('check') and resource ('npm package') and clearly states the composite nature, distinguishing it from sibling tools by noting that other ecosystems fall under direct deps.dev 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?

The description explicitly provides when-to-use examples ('is X safe / popular / small') and when-not-to-use (non-NPM ecosystems should use deps.dev:version directly), offering clear guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description discloses technical behavior: uses BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation and flagging, and returns character offsets. 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?

Concise at about 6 sentences, front-loaded with the main action. Each sentence adds distinct value: defines tool, use case, sibling pairing, technical details. No fluff 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?

For a tool with 3 params, no output schema, but with annotations covering safety, the description fully explains: what you get (top-N passages with offsets and scores), how it works (embeddings, windows), and limitations (200K char cap). It is complete for an agent to understand invocation and expected outcome.

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 detailed descriptions (e.g., text max chars, query examples, limit range and default). The description adds context that text comes from a fetched record and that output includes offsets and scores, but this is marginal additional value beyond the schema. Baseline 3 plus extra context warrants a 4.

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

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

The description clearly states the tool performs semantic search inside a fetched record, returning passages with offsets and scores. It uses specific verbs ('search inside', 'pass the text', 'get back') and distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly states when to use: 'when the record is too big to cram into the prompt'. Provides a clear alternative workflow: 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document.' This gives both usage context and alternative.

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

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

Annotations indicate idempotentHint=true and readOnlyHint=false. The description adds that it returns a new subscription ID, explains delivery channel limits (10/day SMS cap, webhook auto-disable), and mentions feed persistence. No contradictions with annotations.

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

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

The description is a single paragraph but well-organized with logical flow. It is information-dense yet readable. Minor improvement could be using bullet lists for the three delivery channels, but it remains concise and front-loaded.

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

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

Given the tool's complexity (5 subscription types, required params, optional nested delivery object), the description covers authentication, type-specific filters, delivery options with limitations, and the return value ('Returns the new subscription id'). No output schema exists, so description handles it fully.

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

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

Schema coverage is 100% but the description enriches every parameter with concrete examples and constraints (e.g., 'sec_8k: items:["5.02"] = officer change'). It clarifies the type-specific params and delivery subfields beyond the schema definitions.

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

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

The description uses specific verbs ('Create a proactive monitoring subscription') and clearly identifies the resource ('live-data event stream'). It distinguishes from siblings like list_subscriptions and unsubscribe by focusing on creation of subscriptions.

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

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

The description states the requirement for a Pipeworx OAuth account and gives detailed examples per subscription type. It lacks explicit when-to-use vs alternatives but the context makes it clear this is for setting up monitoring, not for retrieving existing alerts.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing that the tool returns example questions from a live catalog, with category bucketing and tool+argument shapes, and explains behavior with/without topic argument. 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 dense but well-structured, front-loading purpose and usage indications. Every clause contributes value, though it is longer than minimal. Could be slightly more concise without losing information.

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

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

Given the tool's role as an onboarding entry point with no output schema, the description is remarkably complete. It covers when to use, what it returns (category-bucketed questions with tool+argument shapes), parameter options, and relationship to sibling tools. 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?

Input schema has 100% coverage with a single optional string parameter 'topic' and its description. The description adds meaning by saying omitting topic gives a cross-category spread and listing example values, enhancing understanding beyond the schema.

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

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

The description clearly states the tool's purpose: it is the onboarding entry point that returns category-bucketed example questions with exact tool+argument shapes. It differentiates from siblings by positioning itself as a first-use tool and listing sibling meta-tools like ask_pipeworx and entity_profile.

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

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

Explicitly says to use this tool first when the agent does not know what Pipeworx can do or to learn how to call meta-tools. It also describes when to omit or include the topic parameter, providing clear context for 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?

Adds information beyond annotations: ownership enforcement, deactivation vs deletion, and relation to recent_alerts. Annotations already indicate idempotent and non-destructive, so description complements well.

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

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

Two sentences, front-loaded with purpose, 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?

Complete for a simple tool: explains behavior (deactivation), ownership, and connection to recent_alerts. No output schema needed as return value is implied.

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 the single parameter with description. The description does not add further detail about the parameter beyond what the schema provides, meeting baseline.

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

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

The description clearly states the verb 'Cancel' and the resource 'subscription by id', distinguishing it from siblings 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?

Explicitly mentions ownership enforcement and that the row is deactivated not deleted, providing context for when to use and what happens after. Lacks mention of alternatives but is clear enough.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, but the description adds crucial behavioral detail beyond this: the meaning of each verdict (especially could_not_verify vs. unsupported), the presence of verification_error{stage,detail} for failures, the routing logic, and the explicit warning that could_not_verify is not evidence for/against the claim. This is rich, non-contradictory context that greatly aids correct interpretation.

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

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

The description is dense but every sentence earns its place: usage triggers, routing behavior, return values, and critical error semantics are all covered. It is front-loaded with examples and immediately tells the agent when to use the tool. The structure flows logically from what it does, to how it works, to what it returns and what to be careful about.

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

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

For a tool with no output schema, the description comprehensively explains return values (verdict list, actual value with citation, reasoning, verification_error). It also covers the two execution paths, the distinction between could_not_verify and unsupported, and even mentions the efficiency benefit over sequential calls. Combined with full parameter schema coverage and supportive annotations, this is complete for safe and correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful guidance for tolerance_pct, explaining how it overrides the default implied by claim wording (capped at 5) and recommending 1–2 for hallucination detection. It also clarifies that 'claim' is a natural-language factual statement, reinforcing the schema's examples. This goes beyond a simple restatement of parameter names.

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 concrete query examples ('fact check', 'verify the claim that…'). It distinguishes itself from siblings by explaining the two routing paths (SEC EDGAR/XBRL for financial claims, grounded pipeline for everything else) and its role as a replacement for 4–6 sequential 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?

Provides explicit usage guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains when the financial fast path applies versus the general grounded pipeline. However, it does not explicitly name alternative tools or state when not to use it (e.g., when deep research is needed), leaving some ambiguity in tool selection.

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