uored

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

With no annotations, the description carries the full burden. It discloses the output fields (name, type, price range) but omits behavioral traits such as whether the result is truly random, side effects, or error handling (e.g., for invalid participant counts). This leaves the agent uncertain about tool behavior beyond the basic function.

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

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

The description is very concise with two sentences, front-loading the core action and then output details. Every word earns its place, 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 simplicity, the description covers the essential purpose, parameter, and output. Output schema exists to detail return structure. However, it lacks mention of randomness behavior or error conditions, which would improve completeness for an agent.

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

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

Schema description coverage is 100%, so the parameter is already well-documented. The description adds minor semantic value by calling it 'group size' and providing examples, but these largely duplicate the schema's examples. Baseline 3 is appropriate as the description does not significantly enhance 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 finds a random activity for a specific group size, specifying the verb 'Find' and resource 'random activity' with a clear scope. It also mentions the return fields (name, type, price range), distinguishing it from siblings like 'random_activity' (no participant filter) and 'activity_by_type' (type-based).

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 examples of valid inputs (1 for solo, 4 for group) but does not explicitly state when to use this tool versus alternatives. It lacks explicit when-not/use-case guidance, especially given siblings like 'random_activity' for unconstrained random activities or 'activity_by_type' for type-specific activities.

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 are empty, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, requires authentication, or has side effects. While it mentions return fields, it lacks essential trait information, earning a low score.

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 sentence, front-loaded with the action and filter, and contains no filler or redundant text. It efficiently conveys the core functionality.

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 parameter, full schema coverage, and an output schema, the description covers purpose and return fields adequately. However, it lacks usage guidance and behavioral disclosure, leaving some gaps. Still, it is largely complete for its complexity.

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

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

Schema coverage is 100%, so the input schema already documents the `type` parameter with enum values. The description adds examples ('cooking', 'sport'), but 'sport' is not in the enum, which could mislead. Overall, marginal value added beyond schema.

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

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

The description clearly states the tool finds a random activity filtered by category (type), specifying the verb 'Find' and resource 'activity by category'. It differentiates from sibling `random_activity` (no filter) and `activity_by_participants` (filter by participants). The mention of return fields adds clarity.

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 usage for category-specific activity searches but does not explicitly guide when to use vs alternatives like `random_activity`. No exclusions or when-not-to-use conditions are provided, leaving the agent to infer from 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?

With no annotations provided, the description carries the full burden and does well by explaining key behaviors: it automatically selects tools and fills arguments, handles natural language questions, and returns results. However, it doesn't mention potential limitations like response time, data source availability, 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 efficiently structured with a clear purpose statement, operational explanation, and practical examples—all in three sentences. Every sentence adds value without redundancy, making it easy to understand 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 tool's complexity (natural language processing with automated backend operations) and lack of annotations/output schema, the description is quite complete for guiding usage. It covers purpose, behavior, and examples effectively, though it could benefit from mentioning output format or error scenarios.

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% with one well-documented parameter, so the baseline is 3. The description adds minimal value beyond the schema by emphasizing 'plain English' and 'natural language' in the context, but doesn't provide additional syntax or format details.

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

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

The description clearly states the tool's purpose with specific verbs ('Ask a question', 'get an answer') and resource ('from the best available data source'). It distinguishes itself from siblings by emphasizing natural language processing and automated tool selection, unlike other tools that require specific parameters or schemas.

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

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

Explicit guidance is provided on when to use this tool ('No need to browse tools or learn schemas — just describe what you need') and includes concrete examples. This clearly differentiates it from sibling tools that likely require more structured inputs or specific operations.

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, which the description aligns with by describing data retrieval only. Beyond annotations, it discloses internal fan-out behavior (resolving market, classifying bet, selecting packs), adding rich behavioral context.

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

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

Very concise (4 sentences) with front-loaded verb+resource. Each sentence adds meaningful detail without waste, efficiently covering purpose, inputs, process, and usage scenarios.

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 data (evidence packet + comparison). Inputs, process, and output are all covered, making the tool self-contained for the intended use case.

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 parameters are well-documented. The description adds value by explaining the 'market' parameter accepts slug, URL, or text, and hints at the depth parameter's effect via 'quick vs thorough' fan-out, though not explicitly stated in 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 tool's purpose: researching a Polymarket bet by aggregating Pipeworx data. It specifies inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison), distinguishing it from sibling tools by positioning it as the core betting research tool.

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

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

Explicit usage guidance is provided: 'Use for “should I bet on X?”, “what does the data say about this Polymarket market?”, or “is there edge in this bet?”'. It implies this tool is superior to alternatives for bet context, though explicit when-not-to-use is missing.

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, so description carries full burden. Discloses return data (paired data + URIs) and data sources (SEC EDGAR, FDA). Does not mention mutability or side effects; since it's a comparison tool, none are expected. Could add more on rate limits or authentication needs.

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

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

Three sentences, each earning its place. Front-loaded with main purpose, followed by details and benefit. No redundancy.

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

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

Given two simple params with full schema descriptions and no output schema, the description covers purpose, parameter details, return data, and usage context. 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%, providing baseline 3. Description adds significant context: explains 'type' enum values and what data each type returns, and provides examples for 'values'. This goes beyond the schema's brief descriptions.

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

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

Clearly states the verb ('Compare'), the resource ('entities'), and the scope ('2–5 entities side by side in one call'). Explicitly distinguishes from potential sequential alternatives by noting 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?

Provides explicit context for when to use: comparing 2–5 entities. Does not explicitly list when not to use or alternatives, but the sibling tools ('resolve_entity' for single lookups) and the stated replacement of sequential calls imply boundaries.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a search operation that returns relevant tools based on natural language queries, with an implied read-only nature (searching a catalog). However, it doesn't mention potential limitations like rate limits, authentication requirements, 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 a distinct purpose: the first explains what the tool does, and the second provides critical usage guidance. There's no wasted language, and the most important information (the 'call this FIRST' directive) is appropriately front-loaded.

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

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

Given the tool's moderate complexity (search functionality with 2 parameters), 100% schema coverage, and no output schema, the description is mostly complete. It explains the tool's purpose, usage context, and behavioral approach well, though it could benefit from mentioning what format the results come in (e.g., list of tool objects) since there's no 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?

The input schema has 100% description coverage, so the schema already documents both parameters (query and limit) thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('search', 'returns') and resources ('Pipeworx tool catalog', 'most relevant tools with names and descriptions'). It explicitly distinguishes this from sibling tools (activity_by_participants, activity_by_type, random_activity) by focusing on search functionality rather than activity analysis.

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 ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task'), including a quantitative threshold (500+ tools) and a clear alternative scenario (when you need to find tools rather than analyze activities like the sibling tools).

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

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

No annotations provided, but description discloses output format (pipeworx:// URIs), performance benefit (replaces 10-15 calls), and a limitation (federal contracts excluded). Minor gap: no mention of potential size or rate limits.

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

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

Extremely concise yet information-dense. Every sentence serves a purpose: defining scope, detailing coverage, noting output format, highlighting efficiency, and excluding federal contracts. Perfectly structured.

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

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

For a complex aggregator tool, the description covers purpose, inputs, output format, and limitations. No output schema, but URIs are described. Could mention error handling or data freshness, but overall 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?

Adds meaning beyond schema: explains type is limited to 'company', value can be ticker or CIK with examples, and warns against unsupported names. Fully compensates for any missing schema detail.

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 returns a full entity profile across multiple data sources in one call. It distinguishes from sequential calls and explicitly mentions the sibling tool for federal contracts, leaving 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?

Explicitly states when to use this tool (for comprehensive profiles) and when not (federal contracts) with a direct sibling reference. Also advises using resolve_entity for name resolution, 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 cover critical aspects: whether deletion is permanent or reversible, error handling for non-existent keys, authentication requirements, or rate limits. The description is minimal and lacks behavioral context beyond the basic action.

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, clear sentence with zero waste: 'Delete a stored memory by key.' It is front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place, and there is no unnecessary elaboration.

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 as a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success or failure, return values, or error conditions. For a mutation tool with zero structured coverage, the description should provide more context to be fully helpful to an AI 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?

The input schema has 100% description coverage, with the 'key' parameter fully documented as 'Memory key to delete.' The description adds no additional meaning beyond this, such as key format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter semantics.

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

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

The description clearly states the action ('Delete') and resource ('a stored memory by key'), making the purpose immediately understandable. It distinguishes from sibling tools like 'recall' (retrieve) and 'remember' (store), though it doesn't explicitly mention these distinctions. The description avoids tautology by not just restating the tool name 'forget'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing memory key), when-not scenarios (e.g., if the key doesn't exist), or explicit alternatives among siblings like 'recall' for retrieval. Usage is implied through the action 'delete,' but no contextual guidance is given.

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 rate limit (5/day per identifier) and acceptable content types. With no annotations provided, the description carries full burden; it gives sufficient behavioral context. Does not mention confirmation or storage, but acceptable for a simple 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?

Three sentences, each valuable: first sentence states purpose, second clarifies content guidelines, third discloses constraints. No wasted words. Front-loaded with core function.

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 tool simplicity and complete schema with descriptions, the description covers essential aspects: purpose, usage, and rate limit. Lacks details on feedback handling (e.g., whether user receives confirmation), but sufficient for agent selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor context (e.g., 'be specific') but does not significantly augment parameter meaning beyond the enum descriptions and field definitions already in the schema.

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

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

Description explicitly states 'Send feedback to the Pipeworx team' and enumerates specific use cases (bug reports, feature requests, missing data, praise). Clearly distinguishes from sibling tools which handle queries (ask_pipeworx), memory (remember/recall), or entity 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?

Provides clear guidance on when to use (for feedback types) and what to include/exclude (describe Pipeworx tools/data, omit end-user prompt). Mentions rate limit. Lacks explicit when-not-to-use or alternatives, but use cases are self-explanatory given sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds context about the monotonicity check and return format. It does not contradict annotations, but the behavioral disclosure is redundant with annotations, thus not adding significant value beyond what annotations provide.

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

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

The description is concise and well-structured: it opens with the purpose, explains the logic with examples, and ends with the return format. Each sentence adds value and there is 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 complexity of arbitrage detection, the description covers the key concepts (monotonicity, event slug), explains the rule, and details the output format. There is no output schema, but the description lists return fields, making it complete for agent understanding.

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 high coverage (100%) with a single parameter 'event' described as 'Polymarket event slug (e.g. ...) or full URL.' The description provides an example, but does not add meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool finds arbitrage opportunities in Polymarket events by detecting monotonicity violations. It specifies the logic and differentiates from siblings like polymarket_edges. The verb 'find' and resource 'arbitrage opportunities' are specific 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 explains when to use the tool (when an event has multiple markets with dates/thresholds) and how to pass the input (slug or URL). However, it does not explicitly mention when not to use it or suggest alternative tools, leaving some ambiguity for the agent.

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

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

Beyond annotations (readOnlyHint, openWorldHint), the description details the model (lognormal from FRED + coinpaprika), data fetching strategy, edge computation, and ranking. No contradictions with annotations.

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

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

The description is compact (4-5 sentences), front-loaded with the core purpose, and every sentence adds meaningful detail 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 tool's complexity (3 parameters, no output schema), the description sufficiently explains inputs, process, and output (ranked edges with direction). Annotations cover safety, making this complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the defaults and descriptions are already clear. The description adds minimal extra value by confirming parameter roles in ranking and filtering, but does not significantly enhance understanding.

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

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

The description clearly states the tool scans high-volume Polymarket markets, finds where Pipeworx data disagrees with market price, computes edge, and returns ranked results. It explicitly ties to the user need of discovering betting opportunities, distinguishing it from siblings like polymarket_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 indicates when to use ("what should I bet on today") and notes it covers crypto-price bets V1, implying scope. It lacks explicit exclusions or alternatives but provides sufficient context for appropriate use.

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

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

No annotations exist, so description bears full burden. It discloses return fields and randomness but omits details like source, determinism, or side effects. Adequate but not thorough.

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, front-loaded sentence with no fluff. Every word contributes to purpose 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?

With an output schema defined, the description need not detail return format. It covers purpose and return fields adequately, though could hint at variability of results.

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 in schema (coverage 100%), so baseline is 4. Description adds no parameter info, but none is required.

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

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

The description explicitly states the purpose ('get a random activity suggestion') and lists the returned fields, clearly distinguishing from siblings like activity_by_participants which offer filtered results.

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?

Implies usage context ('cure boredom') but lacks explicit guidance on when not to use or comparison to sibling tools. No alternatives are mentioned, leaving the agent to infer.

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 discloses key behavioral traits: the tool can retrieve by key or list all memories, and memories persist across sessions. However, it doesn't mention error handling (e.g., what happens if key doesn't exist), performance characteristics, or format of returned data. For a tool with zero annotation coverage, this is adequate but leaves gaps.

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 and front-loaded. The first sentence states the core functionality, the second provides usage context. Every word earns its place with no redundancy or fluff. The structure moves from specific operation to broader application context efficiently.

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 (single optional parameter, retrieval operation), no annotations, and no output schema, the description does well. It covers purpose, usage, and parameter semantics adequately. The main gap is lack of information about return format or error behavior, which would be helpful for a retrieval tool with session persistence.

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 the single parameter 'key'. The description adds meaningful context: it explains the semantic effect of omitting the key ('list all stored memories') and clarifies that keys are used to retrieve specific memories. This goes beyond the schema's technical description, providing practical usage guidance.

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 ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes from siblings like 'remember' (store) and 'forget' (delete) by focusing on retrieval operations. The phrase 'by key' adds specificity about the retrieval mechanism.

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 vs alternatives: 'Retrieve a previously stored memory by key, or list all stored memories (omit key).' It also specifies context for usage: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' This clearly differentiates it from storage ('remember') and deletion ('forget') tools.

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

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

No annotations provided, so description carries full burden. It discloses parallel fan-out to multiple sources, accepted date formats, and return structure (structured changes + count + URIs). It does not discuss error handling or rate limits, but for a read-only tool, this level of transparency 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 four sentences with no wasted words. It front-loads the core purpose and efficiently packs essential details (sources, params, output structure) into a compact, readable block.

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 compensates by outlining the return shape. It covers inputs and behavior but lacks mention of error handling, pagination, or limits. Still, it is sufficiently complete for a tool with three well-described parameters.

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

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

Schema coverage is 100%, baseline 3. The description adds meaningful context: for 'since' it clarifies ISO and relative formats with examples, for 'value' it specifies ticker or CIK, and for 'type' it notes only 'company' is supported. This extra detail justifies a 4.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time.' It specifies the entity type (company), the data sources (SEC EDGAR, GDELT, USPTO), and the parallel fan-out behavior. This sufficiently distinguishes it from sibling tools like entity_profile or compare_entities.

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

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

The description provides explicit usage guidance: 'Use for brief me on what happened with X or change-monitoring workflows.' It implies appropriate contexts but does not explicitly exclude alternatives or mention when not to use, missing full comparative 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?

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 ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), and implies it's for session-scoped data. It lacks details on error handling or rate limits, but covers essential behavior 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 front-loaded with the core purpose in the first sentence, followed by usage guidance and behavioral details in subsequent sentences. Each sentence adds value without redundancy, and the entire description is efficiently structured in just two sentences, making it 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 persistence rules), no annotations, and no output schema, the description does a good job covering purpose, usage, and key behavioral traits. It lacks details on return values or error cases, but for a tool with simple parameters and clear scope, it is largely complete and actionable.

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 both parameters ('key' and 'value') well-documented in the schema itself. The description does not add any meaningful semantic details beyond what the schema already provides (e.g., it doesn't explain key naming conventions or value formatting further), so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'forget' (deletion) and 'recall' (retrieval). It provides concrete examples of what can be stored ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous and differentiated.

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

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

The description explicitly states when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), providing clear context for its application. However, it does not specify when not to use it or mention alternatives like 'recall' for retrieving stored data, which prevents a perfect score.

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 provides key behavioral details: it is a single call, accepts ticker/CIK/name, returns ticker/CIK/company name/resource URIs, and is read-oriented. However, it lacks information on error handling, ambiguous inputs, or required permissions, leaving gaps.

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 with no redundancy, front-loading the purpose and adding concrete details efficiently. 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?

Given moderate complexity and no output schema, the description covers purpose, usage, version, and return fields. It lacks details on error scenarios and output format structure, but is mostly complete for typical use.

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

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

Schema coverage is 100%, so parameters are already well-documented. The description adds examples (e.g., 'AAPL') and specifies version support for the type parameter, providing marginal extra value 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 the tool resolves an entity to canonical IDs across Pipeworx data sources in a single call, specifies the supported type (company) with concrete examples (ticker, CIK, name), and mentions it replaces multiple lookup calls, distinguishing it from sibling tools.

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

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

The description implies use when needing canonical IDs across multiple identifiers, notes version constraints (v1 only supports company), and positions it as replacing 2-3 lookup calls, but does not explicitly state when not to use or 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?

No annotations are provided, so the description carries full burden. It details the return fields (verdict, structured form, actual value with citation, percent delta) and mentions the data source. However, it does not disclose error handling, rate limits, or behavior for ambiguous claims.

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

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

Three sentences, front-loaded with purpose, each sentence adding distinct value (purpose, scope, output format and benefit). No unnecessary words.

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

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

For a single-param tool with no output schema, the description covers purpose, input examples, output fields, and domain constraints. It omits details like pipeline behavior for unsupported claims or citation format, but 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 coverage is 100% with a good description for 'claim'. The tool description reinforces the claim format with examples but does not add new parameter-specific details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool fact-checks natural-language claims, specifically for company-financial data via SEC EDGAR+XBRL. It distinguishes from siblings by highlighting it replaces multiple sequential agent calls and is a specialized validation tool versus general entity/profile 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 indicates when to use (financial claims about revenue/net income/cash for public US companies) and that it replaces multi-step alternatives. It lacks explicit when-not-to-use guidance for unsupported claim types, but the scope is clearly defined.

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