Pipeworx Catalog

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

With no annotations provided, the description partially discloses behavior: it auto-selects data sources and fills arguments. However, it does not specify what data sources are available, privacy implications, or what happens if the tool cannot answer (e.g., error handling).

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

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

The description is very concise (4 sentences) and front-loaded with the main purpose. Every sentence adds value, including examples. No wasted words.

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

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

Given the tool's simplicity (1 parameter, no output schema) and no annotations, the description is largely complete. It covers purpose, usage, and examples. Could benefit from mentioning potential limitations or error cases, but overall adequate.

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, and the description adds value by explaining the parameter's purpose (natural language question) and providing examples. However, it does not add constraints or format details 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 takes a plain English question and returns an answer from the best data source. It explicitly differentiates from sibling tools by emphasizing natural language querying, contrasting with tools like discover_tools or get_platform_status that serve different purposes.

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

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

The description provides clear context on when to use this tool (for natural language questions) and gives examples. It implicitly suggests not to use other tools for such queries, but lacks explicit exclusions 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to state safety. It goes beyond annotations by disclosing that the tool resolves the market, classifies the bet into categories, and fans out to the appropriate data packs. This provides useful behavioral context without contradiction.

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

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

The description is front-loaded with the core action and is efficient overall, though it includes some promotional language ('core demo product ... convert better'). It is appropriately sized for the tool's complexity and every sentence adds value, but slight trimming would improve conciseness.

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

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

Despite lacking an output schema, the description explains that the tool returns an evidence packet plus a market-vs-model comparison, which gives a high-level understanding of the return value. It also conveys the workflow (resolve, classify, fan out) adequately for an agent to use the tool, though more detail on the evidence packet structure would be beneficial.

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

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

The input schema already has 100% coverage and describes both parameters clearly: market accepts slug, URL, or question text; depth is an enum with 'quick' and 'thorough' and defaults to thorough. The description essentially restates this, adding no new semantic meaning beyond the schema, so it meets the baseline but does not exceed.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, and it specifies multiple input forms (slug, URL, question text). It also describes the output (evidence packet plus market-vs-model comparison) and distinguishes itself from sibling tools by calling itself the 'core demo product' that automates complex discovery, making it highly specific and differentiated.

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

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

The description provides explicit use cases such as 'should I bet on X?', 'what does the data say about this Polymarket market?', and 'is there edge in this bet?'. It implies this tool should be used when needing bet-relevant context, but it does not explicitly state when not to use it or mention alternative tools, though the use cases are 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?

Without annotations, the description fully carries the burden. It discloses data sources (SEC EDGAR/XBRL, FAERS, FDA) and return content (paired data + citation URIs). It doesn't cover rate limits or performance implications, but the bulk nature is implied.

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

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

The description is structured with a clear purpose statement upfront, followed by type-specific details. It is slightly verbose but every sentence adds information. A minor trim would improve, 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?

Given no output schema, the description partially explains returns (paired data + citation URIs) but lacks detail on the exact structure of the paired data. For a comparison tool, this is acceptable as the agent can infer the format from the description of what is pulled.

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

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

Schema coverage is 100%, but the description adds significant value: examples of valid values for each type, the min/max from schema, and the mapping from type to data fields (revenue/net income for company, AE counts for drug).

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 starts with a specific verb ('Compare') and resource ('2–5 companies or drugs'), with explicit usage triggers like 'compare X and Y'. It distinguishes itself from siblings by noting it replaces 8–15 sequential agent calls, contrasting with single-entity tools like entity_profile.

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 provides clear when-to-use examples (user phrases like 'compare X and Y', 'vs', 'stack up') and explains the behavior for each type. While it doesn't list exclusions or alternatives by name, the context is strong enough for an agent to decide.

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

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

No annotations are provided, so the description carries full burden. It reveals that the tool searches by natural language and returns tool names and descriptions. It doesn't mention limitations or edge cases, but the purpose is well-scoped and the 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?

The description is extremely concise: three sentences that cover purpose, return value, and when to use it. No wasted words, and the most important information is front-loaded.

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

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

Given the tool's simplicity (2 params, no output schema, no nested objects), the description is nearly complete. It could optionally mention that results are ranked by relevance, but the current text is sufficient for an agent to use it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'query' parameter should be a natural language description with examples. This goes beyond the schema's generic description. The 'limit' parameter is also well-documented 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's purpose: 'Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions.' It specifies the action (search), the resource (tool catalog), and the result (relevant tools with names and descriptions). This distinguishes it from siblings like search_mcp_directory or list_packs, which target different catalogs or actions.

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 when to use the tool: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This provides clear guidance on usage context and priority relative to other tools.

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

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

Without annotations, the description lists the specific data returned (SEC filings, financials, patents, news, LEI) and citation URIs. Lacks mention of pagination or size limits, but still 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?

The description is a single dense sentence, but all sentences are purposeful. Could be slightly more structured, but it's 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 no output schema, the description thoroughly lists return types and references related tools, making it nearly complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds value by elaborating on the 'value' parameter (ticker/CIK) and advising on name resolution, going 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 it retrieves everything about a company in one call, using a specific verb and resource. It also distinguishes itself from siblings by mentioning it replaces calling multiple pack tools.

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

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

Explicitly provides example user queries that trigger this tool, and warns against using it with a name alone, directing to resolve_entity first.

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

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

No annotations provided, so description carries full burden. It confirms delete operation but lacks details on irreversibility, confirmation, or error handling (e.g., what if key doesn't exist).

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

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

Single, clear sentence with no extraneous words. Essential information 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?

For a simple 1-parameter tool with no output schema, the description is adequate but could mention side effects (e.g., permanent deletion) and error scenarios.

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

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

Schema coverage is 100%, and description does not add beyond 'key' parameter meaning. Baseline 3 is appropriate since schema already describes parameter.

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 (Delete), resource (stored memory), and identifier (by key). Distinct from siblings like 'recall' (retrieve) and 'remember' (store).

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 to delete a memory by key, implying use when removal is needed. No alternative tool for deletion exists among siblings, so no exclusion needed.

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

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

No annotations are provided, so the description must carry the full burden. It correctly indicates that the operation is a read/get (safe, non-destructive) and mentions the output formats. However, it does not disclose any side effects, rate limits, or authentication requirements, which are typical for config retrieval. The lack of behavioral depth beyond what's in the schema is acceptable 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 two sentences, front-loading the main purpose and then listing outputs. No wasted words; each 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is sufficiently complete. It covers what the tool does, the input format, and the output types. Minor gap: does not specify if the config includes authentication tokens or requires prior setup, but for a config retrieval tool this is acceptable.

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 parameter 'slugs' already described well in the schema. The description does not add additional meaning beyond the schema, but it correctly implies that 'all' is a special value. Baseline 3 is appropriate since the schema already 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 what the tool does: it retrieves MCP client config JSON for connecting to packs. It specifies the outputs (Claude Desktop config, Claude Code CLI command, gateway URL), making the purpose highly specific and distinguishable from siblings like 'get_pack_tools' or 'list_packs'.

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 when to use the tool (when you need connection config for packs) but provides no guidance on when not to use it or alternatives. Given sibling tools like 'get_pack_tools' or 'search_packs', the description could have differentiated use cases, but it does not.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns tool definitions, but does not mention any side effects, authorization needs, or rate limits. Since the tool is read-only and non-destructive, a score of 3 is reasonable.

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 concise sentences, front-loaded with purpose and followed by usage guidance. 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 has a simple input schema (one required string parameter) and no output schema, the description is complete enough for an agent to understand its purpose and when to use it. It lacks details on output format but since no output schema exists, that is acceptable.

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 the single parameter 'slug'. The description adds minimal extra meaning, merely restating that slug is a pack identifier. 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 retrieves full tool definitions for a specific pack, listing what is included (names, descriptions, parameters). It distinguishes itself from sibling tools like discover_tools or list_packs by specifying it returns tool definitions for a particular pack.

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 advises to use this tool before calling a tool to understand its interface, providing clear usage context. However, it does not mention when not to use it or suggest alternatives among siblings.

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

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

Annotations are empty, so description must cover behavior. It states the tool is non-destructive (reading health info) and provides a clear scope. No contradictions, but could mention that it requires no input and returns a snapshot.

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 sentence, no wasted words, front-loaded with verb and resource. Perfectly concise for a simple read operation.

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?

Tool has no params, no output schema, and is a simple health check. Description is sufficient for the agent to invoke correctly. Could specify return format, but not essential.

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 no parameters, so schema coverage is 100%. Description adds no param info beyond the schema, which is fine because there are none. 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?

Description clearly states the tool returns platform health information, listing specific data points (live packs, outages, degraded services, tool count). Verb 'get' plus resource 'platform status' is precise and distinct from sibling tools like 'get_pack_tools' or 'list_packs'.

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 explicit when-to-use or alternatives mentioned, but the tool's purpose is self-explanatory as a status check. Context signals show no parameters, making it straightforward. Sibling tools exist for more specific queries, but guidance is not strictly necessary.

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 bears full burden. It discloses the output includes slug, name, category, tool count, and gateway URL, and implies a read-only listing operation. However, it does not mention pagination, rate limits, or whether the list is exhaustive or limited.

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

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

The description is two sentences with no extraneous words. It front-loads the key action and result, then adds context. Every sentence is meaningful and 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 simple input schema (1 optional parameter), no output schema, and no annotations, the description adequately covers purpose, parameters, and return fields. It could mention if the result is paginated or if there are any restrictions, but for a listing tool, this 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?

Schema coverage is 100% with a single optional parameter 'category'. The description adds value by providing example categories and clarifying that the tool lists 'all available' packs, implying the category filter is optional. This goes beyond the schema's minimal 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 verb 'list' and the resource 'all available Pipeworx MCP packs', and specifies the fields returned (slug, name, category, tool count, gateway URL). It distinguishes this tool from siblings by positioning it as the 'master inventory' and describing usage for discovery by category.

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

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

The description gives a clear context ('master inventory') and a usage suggestion ('find packs by category or discover what data sources are available'), but does not explicitly state when not to use this tool or mention alternatives among siblings (e.g., search_packs or get_pack_tools).

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

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

Despite no annotations, the description discloses important behavior: rate limit of 5 per identifier per day, that it is free and doesn't count against quota, and includes guidance on writing effective feedback (e.g., describing in terms of tools/packs). This adds valuable transparency for the agent.

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

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

The description is concise and well-structured: it starts with the core purpose, then usage guidelines, then behavioral notes. Every sentence adds value, and there is no redundant information.

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

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

Given the tool's simplicity (no output schema, three parameters), the description covers usage, constraints, and impact. It could mention the immediate outcome of submitting feedback (e.g., confirmation), but the current level is sufficient for correct 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?

Although schema coverage is 100%, the description adds meaning by explaining each enum option (bug, feature, etc.) with context and provides advice on writing the message field (specific, concise). This goes beyond just listing parameters.

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

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

The description clearly states the tool's purpose: to give feedback to the Pipeworx team about bugs, missing features, data gaps, or praise. It uses specific verbs like 'tell' and 'describe' and distinguishes from sibling tools by focusing on feedback rather than other operations.

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

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

The description provides explicit when-to-use scenarios for each feedback type (bug, feature, data_gap, praise) and explains how the feedback is used (digests, roadmap impact). It does not explicitly mention when not to use the tool, but the clear categorization compensates.

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 safe read-only and non-destructive behavior. The description adds rich behavioral details: it walks child markets, extracts dates/thresholds, sorts, reports pairs with violations, and specifies return format. 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 includes necessary details about logic, examples, and output. It is slightly lengthy but each sentence adds value, making it well-structured.

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

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

Despite lacking an output schema, the description explicitly states the return format (list of entries with fields). Given the tool's complexity (arbitrage detection), the description fully covers the input, logic, and output, satisfying completeness.

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

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

With 100% schema coverage, the schema already describes the 'event' parameter. The description adds value by clarifying expected format ('slug or full URL') and providing an example, going beyond the minimal schema 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 finds arbitrage opportunities by checking monotonicity violations in Polymarket events. It provides a specific verb ('Find arbitrage opportunities'), resource ('Polymarket event'), and logic ('monotonicity violations'), distinguishing it from siblings like 'polymarket_edges'.

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

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

The description explains when to use: for detecting mispricings in events with multiple date/threshold markets. It gives examples and conditions. However, it does not explicitly state when not to use or mention alternatives, but the 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?

Beyond annotations (readOnlyHint, openWorldHint), the description adds rich behavioral context: it groups by asset, fetches price history once, computes model probability, ranks by edge, and returns suggested trade direction. No contradictions with annotations.

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

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

The description is structured and front-loaded with the main purpose, but it is somewhat lengthy (8 sentences). Each sentence adds value, but minor trimming could improve conciseness.

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

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

Given no output schema, the description sufficiently explains the return (top N ranked by edge magnitude with suggested trade direction). It covers methodology, inputs, and use case completely for a discovery tool.

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

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

Schema coverage is 100%, and the description does not add significant detail beyond the schema. It mentions defaults and max for 'limit', but this is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool scans high-volume Polymarket markets and returns those where Pipeworx data disagrees most with market price. It provides specific details about the model (V1, FRED + coinpaprika) and the ranking method, distinguishing it from sibling tools 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 frames the tool as built for the 'what should I bet on today' question, guiding agents to discover opportunities. It implies usage context but does not explicitly state when not to use it or name alternatives, though siblings exist.

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. It explains the dual behavior (retrieve by key vs. list all) and that memories persist across sessions. However, it does not disclose edge cases like missing key behavior or maximum number of memories.

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, no fluff, front-loaded with the primary action. 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?

Given a simple tool with one optional parameter and no output schema, the description is nearly complete. It explains the two modes and persistence. Could mention error handling or performance, but not critical.

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. The description mentions 'omit to list all keys' which aligns with the optional key parameter, but doesn't add new 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 it retrieves a memory by key or lists all memories. It specifies the resource ('stored memory') and the action ('retrieve'/'list'), and differentiates from sibling tools like 'remember' (store) and 'forget' (delete).

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 tool to retrieve context saved earlier, and implies that omitting the key lists all memories. It does not explicitly exclude use cases or mention alternatives, but the sibling tools hint at distinct roles (e.g., 'remember' for storage, 'forget' for deletion).

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

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

With no annotations, the description carries full burden and excels by detailing the parallel fan-out to SEC EDGAR, GDELT, and USPTO, the return structure (structured changes + count + citation URIs), and the accepted 'since' formats. All behavioral traits are disclosed.

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, well-organized paragraph. It front-loads the purpose, then provides usage context, and ends with technical details. Every sentence adds value 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?

Despite no output schema, the description covers the return structure. All parameters are thoroughly explained. The tool is complex (multiple data sources), but the description provides sufficient context for an agent to understand its behavior and output.

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%, giving a baseline of 3. The description adds value by explaining the 'since' parameter with examples (ISO date and relative shorthand), describing 'value' as ticker or CIK, and noting that 'type' only supports 'company'. This extra clarity justifies a higher score.

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

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

The description clearly states the verb and resource ('what's new with a company') and provides specific example queries ('what's happening with X?', 'any updates on Y?'), making the purpose unambiguous. It distinguishes itself from sibling tools by its focus on recent changes across multiple sources.

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 when to use the tool ('Use when a user asks...') and gives concrete query examples. However, it does not specify when not to use it or mention alternative tools, so it lacks explicit exclusions.

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

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

With no annotations provided, the description carries full burden. It discloses persistence differences (authenticated vs anonymous) and session duration (24 hours). This adds valuable behavioral context beyond the schema.

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

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

Three sentences, each serving a clear purpose: what it does, when to use it, and persistence details. 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 key-value store with no output schema, the description is complete enough. It covers purpose, usage, and behavioral details. However, it could mention that stored values can be retrieved with 'recall' tool.

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

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

Schema description coverage is 100%, so the schema already describes both parameters. The description adds context about the value being any text, but this is already implied by the schema type. No significant new semantics added.

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 use cases like saving findings, preferences, and context. It distinguishes itself from siblings like 'recall' and 'forget' 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 explains when to use the tool (save intermediate findings, user preferences, context across tool calls) but does not explicitly mention when not to use it or provide alternatives. However, the context 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 are provided, so the description must convey behavior. It mentions it returns IDs and citation URIs and gives examples, but does not explicitly state it is read-only, how errors are handled, or if any side effects exist. This is adequate but not fully 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 concise (4-5 sentences), front-loaded with the main purpose, and includes examples and usage guidance without fluff. 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?

Given no output schema and no annotations, the description covers purpose, usage, examples, return types (IDs, citation URIs), and ordering. It does not detail the return format or error cases, but is fairly complete for a lookup tool.

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

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

Schema coverage is 100%, providing baseline 3. The description enhances parameter semantics with examples and specific explanations for the 'value' parameter (e.g., 'For company: ticker, CIK, or name'), adding 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 tool looks up canonical/official identifiers for companies or drugs, specifying the types (CIK, ticker, RxCUI, LEI) and distinguishing it from siblings by noting it replaces multiple 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?

It explicitly tells when to use the tool ('when a user mentions a name and you need the CIK...') and advises using it before other tools that need official identifiers, providing clear context for selection.

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

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

With no annotations provided, the description carries the full burden. It indicates the tool searches a large index but does not mention behavioral traits like result sorting, pagination, or whether it accesses external services. The description is adequate but leaves gaps for a search tool.

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

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

The description is concise with two sentences. It front-loads the key differentiator (full directory vs. hosted packs) and ends with the use case. 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 (e.g., server names, descriptions). It lacks info on sorting, pagination, or what happens with no results. For a simple search tool, it is mostly complete but could add return structure details.

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 describes parameters. The description does not add extra meaning beyond what the schema provides (e.g., 'query' is search query, 'category' filters, 'limit' max results). Thus 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 searches a directory of MCP servers, distinguishing it from 'search_packs' which likely searches within a subset. It specifies the scope ('full Pipeworx MCP directory' vs. 'hosted packs') and the purpose ('find MCP servers for specific use cases').

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 context (finding MCP servers) but does not explicitly state when to use this tool versus siblings like 'search_packs' or 'ask_pipeworx'. It mentions the broader scope but lacks guidance on trade-offs or exclusion criteria.

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

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

The description explains what fields are searched (pack names, descriptions, tool names), which is useful behavioral detail. Since no annotations are provided, the description carries the full burden; it could mention if results are ranked or paginated, but the given info 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?

Two sentences covering purpose and usage, with example keywords. Efficient and front-loaded. No extraneous content.

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 search tool with one parameter, the description is mostly complete. It could mention whether the search is case-sensitive or if partial matches are supported, but the current info is sufficient for basic 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 description coverage is 100%, so the schema already documents the 'query' parameter. The description adds context that the query searches across specific fields, which adds value but is not extensive. 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: searching Pipeworx packs by keyword. It specifies the search scope (names, descriptions, tool names), distinguishing it from sibling tools like 'list_packs' or 'discover_tools'.

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

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

The description provides a clear usage context: use when looking for a specific capability, with examples. However, it does not explicitly mention when not to use this tool or how it differs from 'discover_tools' or 'search_mcp_directory', leaving some ambiguity.

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

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

Discloses data sources (SEC EDGAR + XBRL) and return format (verdict, structured form, actual value with citation). Lacks details on error cases or rate limits, but adequate for a read-only validation 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?

Concise and well-structured: purpose first, then examples, scope, return values, and efficiency claim. No redundant information.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers purpose, usage, return values, and limitations comprehensively.

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 description of 'claim' parameter. Description adds context with examples and clarifies domain constraints, adding value beyond the schema.

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

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

The description explicitly states the tool's purpose: fact-checking natural-language claims. It distinguishes from siblings by noting it replaces multiple sequential calls and specifies scope (company-financial claims).

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?

Clear guidance on when to use (checking user claims) with examples. Specifies supported domain (company-financial claims). No explicit when-not-to-use, but scope is well-defined.

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