Twilio

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

Without annotations, the description carries the full burden. It clearly states that the tool internally picks the right tool and fills arguments, which is a key behavioral trait. However, it doesn't disclose potential latency, error handling, or data source limitations. The 5 is missed because it doesn't mention what happens if no data source is available.

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

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

The description is extremely concise: three sentences plus examples. Every sentence adds value, no filler. Front-loaded with the core purpose, followed by behavioral insight, then usage guidance via examples.

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 low complexity (single required parameter, no output schema), the description is mostly complete. It explains what the tool does, how it works, and when to use it. Missing details about output format or error cases, but the examples compensate. A 5 would require a brief note on return format.

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

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

Schema coverage is 100% with a single 'question' parameter described as 'Your question or request in natural language.' The description reinforces this with examples but adds no extra semantic details about parameter constraints or formats, so 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's purpose: answering plain English questions using the best available data source. It emphasizes abstraction over browsing tools, with concrete examples like 'What is the US trade deficit with China?' that differentiate it from sibling tools like discover_tools.

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

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

The description explicitly tells the agent when to use this tool ('just describe what you need') and when not to ('No need to browse tools or learn schemas'). It also provides multiple examples covering diverse use cases, guiding selection over more specific tools like twilio_send_sms.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds detailed behavioral context: it resolves the market, classifies the bet, fans out to appropriate packs, and returns an evidence packet with model comparison. Missing specifics like rate limits or data freshness, but adds significant value beyond annotations.

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

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

The description is concise (4 sentences) and well-structured: starts with purpose, then inputs, then process, then use cases. Every sentence adds value with 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 2 parameters, no output schema, and annotations present, the description covers purpose, inputs, process, and use cases thoroughly. It lacks potential details like rate limits or data source specifics, but overall provides sufficient context for correct tool 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%. The description adds meaning beyond the schema by explaining the 'depth' parameter (quick vs thorough behavior) and elaborating on the 'market' parameter inputs. This helps the agent understand parameter implications.

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 using Pipeworx data. It specifies exact inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). This is specific and distinguishes from sibling tools like ask_pipeworx which are more generic.

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

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

The description provides explicit use cases ('should I bet on X?', 'is there edge in this bet?'). However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which would improve clarity.

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 full burden. It lists returned metrics for each type and mentions 'paired data + pipeworx:// resource URIs', but does not disclose safety, auth requirements, or side effects. Provides basic behavioral info.

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

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

Three concise sentences, front-loaded with the core purpose. Every sentence adds value: main action, per-type details, and efficiency benefit. 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?

For a tool with no annotations and no output schema, the description covers the main behavior, input constraints, and output hints. Could be more explicit about the return format structure, but adequately informs 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% with clear descriptions. The description adds value by specifying the exact metrics returned for each 'type' and the URI format, going beyond the schema's parameter definitions.

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

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

Clearly states the tool compares 2–5 entities side by side, with distinct metrics for 'company' and 'drug' types. Distinguishes from siblings like 'resolve_entity' by offering bulk comparison and replacing sequential calls.

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

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

Explicitly says 'Replaces 8–15 sequential agent calls', indicating when to use for efficiency. Does not explicitly state when not to use, but the context implies it is for multi-entity comparison rather than single lookups.

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

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

No annotations are provided, but the description discloses the search behavior and result format (names and descriptions). It does not detail potential performance implications or edge cases (e.g., empty results), but the core behavior is clear.

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 providing essential information: what the tool does, what it returns, and when to use it. No wasted words.

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

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

Given no output schema, the description could mention return format details (e.g., ranked list, includes IDs). However, the context of 11 sibling tools and the clear usage guideline make it sufficient for an agent to use correctly. The limit parameter is documented in the schema, so it's fine.

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

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

Schema coverage is 100%, so the schema already documents both parameters well. The description adds value by explaining the query parameter's use as 'natural language description' and provides examples like 'analyze housing market trends', which goes beyond the schema's generic 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 explicitly states 'Search the Pipeworx tool catalog by describing what you need' and 'Returns the most relevant tools with names and descriptions,' clearly identifying the action and resource. It also distinguishes itself from sibling tools by being a meta-tool for discovery, not a domain-specific 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?

The description provides explicit guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This tells the agent exactly when to use it and implies that other tools are for specific tasks after discovery.

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

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

With no annotations, the description carries the full burden. It describes the data returned (SEC filings, revenue/income, patents, news, LEI) and that it returns citation URIs. It implies a batch operation but doesn't cover rate limits or error handling. Still, it's reasonably transparent.

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 packed with information but not overly verbose. Each sentence adds value. Could be slightly more concise, but it's well-structured with clear front-loading.

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 return content (list of data categories and citation URIs). It mentions an alternative tool for federal contracts. However, it doesn't specify output format structure, but given tool complexity, it's still fairly 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%, and the description adds significant meaning beyond the schema by explaining valid values for type (only company) and value (ticker or CIK, not names), plus guiding to resolve_entity for names.

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

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

The description clearly states the tool returns a full profile of an entity across multiple data sources, specifies the only supported type (company), and gives examples of valid values (ticker or CIK). It distinguishes itself from siblings like resolve_entity 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?

Explicitly says when to use (full profile in one call) and when not to use (for federal contracts, use usa_recipient_profile). Also advises to use resolve_entity if only a name is available, providing clear 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 must disclose behavior. It correctly indicates the tool deletes data, but does not mention side effects (e.g., permanent deletion, error handling for non-existent keys) or authorization needs. The description is minimal but not contradictory.

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, 6 words, which is concise and front-loaded. However, it lacks additional context that might be useful (e.g., 'Note: this action cannot be undone').

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 deletion tool with one parameter and no output schema, the description is adequate but minimal. It does not explain what happens on success/failure, nor does it mention that deletion is irreversible. Given the tool's simplicity, this is acceptable but not exemplary.

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 'key' described as 'Memory key to delete'. The description does not add beyond the schema, but the schema is sufficient. Since coverage is high, baseline 3 is appropriate; a slight bonus is given for clarity of the parameter purpose.

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 the resource ('a stored memory by key'). It distinguishes the tool from siblings like 'remember' (create) and 'recall' (read), but does not explicitly differentiate from other deletion-like tools, though none appear to exist.

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

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

No guidance is provided on when to use this tool versus alternatives. For instance, it does not mention that the key must exist before deletion or suggest verifying existence with 'recall' 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 are provided, so the description carries the burden. It discloses the rate limit, free nature, and content restrictions. It lacks details on storage or response, but for a simple feedback tool, this 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 two sentences, with the purpose front-loaded and details following. Every sentence contributes essential information without redundancy.

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

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

Given the tool's simplicity (three parameters, no output schema), the description covers purpose, usage constraints, rate limits, and content guidelines comprehensively. No additional context is needed.

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

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

Schema description coverage is 100%, but the description adds value by elaborating on the type enum values and clarifying the context object's role. The message length limit (2000 chars) is also in the schema.

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

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

The description clearly states the tool sends feedback to the Pipeworx team, enumerating specific use cases (bug reports, feature requests, missing data, praise). It distinguishes itself from sibling tools which are unrelated (e.g., ask_pipeworx, discover_tools).

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

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

The description specifies when to use (for feedback) and provides guidance on content (describe what you tried, avoid end-user prompt) and rate limits. It does not explicitly state when not to use, but siblings provide no direct alternative for feedback.

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 and openWorldHint, covering safety and dynamic data. The description adds value by detailing the internal logic (walking child markets, extracting dates, sorting, checking inequalities) and the return format, going 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 a single paragraph but well-structured: purpose, rationale, usage, internal steps, output. Each sentence adds value, though it could be slightly more concise. 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 the moderate complexity of the tool and the simple schema, the description adequately explains the algorithm, input, and output format. It does not cover edge cases (e.g., no child markets), but overall it is sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with a clear description of the 'event' parameter. The description reinforces the input format with an example but does not add substantial new meaning beyond what the schema already provides.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations, with a detailed explanation and example. It distinguishes from siblings like 'polymarket_edges' by focusing specifically on monotonicity-based arbitrage within a single event.

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 on when to use the tool (when wanting to detect arbitrage via monotonicity by passing an event slug/URL). It does not explicitly list alternatives or when not to use it, but the context is sufficient for an agent to decide.

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

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

Annotations already mark read-only and open-world. The description adds significant behavioral detail: it scans top markets, groups by asset, fetches price history once, computes model probability, ranks by |edge|. It also notes it's V1 and covers only crypto-price bets, providing transparency about limitations. No contradiction with annotations.

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

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

The description is front-loaded with the main purpose and each sentence adds value (purpose, process, output). It is slightly verbose but not excessive. A concise summary of a complex tool; could be trimmed slightly but still 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?

Despite no output schema, the description specifies return structure: 'top N ranked by edge magnitude with suggested trade direction.' It covers how the tool works internally, its data sources, and its limitations (V1, crypto only). Sufficient for an agent to understand when to use it.

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 three parameters. The description does not add meaning beyond the schema: it repeats defaults and max values already present. Baseline 3 is appropriate as 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 scans high-volume Polymarket markets and returns those where Pipeworx data disagrees most with market price. It specifies the domain (crypto-price bets), the model (lognormal from FRED + coinpaprika), and the output (top N by edge magnitude with trade direction). This is a specific verb+resource that distinguishes 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 explicitly states the tool is built for the 'what should I bet on today' question, indicating when to use it. It contrasts with manually paging through hundreds of markets. However, it does not mention when not to use it or explicitly reference alternatives like polymarket_arbitrage, so it lacks exclusions.

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

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

No annotations provided, so description must bear burden. States listing behavior when key omitted, but doesn't detail side effects or persistence 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?

Two sentences, clear and front-loaded. Every part 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?

Adequate for a simple retrieval tool with optional parameter. No output schema needed given simple return type implied.

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

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

Schema coverage is 100% and description adds meaning: explains purpose of omitting key (list all) vs specifying it.

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

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

Clearly states it retrieves a memory by key or lists all memories. Distinguishes from 'remember' and 'forget' siblings.

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

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

Provides some guidance on when to use (retrieve context), but does not explicitly mention when not to use or alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the parallel fan-out, accepted date formats, and return type (structured changes, count, URIs). It does not discuss destructive actions or authentication, but for a read-like tool, this is adequate. The mention of 'in parallel' adds 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 4-5 sentences, front-loaded with the core purpose, then providing specific details about sources, date formats, and return structure. No filler or 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 no output schema, the description adequately describes the return (structured changes, total_changes count, pipeworx:// URIs). It explains the inputs and behavior well. However, it could be more precise about the structure of 'structured changes' or include edge cases (e.g., what if no changes?).

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the date format (ISO or relative) with examples, and that 'type' is currently limited to 'company'. It also gives a concrete example for 'value' ('AAPL'). This goes beyond the schema descriptions.

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

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

The description clearly states the verb ('what's new'), the resource ('entity'), and the time window. It specifies the fan-out to multiple sources (SEC, GDELT, USPTO), which distinguishes it from sibling tools like entity_profile (static profile) and compare_entities (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 explicit use cases ('brief me on what happened with X', change-monitoring workflows'). However, it does not mention when not to use it or alternatives like entity_profile for static data. The context is clear but lacks exclusions.

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

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

With no annotations, the description carries the full burden. It discloses persistence behavior ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which is useful. However, it does not mention limits on memory size, key uniqueness, or whether overwriting is allowed, leaving some behavioral 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 three sentences, each adding value: first defines the action, second explains usage, third clarifies persistence. No wasted words, front-loaded with the core purpose.

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

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

Given the tool's simplicity (2 string params, no output schema, no annotations), the description is nearly complete. It covers purpose, usage, and persistence. A slight gap is the lack of mention of overwrite behavior or memory limits, but it's sufficient for most agents.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond what the schema provides (e.g., 'key' and 'value' are already described). It does not elaborate on format constraints or usage tips, but the schema is sufficiently clear.

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 ('store'), the resource ('key-value pair in session memory'), and the purpose ('save intermediate findings, user preferences, or context across tool calls'). It distinguishes from siblings like 'forget' and 'recall' by focusing on storage.

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 says 'Use this to save intermediate findings, user preferences, or context across tool calls', providing clear usage context. It does not explicitly exclude other tools, but the purpose is specific enough that an agent can infer when to use it (e.g., not for retrieving or deleting).

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 full weight. It discloses that the tool returns canonical IDs and URIs, but does not mention authentication, rate limits, or whether the operation is read-only (though likely). More detail on behavioral traits would strengthen 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 two sentences with zero waste. The first sentence states the core purpose, the second provides specific details on inputs and outputs, making it efficient and front-loaded.

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

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

Given the simplicity of the tool (2 parameters, no output schema), the description covers return values and input formats well. However, it lacks details on error handling or edge cases, which for a lookup tool is acceptable but not fully comprehensive.

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

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

With 100% schema description coverage, baseline is 3. The description adds significant value by explaining that 'value' can be a ticker, CIK, or company name and provides concrete examples, going beyond the schema's generic 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 resolves an entity to canonical IDs across Pipeworx data sources, with specific input formats (ticker, CIK, name) and outputs (ticker, CIK, company name, URIs). It distinguishes itself by noting it replaces 2–3 lookup calls, setting it apart 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 provides explicit when-to-use context (entity resolution) with examples of inputs (AAPL, CIK, name). It implies it is for lookups rather than other tasks, but does not explicitly state when not to use or mention alternatives among siblings, which are mostly unrelated.

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 bears full responsibility. It states 'Get details', implying a read-only operation, but does not mention any side effects, rate limits, or required permissions beyond the auth tokens in the schema. Lacks depth but does not contradict any annotations.

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

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

The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words.

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

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

Given the simplicity of the tool (3 parameters, no output schema), the description is adequate. It covers the basic purpose, but could mention that the response contains message details (since no output schema exists) or that the SID is required.

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 each parameter has a description in the schema. The tool description adds no additional parameter information beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('get details') and the resource ('a specific Twilio message by its SID'). It is specific and informative, though it does not explicitly distinguish from sibling tools like twilio_list_messages.

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

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

No guidance on when to use this tool versus alternatives. It does not mention that the user needs the message SID or that it is for retrieving a single message, which could be inferred, but no explicit when-to-use or when-not-to-use advice 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?

Annotations are empty, so description carries full burden. It states the tool lists 'recent' calls, implying a time-based default, and mentions returned fields. However, it does not clarify if the tool is read-only, whether authentication parameters are required each call, or any rate limits. The lack of contradiction with annotations (which are empty) means no penalty.

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

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

Two sentences efficiently convey purpose and return fields. No unnecessary words, but could be slightly more structured (e.g., separate purpose and output).

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

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

For a simple list tool with no output schema, the description covers core purpose and output fields. However, it omits details like pagination, default ordering, and whether 'recent' is based on date. Sibling tools and context signals suggest moderate complexity, so a bit more detail would help.

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. The description adds no further meaning beyond the schema (e.g., does not explain the 'limit' parameter's effect or how to use account SID/token). Baseline 3 is appropriate since schema already documents 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 action ('List recent phone calls'), resource ('from your Twilio account'), and key return fields ('call SID, status, duration, and direction'). It distinguishes from sibling tools like twilio_make_call and twilio_list_messages by focusing on listing 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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools exist for sending SMS or making calls, but no criteria (e.g., need to filter vs. list all) are mentioned.

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 burden. It discloses filtering and pagination behavior but does not mention authentication requirements (though account SID and auth token are required params, not explained in description), rate limits, or default/max limits. The default limit of 20 and max 100 are stated in the schema but not in the description.

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 main purpose. It is concise and clear, though it could benefit from a brief note on required authentication parameters.

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 has 5 parameters, no output schema, and no annotations, the description is somewhat complete but lacks details on authentication (though params indicate), response format, and error handling. It is adequate for a simple listing tool but could be more comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by mentioning 'filtering by to/from number' and 'pagination', which maps to the 'to', 'from', and 'limit' parameters, but does not add new meaning beyond the schema.

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

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

The description clearly states the verb 'List' and resource 'SMS/MMS messages from your Twilio account', and distinguishes from sibling tools like twilio_send_sms (sending) and twilio_get_message (single message) by specifying 'list' and mentioning filtering and pagination.

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 usage for listing messages with filtering by to/from and pagination, but does not explicitly state when not to use it (e.g., for sending messages) or name alternatives directly. However, the sibling tool names provide 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 provided, so description carries full burden. It discloses the need for TwiML URL and account/auth parameters, but doesn't mention side effects (cost, phone network delays), rate limits, 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?

Two sentences, front-loaded with action and requirement. Efficient and clear.

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 5 parameters, all required, and no output schema, description is adequate but could include info about call status responses or how to retrieve call results. Lacks guidance on async nature.

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 value by explaining that 'url' is a TwiML URL controlling call behavior, and 'from' is a Twilio phone number, which clarifies purpose beyond the schema's basic 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?

Description clearly states the action (initiate a phone call), the resource (via Twilio), and adds key requirement (TwiML URL or application SID). Distinct from sibling tools like twilio_send_sms (SMS) and twilio_list_calls (list).

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 implies it's for making calls, but does not explicitly state when to use this tool versus alternatives like twilio_send_sms. No guidance on prerequisites or alternatives.

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

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

With no annotations, the description partially discloses behavior: it sends an SMS and returns the SID and status. However, it does not mention potential side effects (cost, delivery delays), rate limits, or failure modes (e.g., invalid numbers). Annotations are absent, so the description carries full burden and could be more detailed.

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

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

The description is concise at one sentence plus a return value note. It is front-loaded with the action. However, it could be slightly more informative without being verbose.

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 has 5 parameters (all required) and no output schema, the description is somewhat complete but lacks context about authentication requirements, character limits, or error handling. The sibling tools list includes twilio_get_message, which could be compared, but no guidance is given.

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 description adds minimal value beyond the schema. It mentions the return value but does not explain parameter details like body character limit or E.164 format beyond what the schema already provides. 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 action ('Send an SMS message'), the resource ('via Twilio'), and the return values ('message SID and status'). It distinguishes from siblings like twilio_make_call and twilio_get_message, but could be more specific about which sibling tools are related.

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

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

No guidance is provided on when to use this tool versus alternatives like twilio_list_messages or when not to use it (e.g., for sending to international numbers). The description does not mention prerequisites like having a Twilio account with SMS capabilities.

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 fully discloses behavior: returns verdict, structured form, actual value with citation, and percent delta. It also notes the tool replaces 4-6 agent calls. Does not mention potential errors or rate limits, but covers key aspects.

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

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

Two succinct sentences convey purpose, scope, outputs, and benefits without redundancy. Front-loaded with key 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?

Description is complete given tool complexity: defines domain, sources, verdict types, output structure, and efficiency gain. No output schema, but description adequately explains return values.

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% for the single parameter. Description adds value with examples and clarifies format (e.g., 'Natural-language factual claim, e.g., ...'), going 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?

Description states specific verb ('fact-check'), resource ('natural-language claim'), domain ('company-financial claims'), and sources ('SEC EDGAR + XBRL'), clearly distinguishing from sibling tools like ask_pipeworx 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?

Description provides clear context: use for company-financial claims and mentions it replaces sequential agent calls. However, it doesn't explicitly state when not to use or list alternative tools for other claim types.

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