swisstransport

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 core behavior: it interprets natural language questions, selects appropriate data sources, executes queries, and returns results. However, it doesn't mention potential limitations like response time, data freshness, or error conditions that would be helpful for complete 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 perfectly front-loaded with the core functionality in the first sentence, followed by clarifying benefits and concrete examples. Every sentence earns its place by either explaining the tool's value proposition or providing actionable usage guidance without any 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?

Given the tool's complexity (natural language processing with automated tool selection) and lack of both annotations and output schema, the description does an excellent job explaining what the tool does and how to use it. The main gap is the absence of information about return format or error handling, which would be helpful given the sophisticated functionality.

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 parameter 'question' is already documented. The description adds valuable semantic context by explaining this should be 'plain English' questions or requests, providing three concrete examples that illustrate the expected format and scope beyond what the schema provides.

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

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

The description clearly states the tool's purpose with specific verbs ('Ask a question', 'get an answer') and resources ('from the best available data source'), distinguishing it from siblings by emphasizing natural language processing and automated tool selection. It explicitly contrasts with sibling tools that require manual browsing or schema knowledge.

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') and includes three concrete examples illustrating appropriate use cases. This clearly differentiates it from alternatives that might require more technical interaction.

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, which the description respects. The description adds value by explaining the fan-out to specific data packs (e.g., crypto+fred+gdelt) and the return of an evidence packet plus market-vs-model comparison. It provides behavioral context beyond the annotations.

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

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

The description is relatively long but efficient. It front-loads the purpose, then details the process, usage, and value proposition. Every sentence adds information without redundancy. It could be slightly more concise, but it's well-structured.

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

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

Given no output schema, the description adequately explains the return format (evidence packet + market-vs-model comparison). For a tool with complex internal fan-out, the description covers the high-level behavior (resolving market, classifying bet, fanning out to packs) sufficiently to guide the agent.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds meaning by explaining the 'depth' parameter values ('quick = 2-3 evidence sources, thorough = full fan-out') and stating the default. It also clarifies the 'market' parameter with examples beyond the schema's 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 researches Polymarket bets by pulling Pipeworx data. It specifies input formats (slug, URL, question text) and outlines the internal process (resolves market, classifies bet, fans out to data packs, returns evidence packet + comparison). This distinguishes it from sibling tools like ask_pipeworx (general Q&A) and compare_entities.

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

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

The description explicitly provides usage cases: 'should I bet on X?', 'what does the data say...', 'is there edge?'. It does not explicitly state when not to use it, but the context makes it clear that it's specialized for Polymarket bets. It positions itself as the core demo product, implying it's the primary choice for bet research.

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, description provides some behavioral info: data sources (SEC EDGAR, FDA, trials) and output format (paired data + resource URIs). However, it does not disclose error conditions, 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?

Description is three sentences, front-loaded with purpose, no wasted words. It efficiently conveys the tool's function and benefits.

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

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

Given no output schema and two parameters, the description sufficiently covers what the tool returns, input requirements, and even notes the efficiency advantage, making it complete for agent selection.

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

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

Input schema covers both parameters fully (100%), but description adds extra value by specifying the exact metrics returned for each type (revenue, net income, etc.), enhancing understanding beyond the schema.

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

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

Description clearly states the tool compares 2-5 entities side by side, specifying verb and resource. It distinguishes from sibling tools which are for other tasks like asking, discovering, or resolving 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?

Description gives clear context for when to use (e.g., comparing companies or drugs in one call) and mentions efficiency gain over sequential calls, but does not explicitly state when not to use or list 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the search functionality and return format (tools with names and descriptions), but doesn't mention performance characteristics, rate limits, authentication requirements, or error handling. The description adds some context 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 perfectly concise with two sentences that each earn their place. The first sentence explains the core functionality, and the second provides crucial usage guidance. No wasted words, and the most important information (when to use it) is front-loaded in the second sentence.

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) and lack of annotations/output schema, the description does well by explaining the purpose, return format, and strategic usage. However, it could benefit from mentioning what happens when no tools match the query or how relevance is determined. The absence of an output schema means the description should ideally explain return values more thoroughly.

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

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

With 100% schema description coverage, the input schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the general purpose ('search by describing what you need') but provides no additional syntax, format, or semantic details about the parameters.

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 distinguishes this tool from its siblings (get_connections, get_stationboard, search_stations) by focusing on tool discovery rather than data retrieval or station-related 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 context about when to use this tool versus alternatives, including a specific threshold (500+ tools) and a strategic position (first).

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 the description carries the burden. It discloses that it returns pipeworx:// citation URIs and replaces many sequential calls. However, it does not explicitly state read-only nature or mention auth/rate limits, though these are implied.

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 dense single paragraph that front-loads the purpose and efficiently lists data sources, return format, and alternatives. While packed with information, it remains clear and avoids redundancy, though slightly longer than minimal.

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 the return values (pipeworx:// URIs). It covers all essential aspects: what data is included, the input constraints, and performance benefits. No missing critical context for an information 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?

Schema coverage is 100%, and the description adds significant context beyond the schema: explains that 'type' currently only supports 'company', and for 'value' clarifies ticker vs CIK formats, providing examples. It also steers agents away from unsupported input (names) and directs to an alternative tool.

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

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

The description clearly states the tool returns a full profile of an entity across relevant packs, with specific data sources listed. It distinguishes from sibling tools by noting an alternative for federal contracts and implying use of resolve_entity for name 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?

Explicitly states when to use (for full profile), when not to use (for federal contracts, use usa_recipient_profile), and mentions using resolve_entity if only a name is available. Provides clear exclusions and alternatives.

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

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

No annotations are provided, so the description carries full burden. It states 'Delete' implies a destructive mutation, but doesn't disclose whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting other data), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Delete') and resource, making it immediately understandable. Every word earns its place, achieving ideal conciseness.

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

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

Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial details like what 'Delete' entails (permanence, side effects), error conditions, or return values. The high schema coverage helps with parameters, but overall context for safe and effective use is insufficient.

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 the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this, merely restating 'by key'. Since the schema already fully describes the parameter, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given high 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 verb ('Delete') and resource ('a stored memory by key'), making the purpose unambiguous. It doesn't explicitly distinguish from sibling tools like 'recall' (which presumably retrieves memories) or 'remember' (which presumably stores them), but the action is specific enough to infer differentiation. A 5 would require explicit sibling comparison.

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., that a memory must exist to be deleted), exclusions, or comparisons to siblings like 'recall' or 'remember'. Without annotations, this leaves the agent guessing about appropriate contexts.

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 mentions that the tool 'Returns up to the requested number of next departures,' which gives some insight into output behavior (time-based, limited results). However, it lacks critical details like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what happens when locations aren't found—important for a tool that queries external data.

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 in two sentences. The first sentence states the core purpose, and the second adds key behavioral context about the return limit. There is no wasted language, and it's front-loaded with essential information, making it efficient for an agent 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 (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output behavior but lacks details on usage guidelines, error handling, or deeper behavioral traits. Without annotations or an output schema, more context would be helpful for reliable agent invocation, but it's not entirely incomplete.

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

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

The description adds minimal parameter semantics beyond the input schema. It implies the 'limit' parameter controls the number of connections returned ('up to the requested number'), but the schema already documents this with 100% coverage. No additional meaning is provided for 'from' or 'to' parameters, so the description doesn't compensate but doesn't detract either, meeting 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 tool's purpose: 'Get public transport connections between two Swiss locations.' It specifies the verb ('Get'), resource ('public transport connections'), and geographic scope ('Swiss locations'). However, it doesn't explicitly differentiate from sibling tools like 'get_stationboard' or 'search_stations' beyond the general domain.

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 tools 'get_stationboard' or 'search_stations'. It mentions the core functionality but offers no context about alternatives, exclusions, or specific use cases that would help an agent choose between these related transportation 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'live departure board' data, implying a read-only operation, but does not cover critical aspects like rate limits, authentication needs, error handling, or data freshness. This leaves significant gaps in understanding the tool's behavior and constraints.

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 that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly and understand 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?

Given the tool's moderate complexity (live data retrieval with two parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on return values, error cases, or operational context, which are important for a tool involving real-time data and sibling alternatives.

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, clearly documenting both parameters ('station' and 'limit') with their types and purposes. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.

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

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

The description clearly states the action ('Get') and resource ('live departure board for a Swiss public transport station'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_connections' or 'search_stations', which might also involve station or departure data, so it lacks sibling 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 like 'get_connections' or 'search_stations'. It implies usage for live departure information but offers no explicit context, exclusions, or comparisons to sibling tools, leaving the agent without clear selection criteria.

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 that the tool sends feedback, is rate-limited to 5 per day, and is free. Does not mention destructive actions or auth, but those are not relevant for feedback submission.

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 plus a note on rate-limiting. Front-loaded with the main action. Every sentence is necessary and informative. No wasted words.

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

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

For a simple feedback tool, the description fully covers purpose, usage, constraints, and parameter usage. No output schema is needed. Sibling tools are clearly different in function.

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

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

Schema coverage is 100% with descriptions for all parameters. Description adds extra guidance on how to write the message (include what was tried, avoid verbatim prompt). This complements the schema but does not dramatically expand parameter meaning.

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

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

The description clearly states 'Send feedback to the Pipeworx team' and lists specific use cases (bug reports, feature requests, missing data, praise). This distinguishes it from sibling tools like discover_tools or ask_pipeworx, which serve different purposes.

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

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

Explicitly states when to use (bug reports, feature requests, missing data, praise) and provides a negative guideline (do not include end-user prompt verbatim). Mentions rate-limit. Could be improved by explicitly stating when not to use, but given sibling context, it's clear.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description aligns with this by describing a read-only check. It adds behavioral details about walking child markets and sorting dates/thresholds, but does not address potential performance 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?

The description is concise (3-4 sentences) and front-loaded with the core purpose, followed by a clear explanation of the logic and output format. No extraneous 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 no output schema, the description fully specifies the return format (list of objects with market_a, market_b, gap_pp, suggested_trade). The input is thoroughly explained, and the tool's behavior is well-described for its complexity.

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

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

Schema coverage is 100% with one parameter. The description adds meaning by explaining how the event slug translates to market scanning and providing an example, going beyond the schema's short 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?

Clearly defines the tool's purpose as finding arbitrage via monotonicity violations in Polymarket events, with a concrete example. Distinguishes itself from siblings like 'polymarket_edges' and 'bet_research' by specifying the exact detection 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?

Explicitly states the input (event slug/URL) and the condition for arbitrage, providing a clear use case. However, it lacks explicit when-not-to-use or alternative scenarios, which would elevate it to a 5.

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

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

The description adds significant behavioral context beyond annotations: it details the algorithmic steps (scans top markets, groups by asset, fetches price history once, computes probability, ranks by edge), mentions data sources (FRED, coinpaprika), and notes that it returns top N edges with direction. This complements the readOnlyHint and openWorldHint annotations without contradiction.

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

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

The description is a single paragraph that efficiently conveys purpose, algorithm, output, and use case. While it is concise and front-loaded, it could be slightly more structured (e.g., separated sentences for algorithm steps) but remains effective.

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

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

Given the tool's complexity (ranking algorithm, multiple data sources) and lack of output schema, the description adequately explains inputs, processing steps, and outputs. It includes data sources and purpose, though it omits specifics on the return format (e.g., JSON structure). Still, it is sufficient for an agent to understand and invoke the tool.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds context by explaining that 'limit' returns top N edges after ranking and reinforces defaults/max. It does not significantly extend beyond schema but provides useful operational 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 clearly states the tool scans high-volume Polymarket markets, identifies discrepancies between Pipeworx data and market prices, and returns ranked edges with suggested trade direction. It distinguishes itself from siblings by explicitly targeting the 'what should I bet on today' question and automating discovery of opportunities.

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

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

The description explicitly states when to use the tool (for discovering betting opportunities, scanning top markets) and provides context for its purpose. However, it does not explicitly mention when not to use it or suggest alternative tools, which would be beneficial for clearer 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 the tool's dual functionality (retrieve by key vs. list all) and persistence behavior ('saved earlier in the session or in previous sessions'). However, it doesn't mention error handling (e.g., what happens if key doesn't exist) or performance characteristics like response format or limitations.

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 functionality, the second provides usage context. Every word earns its place, and the information is front-loaded with the core purpose stated immediately. No redundant or unnecessary information is present.

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 (dual functionality, session persistence) and lack of annotations/output schema, the description does well by covering purpose, usage, and parameter semantics. However, it doesn't describe the return format (what a 'memory' contains) or error conditions, which would be helpful for a retrieval tool with no output schema. The description is complete enough for basic use but has minor 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, so the baseline is 3. The description adds meaningful context by explaining the semantic effect of omitting the key parameter ('omit to list all keys'), which goes beyond the schema's technical description. This clarifies the tool's dual behavior based on parameter presence, adding significant practical value.

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

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

The description clearly states 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: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter ('omit key to list all keys'), which helps distinguish between retrieval modes. While it doesn't explicitly mention alternatives, the context of retrieving saved memories is clear.

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

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

With no annotations, the description carries the full burden. It discloses parallel fan-out, supported parameter formats, and output structure (structured changes + total_changes + URIs). It lacks details on rate limits, authentication, or error handling, but covers core behavior well.

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

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

Four sentences with no wasted words. Purpose is front-loaded, and every sentence provides critical information. Highly concise yet comprehensive.

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

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

Despite no output schema, the description explains return values. It also covers entity type limitations, parameter formats, data sources, and usage scenarios. For a tool with no annotations, this is exceptionally complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value: explains type enum (only 'company' supported), since format with examples, and value as ticker or CIK. This goes well beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time', with specific examples for company type including SEC EDGAR, GDELT, USPTO. This effectively differentiates from siblings like entity_profile which likely provides static profiles.

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 suggests use cases: 'brief me on what happened with X' or change-monitoring workflows. However, it does not mention when not to use it (e.g., for static profiles use entity_profile), so it loses one point.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains the storage mechanism (session memory), persistence differences between authenticated vs. anonymous users (24-hour limit), and the cross-tool context capability. It doesn't mention rate limits or error conditions, but covers the essential operational behavior.

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 front-loaded with the core purpose in the first sentence, followed by usage guidance and behavioral details. Every sentence earns its place with no wasted words, and the structure flows logically from what to why to how.

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

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

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description provides excellent context about memory behavior, persistence rules, and usage scenarios. It could potentially mention what happens on key collisions or retrieval mechanisms (though 'recall' is a sibling), but it's largely complete for this complexity level.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add meaningful parameter semantics beyond what's in the schema descriptions (which provide examples and usage guidance). Baseline 3 is appropriate when 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 verb+resource ('Store a key-value pair in your session memory') and distinguishes it from siblings by mentioning 'session memory' context. It goes beyond the name 'remember' to explain what kind of storage this provides.

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 ('to save intermediate findings, user preferences, or context across tool calls') and distinguishes it from alternatives by specifying the memory scope (session-based vs. persistent). It also mentions authentication implications for usage 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?

No annotations are provided, so the description must carry the behavioral burden. It discloses the return values (ticker, CIK, name, URIs) and input constraints. However, it does not describe error handling or behavior for unmatched entities.

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 primary action, and includes all essential information without extraneous words. Every sentence adds value.

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

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

For a simple lookup tool with two parameters and no output schema, the description covers the main aspects: input format, output content, and efficiency benefit. It lacks details on error cases or idempotency, but is otherwise sufficient.

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

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

Schema description coverage is 100%, but the description adds meaning by explaining the 'type' parameter's allowed value ('company') and providing concrete examples for 'value' (ticker, CIK, name). This goes beyond the schema's enum and type descriptions.

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

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

The description clearly states the tool resolves an entity to canonical IDs, specifies the supported type ('company'), and contrasts with alternatives by saying it replaces 2-3 lookup calls. The examples (ticker, CIK, name) further clarify the purpose.

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 (company entity resolution) and lists the input formats. It implies efficiency gains but does not explicitly state when not to use it or name alternative 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does (searching), but doesn't describe any behavioral traits like whether it's read-only, rate limits, authentication needs, what happens with partial matches, or the format of results. This is inadequate for a tool with zero annotation coverage.

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 that states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential 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 lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the search returns (e.g., list of stations, their details), how results are structured, or any behavioral context needed for effective use. For a search tool with no structured output documentation, this creates significant gaps.

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

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

Schema description coverage is 100%, so the schema already fully documents the single 'query' parameter. The description adds no 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: searching for Swiss public transport stations by name query. It specifies the resource (stations) and verb (search), but doesn't differentiate from sibling tools like get_connections or get_stationboard, which appear to serve different functions.

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 sibling tools or any context about when search_stations is appropriate versus get_connections or get_stationboard, leaving the agent without usage direction.

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 fully discloses the tool's behavior: it performs NL parsing, entity resolution, data lookup, and comparison, returns a verdict with citation and percent delta, and is limited to v1 company-financial claims. This is comprehensive and beyond minimal.

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

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

The description is two sentences, front-loading the core purpose and immediately detailing scope, outputs, and efficiency benefits. Every sentence adds value without redundancy, maximizing clarity in minimal space.

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 fully explains all return elements (verdict, structured form, actual value, citation, percent delta). It also covers scope and version limitations, making the tool's behavior completely understandable to 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?

The input schema has 100% coverage and describes the 'claim' parameter well. The description adds value by giving a concrete example (e.g., 'Apple's FY2024 revenue'), raising clarity slightly, but since schema already provides definition, 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, specifies supported domains (company-financial claims via SEC EDGAR+XBRL), and lists verdict types. It distinguishes itself from sibling tools by focusing on claim validation rather than general Q&A or entity lookup.

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 when to use the tool (fact-checking financial claims) and mentions that it replaces multiple sequential agent calls, implying efficiency. However, it does not explicitly state when not to use it (e.g., non-financial claims) or provide alternative tools, so not a 5.

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