Open Notify

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

Annotations already declare read-only, open-world, and idempotent behavior. The description adds key behavioral details: the tool makes external API calls (to Workers AI and optionally Anthropic), requires a BYO key for Anthropic, and returns per-model data. This aligns with and expands upon 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 extremely concise: three front-loaded sentences covering purpose, defaults, required key, and return format. Every sentence adds value without redundancy.

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

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

Despite no output schema, the description fully explains return values (per-model score, confidence, signals, raw_response + combined view). It accounts for all 4 parameters, 1 required, and optional fields. The tool operates as a stateless probe, so no further context is needed.

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 excellent descriptions, but the tool description adds extra meaning: the default model is Workers AI Llama-3.3-70b (free), models array can be omitted for just workers-ai, and _apiKey is only needed if 'anthropic' is in models. The context parameter's purpose (disambiguation) is also clarified, making all parameters well-understood.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100) per model. It specifies the default model and optional Anthropic probe, and distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on general visibility scoring across multiple models.

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

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

The description lists explicit use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to pass an API key. It could be more explicit about when not to use this tool compared to alternatives like 'scan_competitor_ai_presence', but the given guidance is sufficient.

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

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

The description adds context beyond the readOnlyHint annotation by explaining that the tool routes to many sources and returns structured answers with citation URIs. It does not contradict the annotation and discloses the tool's operation adequately.

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

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

The description is relatively concise given the complexity, with key instructions at the beginning. It could be slightly trimmed, but the examples and domain list are useful and justify the length.

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

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

Given the tool's complexity (routing to many sources), the description explains the purpose, usage, and output format adequately. It does not cover error handling or out-of-scope queries, but for a query router, this is acceptable.

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

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

The schema already describes the 'question' parameter fully, but the tool description adds significant value by specifying the types of questions and examples, helping the agent understand the expected input more concretely.

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 that the tool routes factual questions to a large set of tools across many domains, and it clearly distinguishes itself from sibling tools by focusing on querying structured data versus other operations like entity comparison or tool discovery.

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

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

The description provides explicit guidance on when to use the tool (for factual questions about specific domains) and gives examples. It also suggests preferring over web search, though it does not explicitly state when not to use it, such as for subjective or non-factual queries.

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

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

Annotations already declare readOnlyHint=true. The description adds return field details (name, craft) but lacks other behavioral traits like data freshness or source.

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?

One sentence with no waste. Front-loaded key info: what (people in space), fields (name + craft), and scope (ISS/Tiangong/etc.).

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 zero-parameter tool, the description is adequate. However, no output schema or example response is provided, leaving some ambiguity about the exact return format.

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

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

No parameters, schema coverage 100%. The description adds meaning by specifying the returned fields beyond what the empty schema provides.

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

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

The description clearly states the tool returns people currently in space with their name and craft. It distinguishes from sibling 'iss_now' by specifying all spacecraft (ISS, Tiangong, etc.).

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

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

The description implies when to use (to list all people in space) but does not explicitly exclude alternatives like 'iss_now' or provide context for choosing between them.

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

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

Annotations (readOnlyHint, openWorldHint) indicate safe, read-only operation. The description adds value by detailing the workflow: resolves market, classifies bet, fans out to packs, returns evidence and comparison. No contradictions.

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

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

The description is a single paragraph of 5 sentences, front-loaded with the main action. Each sentence earns its place, covering purpose, input, workflow, and use cases. Slightly less structured than ideal but concise.

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

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

Given the multi-step processing and no output schema, the description explains the return (evidence packet + comparison) and classification. It provides a solid high-level picture, but could detail the evidence packet structure.

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

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

Schema coverage is 100%, but the description adds useful context: explains market accepts slug, URL, or question text, and clarifies depth defaults to 'thorough' (not explicit in 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 researches Polymarket bets by pulling Pipeworx data, with specific verbs and resources. It distinguishes from siblings by positioning itself as the core demo product that improves conversion over discovering packs independently.

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

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

The description explicitly lists use cases ('should I bet on X?', 'what does the data say...', 'is there edge?'). It implies alternatives but does not explicitly state when not to use, though context is clear.

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

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

Annotations indicate readOnlyHint=true; description aligns and adds rich behavioral detail: data sources (SEC EDGAR/XBRL, FAERS), return format (paired data + citation URIs), and efficiency (replaces multiple calls).

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?

Six sentences of moderate length. Each sentence adds value, but could be slightly more concise without losing clarity.

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

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

Given the tool's complexity (two modes, multiple data sources), the description covers all essential aspects: how to invoke, what it returns, and efficiency benefits. No output schema, but return type is described.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds examples and context for each type but does not add semantic meaning beyond the schema.

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

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

Description uses specific verb 'compare' and clearly identifies the resource as companies or drugs. It distinguishes from sibling tools by stating it replaces 8–15 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?

Explicitly provides use cases like 'compare X and Y', 'X vs Y', etc. Explains what each type returns. Lacks explicit exclusion scenarios but context is clear.

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

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

Annotations already mark readOnlyHint=true, so the description adds context: it returns 'top-N most relevant tools with names + descriptions,' which is not in the schema. This goes beyond the bare annotation, though it doesn't detail ranking logic or limits beyond schema default. 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 a single paragraph, front-loaded with purpose and usage. It lists many domains, which adds length but is informative. It is efficient for the information conveyed, though slightly verbose. No wasted sentences.

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

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

For a discovery tool with no output schema, the description adequately specifies what is returned ('top-N most relevant tools with names + descriptions'). It also tells the agent to use this first, providing full context for usage. Given the tool's simplicity and read-only annotation, 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 baseline is 3. The description adds example inputs for the query parameter ('analyze housing market trends', etc.) but does not provide additional semantics beyond what the schema already defines. The limit parameter is fully covered by 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: 'Find tools by describing the data or task.' It lists many domains (SEC filings, financials, etc.) and distinguishes itself from sibling tools like 'ask_pipeworx' or 'entity_profile' by being a meta-tool for discovering other tools. It returns 'top-N most relevant tools with names + descriptions,' which is specific and actionable.

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 when you need to browse, search, look up, or discover what tools exist for' and gives concrete examples. It also instructs 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use and implicitly when-not-to (if you already know 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 declare readOnlyHint=true, and description confirms it only returns data. No contradiction. Describes what data is returned and mentions citation URIs, adding transparency beyond annotations.

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

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

Description is a coherent paragraph, front-loaded with primary purpose. Could be slightly more structured (e.g., bulleted outputs) but is efficient and clear. No wasted sentences.

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

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

No output schema exists, but the description comprehensively lists what the tool returns (SEC filings, revenue/net income, patents, news, LEI) and mentions citation URIs. Fully compensates for lack of output schema.

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

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

Schema has 100% coverage with clear descriptions for both parameters. Description adds extra context (e.g., 'zero-padded CIK like 0000320193') and explicitly notes that names are not supported, adding 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?

Describes the tool as 'Get everything about a company in one call' and lists specific outputs (SEC filings, fundamentals, patents, news, LEI). Clearly distinguishes from siblings like 'resolve_entity' (which resolves names) and '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?

Provides explicit use cases ('tell me about X', 'give me a profile') and states when not to use ('Names not supported — use resolve_entity first'). Offers clear alternatives and context.

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

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

Description aligns with annotations (readOnlyHint: false) and adds context about deleting stored memories. No contradictions.

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

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

Two sentences, front-loaded with purpose, minimal waste.

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

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

Simple tool with one parameter; description covers purpose, usage, and values complete for the tool's complexity.

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

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

Schema coverage is 100% and description does not add additional parameter detail beyond 'key'.

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 explicit verb 'Delete' and resource 'previously stored memory by key'. Distinguishes from siblings like 'remember' and 'recall'.

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

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

Provides clear when-to-use scenarios: 'stale context, task done, clear sensitive data'. Suggests pairing with 'remember and recall'.

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, establishing a safe, read-only, and idempotent behavior. The description complements this by detailing the process (fetches page, extracts title/description/key links, emits markdown), aligning perfectly with annotations and adding no contradictions.

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

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

The description is three sentences long, each serving a distinct purpose: purpose/audience, process, and use cases. It is front-loaded with the essential verb and resource, contains no redundant information, and is efficiently structured for quick comprehension.

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 low complexity (2 params, no output schema, rich annotations), the description covers all necessary aspects: what it does, how it works, the output format, and concrete use cases. No gaps are present for an agent to understand when and how to invoke the tool.

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

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

Schema coverage is 100% with both parameters (url and max_links) already well-described in the input schema, including defaults and constraints. The description does not add new semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states it generates a production-ready llms.txt file for a given URL, specifying the verb 'generate', the resource 'llms.txt file', and the target audience (AI crawlers). It distinguishes from sibling tools by focusing on a specific output format and use case, with no directly overlapping siblings listed.

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 contexts for use: getting a client's site indexed, drafting for a personal project, or auditing competitor visibility. It does not include when-not-to-use or alternative tools, but the given scenarios are clear enough for an AI agent to decide when this tool is appropriate.

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

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

Annotations already indicate read-only; description adds return value content but lacks detail on real-time accuracy or caching.

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

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

Single clear sentence with no waste.

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

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

Given zero parameters and no output schema, description is fully adequate for understanding tool behavior.

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

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

No parameters, so baseline 4 applies. No additional parameter information needed.

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

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

Description clearly states the tool returns current latitude/longitude of the ISS. Verb is implied, and it distinguishes from sibling tools like astros.

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

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

No explicit guidance on when to use this tool versus alternatives, but siblings do not overlap in purpose. Implied use case.

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

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

The description discloses rate limits (5 per identifier per day), that it is free and does not count against quota, and how feedback is used (digests read daily, affects roadmap). The annotation readOnlyHint=false aligns with its mutability. Lacks details on the exact response or whether feedback is logged, but sufficient.

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

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

The description is a single, well-organized paragraph covering purpose, use cases, dos and don'ts, and constraints. Every sentence adds value; no fluff.

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

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

Given the tool's low complexity (3 params, nested object) and full schema coverage, the description completes the picture by explaining feedback lifecycle (daily digests, roadmap impact). No output schema is present, but the tool likely returns a simple acknowledgment; the description could mention that, but it's not critical.

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

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

Schema coverage is 100% with good field descriptions. The description adds value by advising to describe issues in terms of Pipeworx tools/packs and not to paste user prompts, clarifying how to fill the message and context fields effectively.

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

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

The description clearly states the tool is for giving feedback (broken, missing, praise) to the Pipeworx team, using specific terms like bug, feature, data_gap. It distinguishes itself from siblings whose purposes differ (e.g., ask_pipeworx for questions).

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 (bug, feature, data_gap, praise) and provides a strong 'when not to' by advising not to paste end-user prompts. It also mentions rate limits and that it is free. Could be improved by directly contrasting with sibling tools like ask_pipeworx, but the guidance is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value beyond annotations by disclosing caching behavior (5min-1h), aggregation source (CF analytics-engine), and privacy assurances (no PII). This provides a richer behavioral picture 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 compact (three sentences) and well-structured. It front-loads the core functionality, then lists use cases as a bullet-point-like list, and finishes with implementation details. Every sentence serves a purpose: stating the output, providing usage examples, and explaining data sourcing and caching.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is fully adequate. It explains what is returned (top tools, packs, volume), how it is aggregated, and caching freshness. There is no missing information needed for an agent to decide when and how to invoke this tool.

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

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

The input schema has 100% coverage with a description for the single parameter 'window' including an enum. The description adds context by explaining the semantic difference: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This goes beyond just restating the enum values, providing actionable guidance on when to use each window.

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 returns: 'top tools, top packs, and total call volume over a recent window.' It specifies the resource (trending usage data on Pipeworx) and the verb (returns), and distinguishes it from sibling tools like 'ask_pipeworx' or 'entity_profile' by focusing on aggregate, trending signals rather than specific queries or entity lookups.

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

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

The description explicitly lists three use cases: discovering hot data sources, confirming canonical tools, and assessing alignment with agent needs. While it does not explicitly state when not to use it or name alternative tools, the use cases provide clear context for appropriate usage. A minor gap is the lack of exclusions, but the guidelines are still strong.

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

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

Annotations (readOnlyHint:true, destructiveHint:false) already indicate safety, but the description adds substantial behavioral context: it searches, groups related markets, checks monotonicity, and returns ranked opportunities. This fully complements the annotations without contradiction.

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

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

The description is concise at under 150 words, front-loads the purpose in the first sentence, and uses clear structure (two modes with examples). Every sentence contributes meaning without redundancy.

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

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

Given the absence of an output schema, the description adequately explains the return format ('ranked opportunities with suggested trade direction + reasoning'). Together with annotations and schema, it covers all necessary information for correct tool 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 coverage is 100% with descriptions for both parameters. The description adds value by explaining the two modes and providing examples ('when-will-bitcoin-hit-150k', 'Strait of Hormuz traffic returns to normal'), clarifying how each parameter drives different behavior.

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

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

The description clearly states the tool's function: finding arbitrage on Polymarket via monotonicity violations. It specifies two distinct modes ('event' and 'topic') with precise explanations, differentiating it from any sibling tools by focusing on arbitrage detection.

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

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

The description explicitly guides when to use each mode: 'event' for a single event slug, 'topic' for cross-event searches. It provides a concrete example (May/June cutoff events) illustrating why cross-event mode is necessary. While it doesn't explicitly say when not to use the tool, the mode selection is clear.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, and the description does not contradict these. It adds valuable behavioral details: the tool scans, groups by asset, fetches price history once (performance consideration), computes model probability, and ranks by edge. It also notes the limitation to crypto-price bets in V1, providing full transparency.

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

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

The description is front-loaded with the main purpose and efficiently conveys the algorithm and use case. It is somewhat lengthy but every sentence adds value, detailing the model, data sources, and logic. There is no filler, though it could be slightly more concise without losing clarity.

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

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

Given the absence of an output schema, the description adequately explains the return value: 'Top N ranked by edge magnitude with suggested trade direction'. It covers the inputs, method, and intended use case comprehensively. The tool's complexity is matched by thorough contextual information, making it fully understandable 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?

With 100% schema description coverage, the baseline is 3. The description adds no additional parameter details beyond what the schema provides. It does mention 'top N' and ranking by edge magnitude, which implicitly relates to the 'limit' parameter, but this is already covered in the schema. The parameter semantics are adequately served by the schema alone.

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

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

The description clearly states the tool's purpose: scanning high-volume Polymarket markets to find those with greatest disagreement between Pipeworx data and market price. It specifies the verb (scan, return), resource (Polymarket markets), and distinguishes from siblings like polymarket_arbitrage by focusing on edges from a specific model. The 'V1 covers crypto-price bets' further refines scope.

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

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

The description explicitly states the tool is built for the 'what should I bet on today' question, indicating it is for discovering opportunities without manual paging. It implies not to use it for non-crypto bets or single market analysis, but does not name specific alternatives among siblings. This is clear guidance, though a direct contrast with polymarket_arbitrage would improve it.

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

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

Annotations already mark as read-only and idempotent. The description adds behavioral context: explains why spreads exist (different participant pools) and details the output structure (leg prices, spread). 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 front-loaded purpose, clearly separated modes, and output summary. It is efficient but could be slightly more concise.

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

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

For a tool with no output schema, the description adequately describes the return format (leg prices, spread). With 3 params and moderate complexity, the coverage 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% with parameter descriptions. The description adds value by explaining the override behavior between topic and explicit parameters, but this does not significantly surpass baseline.

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

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

The description clearly states the tool calculates cross-venue spread between Kalshi and Polymarket, a specific verb-resource combination. It distinguishes itself from sibling tools like polymarket_arbitrage by focusing on inter-venue arbitrage.

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

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

The description explicitly outlines two modes (topic and explicit) with clear guidance on when to use each. It mentions the arb signal, implying use cases, but does not provide explicit exclusions or 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 provide readOnlyHint: true. The description adds value by explaining scoping (anonymous IP, key hash, account ID) and the dual behavior (retrieve or list). No contradiction.

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

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

The description is concise—two sentences and a short phrase—with no wasted words. Core purpose is front-loaded, and 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 tool with one optional parameter, the description covers behavior, scoping, and pairing with siblings. No output schema needed; completeness is excellent.

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

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

With 100% schema coverage, the description reiterates the key parameter's purpose and omitting lists all keys. It adds semantic examples (ticker, address, notes) that enrich 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 retrieves a saved value by key or lists all keys when omitted. It uses specific verbs and identifies the resource (saved values via remember). It distinguishes from siblings like forget and remember.

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

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

The description explains when to use the tool (to look up stored context without re-deriving) and implicitly contrasts with remember and forget. It could explicitly mention when not to use, but the context is clear enough.

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

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

Annotations mark it readOnlyHint=true, consistent with read operation. Description adds value by detailing parallel fan-out to three sources and return format (structured changes, count, 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?

Single paragraph packs essential information without excess. Could be slightly more structured (e.g., bullet points), but every sentence contributes value.

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

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

No output schema, so description should detail return structure; 'structured changes' is vague. For a complex tool fanning out to multiple sources, more specifics on output format would improve completeness.

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

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

Schema coverage is 100%, but description enhances with examples for 'since' (ISO and relative), explains 'value' as ticker or CIK, and notes 'type' only supports company. Adds clarity 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 'What's new with a company' and lists example queries, specific verb+resource, distinguishes from siblings like entity_profile. It specifies fan-out to SEC, GDELT, USPTO, making purpose unambiguous.

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

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

Provides explicit use case triggers, example queries, and parameter guidance for 'since' (ISO or relative). Does not exclude alternatives explicitly, but context from siblings and description implies appropriate usage.

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

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

Annotations provide readOnlyHint=false, and the description exceeds that by detailing scope (by identifier), persistence (authenticated vs anonymous), and retention period (24 hours). 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?

Four concise sentences covering purpose, usage, behavioral details, and pairing with sibling tools. No redundant information.

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

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

With only 2 parameters, full schema coverage, no output schema needed (write operation), and clear annotations, the description fully covers all necessary context for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for both key and value. The description adds example key names (e.g., 'subject_property') and clarifies value as any text, but this is marginal improvement over the schema.

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

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

The description clearly states 'Save data the agent will need to reuse later', with specific verb+resource (save key-value pairs). It distinguishes from siblings by mentioning recall and forget tools.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward', and pairs with recall and forget for retrieval and deletion. No exclusions needed.

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

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

Annotations declare readOnlyHint=true, confirming safe read operation. Description adds behavioral context by specifying return values (IDs, pipeworx:// citation URIs) and multiple ID systems, aligning with annotations and providing transparency beyond them.

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

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

Single paragraph with front-loaded purpose, followed by usage guidelines, examples, and workflow note. Every sentence is essential and contributes to understanding. No redundancy or unnecessary text.

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

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

Despite no output schema, description fully explains return values (IDs plus citation URIs) and entity types. It covers the tool's role in the workflow ('Use this BEFORE') and the supported ID systems, making it complete for an identifier lookup tool.

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

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

Input schema has 100% coverage with descriptions. Description adds significant value by explaining parameter types with examples (e.g., ticker, CIK, name for company; brand/generic for drug) and clarifying that the output includes multiple identifier types, enriching the semantics 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 looks up canonical/official identifiers for companies or drugs, with specific verb 'look up' and resource description. It distinguishes itself from sibling tools by stating it replaces multiple lookups and should be used before other tools.

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

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

Explicitly states when to use (when needing CIK, ticker, RxCUI, LEI) and when to call it (before other tools that need official identifiers). Provides concrete examples like 'Apple' and 'Ozempic' to guide usage.

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

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

Annotations (readOnlyHint, idempotentHint) already indicate safe behavior. Description adds context about probing each entity with ai_visibility_check and output structure (ranked list with score, confidence, signal density). No contradictions.

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

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

Three sentences, each adding value: what it does, how it works, when to use it. No fluff.

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

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

Description fully covers purpose, usage, and output (ranked list) despite no output schema. Sufficient for an agent to select and invoke correctly.

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

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

Schema descriptions cover all 4 parameters; description adds minimal extra meaning beyond reinforcing the role of entities (first as subject). Baseline 3 is appropriate given full 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?

Clearly states the tool compares AI visibility of multiple entities side-by-side, referencing its underlying call to ai_visibility_check and the ranking output. Distinct from sibling ai_visibility_check which handles single 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?

Provides example use case for competitive AI-marketing audits and a concrete question. Implicitly suggests when to use (multiple entities) vs. single-entity sibling. Could be more explicit about when not to use, but current guidance 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?

Description adds behavioral traits beyond annotations: composite nature, graceful degradation on bundlephobia timeout (5-30s first measurement), partial failures, and that it returns even with failures. No contradictions with annotations.

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

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

Well-structured with purpose front-loaded, then details and caveats. Could be slightly more concise (e.g., 'fans out across' is jargon), but overall 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?

No output schema, but description lists return fields (summary, per-advisory, links, alternative versions) and covers partial failures. Complete for the tool's complexity.

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

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

Schema coverage is 100% and description adds valuable context: scoped packages accepted, version defaults to latest, and explains how parameters are used in the check. Enhances schema meaning.

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

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

The description clearly states the tool's purpose as a composite check for adding an npm package, listing what it covers (license, advisories, size, etc.) and distinguishing it from sibling tools like scan_competitor_ai_presence.

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

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

Explicit usage guidance: 'Use whenever an agent asks "is X safe / popular / small"'. Also notes NPM ecosystem only and mentions fallback for other ecosystems, providing clear context.

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

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

The description discloses the return structure (verdict, structured form, actual value with citation, percent delta) and data sources (SEC EDGAR+XBRL), adding behavioral context beyond the readOnlyHint annotation. It does not contradict annotations, scoring high for transparency.

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

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

The description is well-structured with a clear one-liner, usage guidance, version info, and return details. It is front-loaded but slightly verbose with the 'replaces 4-6 sequential calls' note, though each sentence adds value. A score of 4 reflects good conciseness without being overly terse.

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 input schema (one parameter) and presence of annotations, the description fully covers the tool's scope, allowed claims, behavioral notes, and return artifacts. It is complete for the tool's complexity, including version constraints and data source limitations.

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

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

Schema coverage is 100% with a well-described 'claim' parameter. The description reinforces the parameter's meaning with examples, but does not add significant new semantics beyond the schema, earning a baseline score of 3.

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

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

The description clearly defines the tool as fact-checking natural-language claims against authoritative sources, specifically company financial claims via SEC EDGAR+XBRL. It provides example queries and distinguishes itself by noting it replaces 4-6 sequential calls, making the purpose very specific and actionable.

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

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

The description explicitly states when to use the tool (e.g., 'Use when an agent needs to check whether something a user said is true') and gives example trigger phrases. However, it does not explicitly mention when not to use it or provide alternatives, which is acceptable given the clear purpose.

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