Linear

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

The description discloses that the tool selects the best data source and fills arguments, which is behavioral. No annotations are provided, so the description carries the full burden. It does not mention any side effects, authorization needs, or rate limits, but the tool appears to be read-only and non-destructive, which is inferred.

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

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

The description is concise (two sentences plus examples) and front-loaded with the core purpose. Every sentence adds value. The examples are helpful but add length; still appropriate for clarity.

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

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

Given the simple input schema (one string parameter), no output schema, and no annotations, the description is largely complete. It explains the tool's behavior and provides examples. It could mention that results are returned as text, but that is 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?

The input schema has 100% coverage with a single 'question' parameter described as 'Your question or request in natural language'. The description adds context by specifying 'in plain English' and providing examples, but the schema already conveys the essential meaning. Baseline of 3 is appropriate.

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

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

The description clearly states that the tool answers natural language questions by selecting the appropriate data source and filling arguments. It specifies the verb ('Ask'), the resource ('Pipeworx'), and distinguishes it from sibling tools that are more specific (e.g., linear_* 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 usage guidance: 'No need to browse tools or learn schemas — just describe what you need.' It gives examples of appropriate questions. However, it does not explicitly state when not to use this tool or mention alternatives.

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

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

Annotations mark readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds behavioral details: resolves market, classifies bet, fans out to packs, returns comparison. No contradictions, and description adds substantial context 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?

Single dense paragraph that front-loads the core action, then details inputs, processing, output, and use cases. Every sentence adds value, though could be slightly more structured for quick scanning.

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 (multi-step research, fan-out) and no output schema, the description adequately explains the output format (evidence packet + comparison). Coverage is sufficient for an agent to understand what to expect.

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. The tool description adds default for depth (thorough) and examples for market, which enriches parameter understanding beyond schema alone.

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

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

Clearly states the tool researches Polymarket bets by pulling Pipeworx data. Specifies input types (slug, URL, question text) and output (evidence packet + market-vs-model comparison). Distinguishes from sibling tools by focusing on bet-specific context.

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

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

Provides explicit use cases ('should I bet on X?', 'what does the data say?', 'is there edge?') and notes it's the core demo product. Lacks explicit when-not-to-use or alternatives, but usage is well implied.

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

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

No annotations provided, so description carries full burden. Discloses that it returns paired data and resource URIs, and specifies data sources (SEC EDGAR for companies, FDA for drugs). Does not mention any destructive side effects, which is appropriate for a comparison tool.

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

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

Three concise sentences, front-loaded with purpose and supported by specifics. Every sentence adds value; 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?

Despite lacking output schema, description explains the output nature (paired data + resource URIs). Covers parameters, use cases, and benefit (efficiency). Complete for a straightforward comparison tool with two parameters.

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

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

Schema coverage is 100%. Description adds significant meaning beyond schema: explains the 'type' enum values with context (company metrics vs drug metrics), and clarifies the 'values' format (tickers/CIKs for companies, drug names). This helps the agent construct valid inputs.

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

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

Clearly states verb 'compare' with specific resource '2–5 entities side by side'. Distinguishes from siblings by mentioning it replaces 8–15 sequential calls, implying efficiency over repeated individual lookups. The two entity types (company, drug) and their specific metrics are explicitly listed.

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

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

Tells when to use: when needing side-by-side comparison of company or drug entities. Mentions it replaces sequential calls, indirectly pointing to alternatives. Does not explicitly state when not to use, but context is clear enough.

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

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

Although no annotations are provided, the description clearly states the tool's behavior: it searches a catalog and returns tool names and descriptions. It does not reveal performance characteristics (e.g., search algorithm, indexing) but adequately describes the core function and typical usage scenario.

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 at two sentences, front-loads the action and resource, and every sentence adds value. The first sentence states what it does, and the second sentence explains 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 the tool's complexity (simple search, 2 params, no output schema), the description is complete: it explains what it does, when to use it, and what it returns. The schema covers parameter details, so no further elaboration 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?

The input schema has 100% coverage with descriptions for both parameters. The description adds value by explaining the return type ('names and descriptions') and giving example queries, which helps the agent formulate effective queries. However, it does not add significant new meaning beyond the schema's parameter 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 uses specific verb+resource ('Search the Pipeworx tool catalog') and clearly distinguishes from siblings by stating 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This makes its purpose unique among sibling tools like ask_pipeworx or linear_search.

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 when to use it and implies it's a preliminary step, distinguishing it from direct-action tools like linear_create_issue.

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 thoroughly explains return data, supported types (company only), and citation URIs, setting accurate expectations.

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 about 5 sentences, front-loaded with the main purpose, and each sentence provides 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 complexity and lack of output schema, the description fully explains what is included, limitations, and alternatives, making it complete for agent decision-making.

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?

While schema coverage is 100%, the description adds significant value by explaining that 'value' can be ticker or CIK, that names are not supported, and that only 'company' type is available, enriching agent understanding.

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

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

The description clearly states it returns a full profile of an entity across multiple Pipeworx packs, listing specific data types (SEC filings, XBRL, patents, news, LEI) and 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?

It explicitly notes when not to use this tool (for federal contracts, call usa_recipient_profile) and implies using resolve_entity first if only a name is available, providing clear alternatives and context.

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

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

No annotations are provided, so the description must disclose behavioral traits. It confirms deletion (a destructive operation) but does not mention irreversibility, error handling, or authorization requirements. 'Delete' implies mutation, but the agent needs more 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 sentence with 6 words, no redundancy, and front-loaded verb 'Delete'. Every word earns its place.

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 (1 required param, no output schema, no annotations), the description is adequate but could mention that deletion is irreversible or that the key must exist.

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 required parameter 'key' described as 'Memory key to delete'. The description adds minimal extra meaning, but the schema already provides full coverage, so a baseline of 3 is adjusted up slightly because the description reiterates the parameter's 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 uses a clear verb 'Delete' with a specific resource 'stored memory' and the qualifier 'by key', distinguishing it from sibling tools like 'remember' (store) and 'recall' (retrieve).

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

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

The description implies usage for deletion but provides no guidance on when to use it versus alternatives (e.g., 'recall' to read, 'remember' to store) or any prerequisites or consequences.

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 explicitly states that it creates a new issue (write operation) and returns specific fields. Since annotations are empty, the description adequately conveys the behavioral trait that this is a creation tool, but does not mention any destructive behavior or side effects (which are not expected).

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

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

Two concise sentences that front-load the core purpose and key result. No wasted words.

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

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

Given the tool is a simple creation action with a well-defined schema and no output schema, the description covers the essential purpose and return value. It could mention more about optional parameters like priority or description, but the schema already provides that detail.

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 mentioning the return fields, which helps infer parameter importance. However, it does not add meaning beyond what the schema already provides for each parameter, but the return context compensates slightly.

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 (create), resource (issue), and tool (Linear). It also specifies what is returned (ID, identifier, title, URL), making it easy to distinguish from sibling tools like linear_get_issue or linear_list_issues.

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

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

The description implies usage for creating issues but provides no guidance on when to use this tool versus alternatives like linear_get_issue or linear_search. No explicit when-not or context about prerequisites 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 the description carries the full burden. It discloses that the tool returns 'full issue details' and lists the fields included (title, description, state, priority, assignee, labels, comments). This provides good transparency about the response content, though it does not mention whether the tool is read-only or any side effects.

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

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

The description is concise with two sentences: the first states the core purpose, the second lists the returned fields. No wasted words.

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

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

Given the tool is a simple lookup with one parameter and no output schema, the description provides sufficient information for an agent to select and invoke the tool. It lists the key fields returned, which compensates for the lack of output schema. However, it could mention if the tool requires authentication or any rate limiting.

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 coverage is 100% with a single parameter 'id' described as 'Issue identifier (e.g., "ABC-123")'. The description restates the same example, adding no new semantic meaning beyond the schema.

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

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

The description clearly states the verb 'Get' and the resource 'a single Linear issue by its ID', and includes the specific ID format 'ABC-123'. It distinguishes from sibling tools like linear_list_issues (which lists multiple) and linear_create_issue (which creates).

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

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

The description implies usage when a specific issue ID is known, but does not explicitly state when not to use it (e.g., for searching by other criteria, use linear_search instead) or mention alternatives.

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

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as pagination behavior beyond 'first' parameter, rate limits, ordering, or whether results are truncated. The description only lists return fields, lacking operational 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 a single concise sentence that front-loads the main action and lists return fields. No wasted words, but could be slightly more structured with separate lines for parameters and returns.

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 params, no output schema), the description is mostly adequate but lacks behavioral transparency (pagination, defaults beyond 'first', ordering). The return fields are covered, but no details on empty results or error conditions.

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 does not add meaning beyond the schema: 'first' and 'filter' are already explained. The description mentions 'optional filtering' but provides no additional context about filter syntax beyond the schema's JSON example.

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 lists issues from Linear with optional filtering, and enumerates the fields returned (ID, title, state, priority, assignee, URL). It distinguishes from siblings like linear_get_issue (single issue) and linear_create_issue (creation). However, it could more explicitly contrast with linear_search.

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

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

The description implies usage for listing with optional filters, but does not provide explicit guidance on when to use this tool versus alternatives like linear_search or linear_get_issue. No when-not-to-use or exclusion criteria 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?

The description states that the tool returns specific fields, which provides basic transparency. However, there are no annotations (e.g., readOnlyHint) to supplement this, and the description does not disclose any side effects, authorization needs, or limits. For a read-only list operation with no parameters, this is adequate but not exceptional.

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 with no wasted words. It is front-loaded with the action and resource, then lists the return values. Perfectly concise.

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

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

The tool is simple with no parameters and no output schema. The description covers the purpose and return fields completely. It could mention that this is a paginated list or that it returns all teams, but for a simple list operation, it is nearly 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?

The input schema has zero parameters and schema coverage is 100%, so the description does not need to explain parameters. The description adds value by listing the returned fields, which helps the agent understand the output without needing an output 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 'teams in the Linear workspace', and specifies the returned fields (ID, name, key, description). It is distinct from sibling tools like linear_create_issue or linear_list_issues, which operate on different resources.

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

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

The description implies this tool is for listing all teams without filters, and the lack of parameters confirms it requires no additional input. It does not explicitly mention when not to use it or compare with alternatives, but the context is clear given the zero-parameter schema and sibling tools that handle other tasks.

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 that it returns specific fields (ID, title, state, priority, URL) but does not mention whether the operation is read-only, any rate limits, or potential side effects. As a search tool, it is implicitly read-only, but this is not explicitly stated.

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

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

Two concise sentences that efficiently convey the tool's purpose and output. No redundant or wasted words.

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

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

Given the tool's simplicity (2 params, no output schema, no nested objects), the description is adequate but minimal. It covers the purpose and return fields, but could mention that results are paginated or sorted.

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 does not add meaning beyond the schema: it lists returned fields but does not elaborate on the 'query' parameter's syntax or the 'first' parameter's behavior beyond what's 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 action (search), the resource (Linear issues), and the method (by text query). It also lists the returned fields (ID, title, state, priority, URL), distinguishing it from siblings like linear_list_issues which likely lists all issues without text search.

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

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

The description implies usage for text-based search, but does not explicitly differentiate from other Linear tools like linear_list_issues or linear_get_issue. It lacks guidance on when not to use this tool 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?

No annotations provided, so description bears full burden. It discloses rate limiting (5 per day per identifier) and content guidelines. It lacks details on data handling or if feedback is anonymous, 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 concise with three sentences, each adding unique value: purpose, usage tips, and rate limit. Information is front-loaded and no words are wasted.

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 simple tool function, the description covers all necessary aspects: purpose, usage guidance, parameter semantics, and constraints. It is self-contained and leaves no critical 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 coverage is 100% with detailed enum descriptions. The description adds practical guidance on message length (1-2 sentences, 2000 chars) and specificity, as well as optional context examples, significantly enhancing understanding beyond schema.

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

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

The description clearly states it sends feedback to the Pipeworx team and lists explicit use cases (bug reports, feature requests, etc.). It effectively distinguishes from sibling tools like linear_create_issue by targeting Pipeworx team feedback.

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

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

The description explicitly says when to use (for feedback types) and what to avoid (no end-user prompt verbatim). It also mentions rate limits. While it doesn't explicitly name alternatives, the sibling context provides necessary differentiation.

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?

Adds details beyond annotations: walks child markets, extracts dates, sorts, reports violations. No contradiction with readOnlyHint/openWorldHint/destructiveHint.

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

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

Well-structured, explains concept and process in 3 sentences. Slightly wordy with example, but each 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?

With single param, high annotation coverage, and no output schema, description sufficiently explains input, logic, and output. No major 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?

Only one parameter 'event' with 100% schema coverage; description adds no extra semantic meaning beyond what 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?

Clearly states the verb 'find', the resource 'arbitrage opportunities within a Polymarket event', and the mechanism 'checking for monotonicity violations'. Distinguishes from sibling 'polymarket_edges'.

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

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

Explains when to use (monotonicity violations in events with multiple date/threshold markets) and provides example. Lacks explicit exclusions or comparison to siblings, but context is strong.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which align with the description. The description adds transparency about the underlying model (lognormal, FRED, coinpaprika) and output (ranked edges with trade direction). No contradictions.

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

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

The description is relatively concise for its complexity, covering purpose, model, and output in a few sentences. It front-loads the main action and is well-structured 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 has no output schema, the description adequately explains the return format (top N edges with edge magnitude and suggested direction). It covers the algorithm steps and data sources, making it complete for a data analysis 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?

All three parameters have schema descriptions, so coverage is 100%. The description does not add much beyond the schema; it restates defaults and constraints. Baseline score of 3 is appropriate since the schema already provides adequate semantics.

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

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

The description clearly states the tool's purpose: scanning high-volume Polymarket markets to find where Pipeworx data disagrees most with market prices. It specifies the model (lognormal from FRED and coinpaprika) and distinguishes from sibling tools like polymarket_arbitrage by focusing on edge discovery for betting decisions.

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 a clear use case: 'what should I bet on today' — discovering opportunities without manual browsing. It implies when to use, but does not explicitly state when not to use or list alternatives among siblings. Still, the context is well-defined.

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

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

No annotations are provided, so description carries full burden. It discloses that omitting key lists all memories, which is a key behavioral trait. However, it doesn't mention persistence across sessions or data format, but is adequate for a simple retrieval tool.

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

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

Two sentences, front-loaded with action. 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 retrieval tool with 0 required parameters and no output schema, the description is sufficient. It explains both retrieval modes and when to use.

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

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

Schema coverage is 100% with one parameter 'key' described. The description adds context: omitting key lists all memories, which goes 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 retrieves a memory by key or lists all memories when key is omitted. This distinguishes it from 'remember' (write) and 'forget' (delete) 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 says to use this for retrieving context saved earlier, implying when to use. It does not explicitly contrast with alternatives like 'ask_pipeworx' or 'discover_tools', but given sibling names, the purpose 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?

No annotations provided, so description fully bears burden. It explains parallel fan-out, input formats (ISO/relative), return structure (structured changes, count, URIs). Lacks details on error handling, rate limits, but sufficient for typical use.

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

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

Single, dense paragraph. Front-loaded with purpose, then behavior, input, return, use case. No superfluous 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 complex tool with 3 params, no output schema, and no annotations, description covers fan-out, input formats, and return structure. Minor gaps: no pagination or error handling, but overall adequate for tool 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?

Schema coverage 100%, but description adds value: explains 'since' syntax (ISO/relative) and typical default, confirms 'type' only supports 'company', and gives examples for 'value' (ticker or CIK).

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's purpose: 'What's new about an entity since a given point in time.' It details behavior for company type, including fan-out to SEC EDGAR, GDELT, USPTO. This distinguishes it from sibling tools like entity_profile or compare_entities.

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

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

Explicit usage guidance: 'Use for brief me on what happened with X or change-monitoring workflows.' Clear context but does not mention when not to use or alternatives, though siblings are available.

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

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

No annotations are provided, so the description carries full burden. It discloses persistence differences: authenticated users get persistent memory, anonymous sessions last 24 hours. This adds useful behavioral context beyond the input schema.

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

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

Three sentences, each adding distinct value: what it does, when to use, and behavioral nuance. No wasted words, front-loaded with 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 low complexity (2 simple params, no output schema), the description covers purpose, usage, and behavioral traits sufficiently. It does not explain return value, but that is acceptable as output schema is absent and the action is straightforward.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides. The schema examples for key and value are already 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 tool stores a key-value pair in session memory, with specific verb 'store' and resource 'key-value pair'. It distinguishes from siblings like 'recall' and 'forget' by defining the write operation for memory.

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

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

The description explains when to use it: to save intermediate findings, user preferences, or context across tool calls. It implies use over alternative tools like 'recall' or 'forget' but does not explicitly mention when not to use it or compare to siblings.

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

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

Describes behavior well: single call, only supports company in v1, accepts various input formats, returns specific fields and URIs. No annotations available, but lacks mention of idempotency, error handling, or read-only nature; however, the description is still quite informative.

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, no fluff. First sentence states action and benefit; second sentence details specifics. Front-loaded with 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?

For a tool with no output schema, the description adequately explains return values (ticker, CIK, name, URIs) and the context that it replaces multiple calls. No missing critical information given the tool's simplicity and sibling tool set.

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

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

Input schema has full description coverage, but the description adds valuable examples (ticker, CIK, name) and usage context (v1 only supports company), 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 'resolve an entity to canonical IDs' with specific input formats and outputs, distinguishing it from sibling tools like Linear tools or memory tools by noting it replaces 2-3 lookup 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 when to use: to get canonical IDs for a company in a single call, replacing multiple lookups. Implicitly tells agent to use instead of separate lookups, though no explicit 'when not to use' is needed given sibling tools are 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?

No annotations provided, so the description carries full burden. It discloses the return structure (verdict, structured form, actual value with citation, percent delta) and the data source (SEC EDGAR + XBRL). It does not cover potential side effects, auth needs, or rate limits, but for a read-only tool this is acceptable.

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

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

Three well-structured sentences: purpose first, then scope and output, finally context. No redundant 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?

The description covers purpose, scope, output, and replacement benefit. It lacks explicit error handling or edge case behavior but is sufficient for a simple single-parameter tool. Could mention what happens if claim is out of scope.

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 sole parameter 'claim' has 100% schema description coverage, including an example. The tool description adds further context by providing example formats and clarifying it is natural-language. This adds marginal value beyond the schema.

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

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

The description clearly states the tool fact-checks claims, specifies supported scope (company-financial claims for US public companies), and lists the verdicts returned. It distinguishes from siblings by explicitly replacing 4-6 sequential agent calls, highlighting its unique value.

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

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

The description indicates when to use (for fact-checking financial claims) and implies limitations by stating 'v1 supports company-financial claims' and 'public US companies'. However, it does not explicitly mention when not to use or compare with sibling tools beyond stating it replaces sequential calls.

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