dictionary

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

The description adds significant value beyond annotations. It discloses that Anthropic probing requires a BYO API key and that the user pays Anthropic directly. It also describes the return structure (per-model {score, confidence, signals, raw_response} + combined view). No contradictions with annotations (readOnlyHint, idempotentHint, etc.) are present.

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

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

The description is a single coherent paragraph that covers purpose, usage, parameters, and returns without superfluous text. It is well-structured but could be slightly more concise by breaking into bullet points. Still, it earns its 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 that there is no output schema, the description adequately describes return values (per-model scores, confidence, signals, raw_response). It also explains the default model and the optional Anthropic probing. The tool has 4 parameters, and all are addressed. Slight room for more detail on error cases or rate limits, but overall complete.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema. For example, it explains that '_apiKey' is optional and passed directly to Anthropic, and 'context' helps disambiguate. It also gives examples for 'entity'. This elevates the description above the 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 probes LLMs for knowledge about a business/brand/product/topic and returns a visibility score per model. It provides concrete examples (e.g., 'Pipeworx') and specifies the default model (Workers AI Llama-3.3-70b), making the purpose highly specific and distinguishable from siblings.

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 use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It implies when to use it (when assessing AI visibility) but does not explicitly exclude alternatives or mention when not to use. However, the context is clear enough for an agent to decide.

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

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

With no annotations provided, the description carries full burden and does well. It discloses key behavioral traits: the tool automatically selects data sources and fills arguments, handles natural language questions, and returns results. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational context beyond basic functionality.

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 efficiently structured: first sentence states core functionality, second explains the automation benefit, third provides usage guidance, and examples illustrate practical applications. Every sentence adds value with zero redundancy. It's appropriately sized for a single-parameter tool with clear differentiation from siblings.

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 single-parameter tool with no annotations and no output schema, the description provides strong context about what the tool does and when to use it. It explains the automation mechanism and provides concrete examples. The main gap is lack of information about return format or error handling, but given the tool's simplicity, the description is largely 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema's 'Your question or request in natural language' - it reinforces this with 'Ask a question in plain English' and provides examples, but doesn't add significant new information about the question parameter's format or constraints.

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

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

The description clearly states the tool's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'). It distinguishes from siblings by emphasizing natural language queries rather than structured tool usage.

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 this tool: 'No need to browse tools or learn schemas — just describe what you need.' It contrasts with sibling tools by positioning this as a high-level query interface versus specific operations like define_word or recall. The examples further clarify appropriate use cases.

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, openWorldHint=true, destructiveHint=false. The description adds rich behavioral detail: resolves market, classifies bet type, fans out to appropriate data packs, and returns a comparison. This goes well beyond the annotations, explaining the reasoning logic.

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 efficiently structured with front-loaded purpose, followed by input, behavior, and use cases. All sentences add value. It is slightly verbose but not wasteful, earning a high 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 no output schema, the description clearly states what the tool returns (evidence packet + comparison). For a complex tool with multi-source fan-out, this is sufficient for an agent to decide to invoke it. More detail on evidence packet structure could 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?

Input schema has 2 parameters with 100% description coverage. The description repeats examples for 'market' (slug, URL, text) already in schema, and does not add extra meaning for 'depth' beyond the enum values. Baseline 3 is appropriate as the schema already documents parameters well.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data. It specifies input types (slug, URL, question text) and output (evidence packet + comparison). It distinguishes itself by promoting that agents using this tool convert better than those 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 provides explicit use cases: 'should I bet on X?', 'what does the data say?', 'is there edge?'. It does not explicitly mention when not to use it or alternatives, but the context makes its niche clear. Sibling tools like 'ask_pipeworx' exist but are not directly compared.

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?

No annotations are provided. The description adds behavioral context by stating it returns paired data and pipeworx:// URIs and replaces many calls, hinting at read-only nature and efficiency. However, it lacks explicit statements about authorization, rate limits, or error handling.

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 long, front-loaded with the core purpose, and contains no filler. Every sentence adds value: purpose, type-specific data, and efficiency gain.

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 adequately explains the return data for each type and mentions resource URIs. It covers the main use case but could be more complete by noting error handling or behavior for missing entities.

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 descriptions for both parameters. The description enhances the schema by explaining what data is compared for each type, adding meaning beyond the parameter names and value formats.

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

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

The description clearly states the tool compares 2-5 entities side by side in one call, specifying two types (company, drug) and their data fields. It distinguishes itself from siblings by noting it replaces 8-15 sequential agent calls, indicating a batch comparison capability.

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

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

The description provides clear context for when to use the tool (comparing multiple entities of type company or drug) and implies efficiency over sequential calls, but it does not explicitly state when not to use it or name alternative tools like resolve_entity for single lookups.

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?

No annotations are provided, so the description carries the full burden. It mentions the return content (definitions, phonetics, part of speech, usage examples), which adds some behavioral context, but it doesn't disclose other traits like error handling, rate limits, or authentication needs, leaving significant gaps for a tool with no structured safety hints.

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

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

The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the action and return values without any wasted words, making it efficient and easy to understand.

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 (one parameter, no output schema, no annotations), the description is somewhat complete by covering the purpose and return values. However, it lacks details on usage guidelines and behavioral traits, which are needed for full context, making it adequate but with clear 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 input schema has 100% description coverage, with the single parameter 'word' documented as 'The word to look up'. The description adds no additional meaning beyond this, such as format constraints or examples, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the action ('Look up a word in the dictionary') and resource ('word'), specifying what the tool does. However, it doesn't explicitly differentiate from the sibling tool 'get_synonyms', which likely provides related but different functionality, so it doesn't reach the highest score of 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?

The description provides no guidance on when to use this tool versus the sibling 'get_synonyms' or any alternatives. It states the purpose but lacks explicit context, exclusions, or comparisons, leaving usage decisions unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it performs a search based on natural language queries, returns relevant tools with names and descriptions, and has a specific use case (large tool catalogs). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions.

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 perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does, and the second provides critical usage guidance. Every word earns its place with no redundancy or unnecessary 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 moderate complexity (search functionality with two parameters) and the absence of both annotations and output schema, the description provides strong contextual information about purpose and usage. However, it doesn't describe the return format or what 'most relevant' means in practice, leaving some gaps for a search tool.

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

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

The schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain query formatting nuances or limit implications). This meets the baseline expectation when schema coverage is complete.

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 specific action ('Search the Pipeworx tool catalog') and resource ('tool catalog'), with explicit scope ('by describing what you need'). It distinguishes from siblings like 'define_word' and 'get_synonyms' by focusing on tool discovery rather than language 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?

The description provides explicit usage guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear conditions for when to use this tool versus alternatives, including the threshold of available tools and the need for discovery.

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

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

Discloses return format (pipeworx:// citation URIs) and performance benefit (replaces 10–15 calls). With no annotations, it adequately covers behavioral expectations, though rate limits or auth requirements are not mentioned.

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 with front-loaded purpose. No wasted words; each sentence adds value by detailing outputs and alternatives.

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 low parameter count (2) and full schema coverage, the description is fully complete. It covers return information, usage guidelines, and performance expectations, with 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?

Adds meaning beyond schema by explaining that type only supports 'company', value can be ticker or CIK, and that names are not supported. Schema coverage is 100%, but description enriches context.

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 'Full profile of an entity across every relevant Pipeworx pack in one call' and details the specific data returned (SEC filings, revenue, patents, news, LEI), clearly distinguishing its purpose. It also contrasts with alternatives like usa_recipient_profile and resolve_entity.

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 (for company profiles across packs) and when not (for federal contracts, use usa_recipient_profile). Also instructs to use resolve_entity first if only a name is available, providing clear prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a memory, implying a destructive mutation, but doesn't specify whether deletion is permanent, reversible, or requires specific permissions. It lacks details on error handling (e.g., what happens if the key doesn't exist) or side effects, leaving significant gaps for a mutation tool.

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, efficient sentence with zero waste. It is front-loaded with the core action ('Delete') and resource, making it immediately understandable. Every word earns its place, achieving optimal conciseness.

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

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

Given the tool's complexity (a destructive mutation with no annotations and no output schema), the description is incomplete. It doesn't address behavioral aspects like permanence, permissions, or error handling, nor does it explain return values or side effects. For a delete operation, this leaves critical gaps in understanding how to use it safely and 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 input schema has 100% description coverage, with the 'key' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format examples or constraints). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.

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

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

The description clearly states the specific action ('Delete') and resource ('a stored memory by key'), distinguishing it from sibling tools like 'recall' (retrieve) and 'remember' (store). It precisely communicates the tool's function without ambiguity.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory key), exclusions, or how it differs from other memory-related operations like 'recall' or 'remember'. The description is purely functional without contextual advice.

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?

Describes the process (fetch, extract, emit) which aligns with annotations (readOnlyHint, idempotentHint). Adds value beyond annotations by detailing the output format and steps, though no special side effects are mentioned.

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 well-structured sentences: purpose, process, usage. Front-loaded with main action, no filler. 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?

Covers all essential aspects: input (URL, max_links), process (fetch, extract), output (text blob, file location), and usage scenarios. No output schema but description sufficiently explains return value.

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 essentially repeats schema descriptions for both parameters. Does not add new semantic meaning beyond what schema provides, so baseline score 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?

States the verb 'Generate', resource 'llms.txt', and target audience 'AI crawlers'. Clearly distinguishes from siblings by focusing on a specific file format. No ambiguity.

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 three use cases (client indexing, personal project, competitor audit) but does not explicitly state when not to use or alternatives among sibling tools. Clear context but lacks exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about response format, error handling, rate limits, authentication needs, or whether it's a read-only operation. The description is minimal and lacks behavioral context.

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

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

The description is extremely concise—a single sentence with zero waste. It's front-loaded with the core purpose and efficiently communicates the essential function without unnecessary elaboration, making it easy to parse quickly.

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 lack of annotations and output schema, the description is incomplete for a tool that presumably returns structured data. It doesn't explain what the output looks like (e.g., lists of synonyms/antonyms, categories, or examples), nor does it cover error cases or usage limits. For a tool with no structured behavioral hints, this is a significant gap.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'word' adequately. The description adds no additional parameter semantics beyond what's in the schema, such as word format constraints, language considerations, or examples. The baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('get synonyms and antonyms') and identifies the resource ('for a word'). It distinguishes from the sibling tool 'define_word' by focusing on lexical relationships rather than definitions, though it doesn't explicitly mention this distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'define_word' or suggest scenarios where synonyms/antonyms are more appropriate than definitions, nor does it specify any prerequisites or exclusions for 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?

No annotations are provided, so the description carries full burden. It discloses the rate limit (5 per identifier per day) and advises against including sensitive user prompts. It also notes the tool is 'Free,' indicating no cost. Adequate transparency for a feedback tool.

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, tightly packed with information. The first sentence immediately states purpose, followed by enumerations and constraints. No redundant or unnecessary words.

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

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

Given the tool's simplicity and the schema covering all parameters, the description is complete. It covers what the tool does, when to use it, what to include in the message (and what not to), and the rate limit. No output schema is needed for this fire-and-forget feedback tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context about not including end-user prompts and the rate limit, which are not in the schema. However, it does not significantly enhance the understanding of individual parameters beyond what the schema already provides.

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

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

The description clearly states the tool's purpose: 'Send feedback to the Pipeworx team.' It enumerates specific use cases (bug reports, feature requests, missing data, praise) and distinguishes itself from sibling tools which are primarily data retrieval or memory tools.

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

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

The description explicitly lists when to use the tool (for feedback) and provides a critical do-not (avoid including end-user prompt verbatim). It also mentions rate limits. However, it does not explicitly state when not to use or suggest alternatives, but the uniqueness of the feedback function among siblings 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?

Description adds value beyond annotations by disclosing data source (CF analytics-engine), lack of PII, and caching behavior (5min-1h). Annotation readOnlyHint already indicates non-destructive, but caching info is new and useful.

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

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

Three concise sentences with no fluff: definition, use cases, technical notes. Front-loaded with core purpose.

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

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

Given low complexity (1 param, no required fields, no output schema), description covers what is returned, caching, and data source. Annotations cover safety. Complete for an AI agent to invoke.

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?

Single parameter window with enum and full schema coverage. Description adds context differentiating short vs long windows ('what's hot right now' vs 'steady-state demand'), which is beyond the schema 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?

Name and description clearly state it returns top tools, top packs, and total call volume on Pipeworx over recent windows. Three use cases differentiate it from siblings like ask_pipeworx or 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?

Explicitly lists three practical use cases (discovering hot data sources, confirming canonical tools, checking alignment). Implicitly guides when to use shorter vs longer windows, but does not directly mention alternatives 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 indicate read-only, open-world, non-destructive. The description adds behavioral context: it searches child markets for an event or across events for a topic, and returns ranked opportunities with reasoning. 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?

Concise, front-loaded with main purpose, uses bullet-point-like structure for modes. 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?

Despite no output schema, the description states returns 'ranked opportunities with suggested trade direction + reasoning'. Covers essential aspects of modes and use cases. Minor gap: lacks explanation of 'monotonicity violations' for users unfamiliar with the concept, but overall sufficient for intended audience.

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 2 params with 100% coverage. Description enriches both parameters with explanations of modes, examples (e.g., 'when-will-bitcoin-hit-150k'), and behavior (walks child markets, searches across events). Adds significant meaning beyond 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 clearly states the tool's purpose: finding arbitrage opportunities via monotonicity violations. It explains two modes with concrete examples, effectively distinguishing from likely 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?

Explicit guidance on when to use each mode ('event' vs 'topic'), including why cross-event mode is necessary for cases Polymarket splits into separate events. Covers both use cases without ambiguity.

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

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

The description adds significant detail beyond annotations: it explains the scanning process, grouping by asset, single price fetch for caching, model probability computation, and ranking. This transparency aligns with readOnlyHint and openWorldHint, and no contradictions exist.

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

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

The description is relatively long but front-loaded with the primary action. Every sentence serves a purpose, though some details (e.g., model source) could be condensed. 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?

The description covers the tool's purpose, process, and use case well, but lacks specifics about the return format (e.g., structure of ranked edges) since no output schema is provided. Otherwise comprehensive.

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 integrates parameters meaningfully (e.g., 'top N' for limit, 'volume window' for window, 'minimum edge' for min_edge_pp) with defaults and constraints, 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?

The description clearly states the tool scans Polymarket markets for edges, specifies it covers crypto bets using a lognormal model, and includes the intended use case. It distinguishes from siblings like polymarket_arbitrage by focusing on a specific discovery task.

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

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

The description explicitly frames the tool for discovering opportunities without manual browsing, but does not mention when to avoid it or compare to siblings like bet_research. The context is clear but exclusions are absent.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes beyond this by explaining the data source, typical spread magnitude (2-25pp), the two modes, and the return 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?

The description is concise at 4-5 sentences, front-loaded with the purpose, and every sentence adds value without redundancy. It efficiently covers why, how, and what.

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

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

Given no output schema, the description explains return values (prices and spreads) adequately. It covers both modes and parameter interactions. Minor gap: no mention of error handling or edge cases.

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

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

The input schema provides 100% description coverage. The tool description adds value by clarifying the two modes and the relationship between parameters (e.g., explicit tickers override topic-mapped sides) and providing examples.

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

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

The description clearly identifies the tool's purpose: computing cross-venue spreads between Kalshi and Polymarket for the same question. It distinguishes from siblings by focusing on arbitrage signals between two prediction markets, using specific language like 'that delta is a real arb signal.'

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

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

The description explains when to use the tool (to find arbitrage signals between venues) and provides two modes: topic shortcuts for quick access or explicit tickers for custom pairings. It does not explicitly mention alternatives, but the use case is well-defined.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool retrieves or lists memories stored across sessions, which is useful behavioral context. However, it doesn't mention potential limitations like memory persistence, retrieval failures, or whether listing all keys has performance implications. The description adds value but lacks comprehensive behavioral details.

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 functionality in the first sentence and uses a second sentence to provide usage context. Both sentences earn their place by adding clarity and guidance without redundancy. It's appropriately sized for a simple tool with one optional parameter.

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 (one optional parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, usage, and parameter semantics effectively. However, without annotations or output schema, it could benefit from mentioning the format of retrieved memories or listing output, but this is a minor gap for a retrieval tool.

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

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

The schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics: it explains that omitting the key parameter triggers listing all stored memories, which clarifies the optional parameter's effect beyond the schema's 'omit to list all keys.' This provides valuable context for parameter usage, elevating the score.

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: 'Retrieve a previously stored memory by key, or list all stored memories (omit key).' It specifies the verb ('retrieve'/'list') and resource ('memory'), but doesn't explicitly differentiate from sibling tools like 'remember' or 'forget' beyond mentioning retrieval vs. saving context.

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

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

The description provides clear context for when to use the tool: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It also implicitly indicates when to omit the key parameter ('omit key' to list all). However, it doesn't explicitly state when NOT to use it or name alternatives among siblings like 'forget' for deletion.

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?

No annotations provided, but description details parallel fan-out to multiple sources, accepted date formats, and return format (structured changes, count, URIs). No mention of destructive actions or rate limits, but sufficient for a read-like tool.

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

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

Extremely concise (3-4 sentences) with front-loaded purpose. Every sentence adds information 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?

Provides enough detail for an agent to understand inputs, behavior, and outputs. Although no output schema, description clearly lists return components. Covers all key aspects for a change-monitoring 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 has 100% coverage, but description adds value: explains type='company' triggers multiple sources, clarifies acceptable date formats with examples ('7d', '30d', '3m', '1y'), and suggests '30d' or '1m' for typical monitoring.

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 describes the tool as showing what's new for an entity since a point in time, with specific sources (SEC EDGAR, GDELT, USPTO). Lacks explicit differentiation from siblings like entity_profile or compare_entities, but the temporal delta focus distinguishes it.

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 ('brief me on what happened with X' or change-monitoring workflows) but does not specify when not to use it or mention 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool performs a write operation ('store'), specifies persistence characteristics ('persistent memory' vs. '24 hours'), and implies it's for session-scoped data. However, it doesn't mention potential limitations like storage size, rate limits, or error conditions, leaving some gaps in 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 highly concise and well-structured, consisting of two sentences that efficiently convey purpose, usage guidelines, and behavioral context without any wasted words. The first sentence states the core function, and the second adds critical behavioral details, making it front-loaded and easy to parse.

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

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

Given the tool's moderate complexity (a write operation with session management), no annotations, and no output schema, the description does a good job of covering essential aspects: purpose, usage, and persistence behavior. However, it lacks details on return values (e.g., confirmation message or error handling) and doesn't address potential constraints like key uniqueness or storage limits, leaving room for improvement in 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?

The schema description coverage is 100%, so the input schema already fully documents the two parameters (key and value). The description adds minimal semantic value beyond the schema, as it doesn't provide additional syntax, format details, or usage examples for the parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra insights.

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 with specific verbs ('store a key-value pair') and resources ('in your session memory'), distinguishing it from sibling tools like 'forget' (which likely removes) and 'recall' (which likely retrieves). It explicitly mentions what types of data can be saved ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous and 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 provides explicit guidance on when to use this tool by listing specific use cases ('save intermediate findings, user preferences, or context across tool calls'). It also distinguishes it from alternatives by implying that 'forget' and 'recall' serve different purposes (deletion and retrieval, respectively), and it includes important context about session persistence ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which helps in decision-making.

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?

No annotations are provided, so the description carries the full burden. It details what the tool returns (ticker, CIK, company name, URIs) and version constraints, but omits authentication needs, rate limits, or error behaviors. This is adequate but not exhaustive.

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 (3 sentences), front-loaded with the main purpose, and each sentence adds value: action, supported inputs, outputs, and benefit. No wasted words.

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

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

Given the tool's simplicity (2 parameters, simple output), the description covers the purpose, inputs, outputs, and a version note. Without an output schema, it adequately describes the return values. Sibling tools are distinct.

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

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

The input schema already provides 100% coverage of parameter descriptions. The description adds examples and clarifies the version scope (v1 supports 'company'), but does not add significant meaning beyond the schema, so a 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 tool resolves an entity to canonical IDs, specifying the verb 'resolve' and resource 'entity'. It distinguishes from siblings like ask_pipeworx or define_word by focusing on cross-source canonical ID resolution.

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 context that it replaces 2–3 lookup calls, implying efficiency. However, it does not explicitly state when not to use the tool or provide alternatives among siblings, which would improve guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with specific fields. It also notes that the first entity is treated as the 'subject'. This exceeds what annotations provide, though it does not mention potential rate limits or authentication needs for the 'anthropic' model beyond the 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?

The description is appropriately sized and front-loaded, starting with the core action. It is structured in a logical flow: purpose, process, use case, example, and output. However, it could be slightly more concise by removing the parenthetical 'your brand + N competitors' and the example question, which, while helpful, adds 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 rich annotations and 100% schema description coverage, the description adequately covers all necessary context. It explains the output format ('ranked list with score, confidence, signal density per entity') even without an explicit output schema. The process of probing and ranking is clearly described. No gaps remain for an agent to correctly 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?

Schema description coverage is 100%, so the baseline is 3. The description reiterates the treatment of the first entity as the subject but does not add significant new semantic detail beyond the already-informative schema property descriptions. It does not provide additional guidance on parameter formats or interdependencies.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, specifying both the verb 'compare' and the resource 'AI visibility'. It distinguishes from the sibling tool 'ai_visibility_check' by emphasizing the multi-entity comparison and provides an explicit use case ('competitive AI-marketing audits').

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 context for when to use the tool: 'Useful for competitive AI-marketing audits'. It includes a concrete example question and implicitly advises against using it for single-entity checks (which would be covered by the sibling 'ai_visibility_check'). No explicit alternatives are listed, but the phrasing strongly implies the appropriate scope.

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

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

With no annotations, the description carries full transparency burden. It explains the tool's behavior: returns a verdict with structured data and citations. It does not discuss destructive actions or permissions, but given the read-only nature, the description is adequate.

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, with three sentences covering purpose, scope, and output. It is well-structured and front-loaded with the primary action. No unnecessary words.

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

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

Given the simple single-parameter tool with no output schema, the description sufficiently covers the input, output (verdict types, citation, delta), and limitations. It is complete for the tool's complexity.

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

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

The only parameter 'claim' has a schema description, and the tool description adds context about the types of claims it supports (e.g., revenue, net income). This goes beyond the schema to guide the agent on valid inputs.

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

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

The description clearly states the core purpose: fact-checking natural-language claims against authoritative sources. It specifies the domain (company-financial claims for public US companies) and distinguishes from sibling tools by explicitly listing the types of claims supported and the value it provides over sequential agent 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 indicates when to use the tool (for fact-checking financial claims) and what it replaces (4-6 sequential agent calls). It does not explicitly state when not to use it, but the scope is well-defined by mentioning v1 supports only certain claim types.

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