Mitre Attck

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

Annotations already provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds that the tool returns structured answers with stable pipeworx:// citation URIs, fills arguments automatically, and selects from thousands of tools. 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 moderately long but front-loaded with the key instruction to prefer over web search. It includes a long list of example use cases which could be condensed. While informative, it could be more concise without losing 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 tool has one required parameter, no output schema, and a complex ecosystem of sibling tools, the description effectively covers its purpose, when to use it, and what to expect (citations, structured answers). It does not explain error handling or rate limits, but the read-only and non-destructive annotations suffice for basic safety.

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 covers the only parameter 100% with a basic description. The tool description goes beyond by stating that the question is in natural language and providing many example queries, which helps the agent understand the scope and format of acceptable inputs. This adds significant 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 that the tool routes questions to the appropriate tool among over 1,400 verified sources, returning structured answers with citations. It distinguishes itself from web search by emphasizing its preference for authoritative structured data, using strong verbs like 'PREFER OVER WEB SEARCH' and listing specific data domains.

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 prefer this tool over web search for factual queries and provides numerous examples of when to use it (e.g., 'current US unemployment rate', 'Apple's latest 10-K'). It implies broad applicability for factual questions. However, it does not mention when to use sibling tools like bet_research for specific domains, which would improve guidance.

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

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

Annotations already mark it as read-only, open-world, non-destructive. Description adds behavioral detail: resolves market, classifies bet type, fans out to specific packs (with examples), returns evidence packet and comparison. No contradiction with annotations. Lacks specifics on error handling or rate limits, but adequate given annotation coverage.

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

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

Four sentences, front-loaded with purpose, then details, then process, then use cases. Each sentence earns its place. Slightly verbose but informative and 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?

Tool is complex (multiple input formats, automatic classification, fan-out, output includes evidence and comparison). Description explains what input is accepted, what happens internally, and what is returned. No output schema, but description gives sufficient expectation. Slightly vague on exact output structure, but adequate for an agent.

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

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

Schema covers both parameters with descriptions. Description adds meaning: explains the 'depth' enum values (quick = 2-3 sources, thorough = full fan-out) and reinforces acceptable formats for 'market'. Adds value beyond schema but not extensive.

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, with specific verb-resource pair. It distinguishes from siblings by describing the classification and fan-out logic that combines multiple data sources automatically, which no other sibling does.

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 gives use cases ('should I bet on X?', 'what does the data say?', 'is there edge?') and contrasts with alternatives by noting agents using this tool convert better than those discovering packs themselves. Provides clear when-to-use and implicit when-not-to.

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?

Description goes beyond annotations by detailing data sources (SEC EDGAR, FAERS, FDA, clinicaltrials) and output format (paired data, citation URIs). 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?

Single paragraph of ~100 words, front-loaded with purpose and usage. Could be more structured with bullet points, but remains concise and clear.

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

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

Covers entity types, data sources, and return characteristics. Missing details on exact format of paired data or pagination, but sufficient given no output schema and 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 description adds examples and clarifies how values map to tickers or drug names, enhancing understanding beyond raw 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?

Clearly states the tool compares 2–5 companies or drugs side by side, with specific use-case phrases ('compare X and Y', 'X vs Y'). Distinguishes from siblings by noting it replaces 8–15 sequential calls.

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

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

Explicitly lists triggering phrases and distinguishes between company and drug types. Could mention when not to use (e.g., when only one entity is needed, use entity_profile), but still provides effective guidance.

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

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

The description states that it returns 'top-N most relevant tools with names + descriptions,' which is consistent with the readOnlyHint annotation. It adds context beyond annotations by explaining the tool's behavior as a search/discovery function, but could mention that it only searches tools on this server.

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

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

The description is a single paragraph that front-loads the purpose and includes a call to action. It is concise without unnecessary words, though it could be broken into clearer sentences for readability.

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 adequately covers what the tool does and how to use it. It mentions the return format (names+descriptions) despite lacking an output schema. The tool's low complexity and good annotations make the description sufficient.

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

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

The input schema has 100% coverage with descriptions for both parameters (query, limit). The description adds value by explaining the default and max limit (20, 50) and providing examples for the query parameter, enhancing the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It provides specific examples of use cases (SEC filings, financials, FDA drugs, etc.) and distinguishes itself from sibling tools by being the only discovery tool.

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

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

The description explicitly advises: 'Call this FIRST when you have many tools available and want to see the option set.' It also lists many scenarios where the tool is appropriate, giving clear guidance on when to use it.

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 adds no behavioral context. It does not contradict annotations, but for a tool with no extra detail, a score of 3 is appropriate.

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 with no superfluous words. It is well-structured 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 and the simple nature of the tool, the description is adequate but lacks explanation of what 'STIX bundles' are or the output format. Some additional context would improve 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?

There are no parameters, and schema coverage is 100%. Per guidelines, baseline is 4 for zero parameters. No additional semantics needed.

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 'List loaded STIX bundles' clearly states the verb (List) and resource (loaded STIX bundles), making the purpose unambiguous. However, it does not explicitly differentiate from siblings like 'group' or 'software', but the resource is specific enough.

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

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

No guidance is provided on when to use this tool versus sibling tools. Given the variety of siblings, explicit context on when 'domains' is appropriate would be helpful.

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?

Description adds value beyond readOnlyHint and openWorldHint annotations by detailing the returned data types and citation URIs. It also clarifies current limitation (only company type). Could mention potential latency or cost but otherwise strong.

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 paragraph is dense and well-ordered: purpose first, then usage triggers, then output enumeration, then parameter notes. Slightly long but no wasted words; could be broken for readability but not necessary.

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, description thoroughly explains what the tool returns. Parameter details are complete. Context about when to use and alternatives is provided. The tool is complex (aggregating multiple sources), and the description covers that.

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%, and description adds critical context: 'names not supported — use resolve_entity first if you only have a name' and gives examples for value (ticker or zero-padded CIK). This goes beyond schema to guide correct usage.

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 'Get everything about a company in one call', specifies verb and resource, lists exact outputs (SEC filings, fundamentals, patents, news, LEI), and distinguishes from siblings by noting it replaces 10+ pack tool 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 gives user query patterns ('tell me about X', 'profile of Acme', etc.) and notes when to use versus alternatives like resolve_entity for names. Also implies when not to use (if you only have a name, use 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?

Annotations already indicate destructiveHint: true. The description adds context about clearing sensitive data and stale context, enhancing transparency 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?

Two concise sentences, front-loaded with the action, immediately 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?

For a simple destructive tool with one parameter and built-in annotations, the description covers purpose, usage scenarios, and relationship to siblings completely.

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 has 100% coverage for the single 'key' parameter, so baseline is 3. Description doesn't add extra semantics beyond the schema's description 'Memory key to delete'.

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 'Delete a previously stored memory by key,' specifying verb and resource. It distinguishes from siblings by explicitly mentioning 'remember' and 'recall'.

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: 'when context is stale, the task is done, or you want to clear sensitive data.' It also suggests pairing with related tools.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds no behavioral context beyond labeling the resource. It fails to disclose that this is a lookup tool or specify any side effects, return format, or authentication needs.

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

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

The description is extremely short (5 words) but under-specified. While front-loaded, it fails to convey essential information, making it ineffective. Conciseness is not a virtue when it omits critical details.

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 low complexity, the description should explain tool behavior and return values. It does not state that the tool retrieves a threat group by ID, nor does it clarify the output structure. Incomplete for an agent to use correctly.

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

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

Input schema has 2 parameters (id required, domain optional) with 0% schema coverage. The description provides zero information about what these parameters mean, expected formats, or examples. Without this, the agent cannot correctly invoke the tool.

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

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

The description 'Threat group (e.g. G0007)' is a noun phrase with an example but no verb indicating the tool's action. It suggests the tool is about threat groups but does not explicitly state whether it retrieves, lists, or searches. Vague purpose with no clear verb-resource combination.

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

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

The description provides no guidance on when to use this tool, what alternatives exist (e.g., 'technique', 'software'), or any context for selection. No when-to-use or when-not-to-use information.

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?

Description adds no behavioral traits beyond annotations. It does not confirm that it is read-only (already in annotations) or explain any other behavior. Too vague to be 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?

Single word is underspecified, not concise. It earns no space through usefulness.

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 no output schema, no parameter descriptions, and no usage context, the description is completely inadequate for a tool with 2 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 description coverage is 0%, and the description provides no meaning for the 'id' or 'domain' parameters. Schema alone leaves ambiguity.

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 is just 'Mitigation,' which is a tautology of the name. It fails to specify any verb or resource, making it impossible to understand what the tool does.

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

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

No guidance on when to use this tool versus siblings like 'search' or 'remember.' No mention of context or criteria 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?

Annotations provide minimal info, but the description fully compensates. It discloses that the tool sends feedback (not read-only), is not destructive, and is not open-world. It adds rate-limit details (5 per identifier per day) and confirms it doesn't count against tool-call quota, giving complete behavioral transparency.

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

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

The description is efficiently structured: first sentence states purpose, then usage guidance, followed by a note about team practices and rate limits. Every sentence is necessary and front-loaded with critical information. No extraneous text.

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

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

For a simple feedback tool, the description covers all aspects: purpose, usage, what to include/exclude, rate limits, and quota impact. Schema is detailed, annotations are consistent, and no output schema is needed. The description is self-sufficient and leaves no 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 descriptions, but the description adds significant semantic value: it elaborates on the enum options beyond the schema (e.g., 'bug = something broke...'), explains the optional context object's purpose, and advises on message specificity. This extra context aids correct parameter selection.

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: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates specific feedback types (bug, feature/data_gap, praise) and distinguishes itself from sibling tools like ask_pipeworx or discover_tools by focusing on platform 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?

Explicitly states when to use: 'when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides a 'don't' instruction: 'don't paste the end-user's prompt.' Rate limits and quota impact are clearly noted.

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

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

Annotations already declare read-only and open-world. The description adds details: two modes, cross-event search behavior, and return format (ranked opportunities with reasoning). 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 one concise paragraph front-loaded with purpose, then explains modes and cross-event motivation, ending with output. 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 specifies returns (ranked opportunities with suggestions). Parameters are fully covered, and the tool's complexity is adequately addressed given annotations.

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 parameter descriptions. The description adds meaningful context: event can be slug or URL, topic is a seed question, and explains how each mode works. This goes beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations. It distinguishes two modes (event vs topic) and explains cross-event case, differentiating from sibling tools 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?

It explicitly describes when to use each mode with concrete examples (e.g., single-event slug vs topic like 'Strait of Hormuz'). It doesn't mention when not to use the tool, but the context is clear 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?

Annotations indicate readOnlyHint: true and destructiveHint: false. The description adds substantial behavioral detail: it fetches price history, computes model probability, ranks by edge magnitude, and returns suggested 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 a single paragraph that front-loads the main action and purpose. It is efficient but slightly lengthy due to model details; could be trimmed slightly without losing meaning.

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

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

Given the tool's complexity (3 optional parameters, no output schema), the description provides sufficient context: input parameters, model approach, grouping logic, and output format (ranked edges with trade direction). It fully prepares an agent to use the tool 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 description coverage is 100%, with each parameter having a brief description. The tool description reiterates the output ranking but doesn't add new semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('scan', 'return'), resource ('Polymarket markets'), and specific purpose ('where Pipeworx data disagrees most with market price'). It also names the model and sources, distinguishing it from siblings like polymarket_arbitrage.

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

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

The description explicitly frames the tool for the 'what should I bet on today' use case, implying when to use. While it doesn't explicitly state when not to use or name alternatives, the context is clear and practical.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations: behavior when key is omitted (lists all keys), scoping to identifier, and the type of data stored (ticker, address, notes). 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?

Single, dense sentence that front-loads the main action. Uses dashes to separate key details without verbosity. Every part 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 (one optional parameter, no output schema), the description fully covers its purpose, usage, behavior, and relationship to siblings. No 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 a description for the 'key' parameter. The description adds value by explaining that omitting the key lists all saved keys and gives examples of what keys might contain (ticker, address).

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 specific verb 'retrieve' and resource 'value saved via remember', and distinguishes from siblings by mentioning pairing with 'remember' and 'forget'. It clearly states the dual functionality: retrieving a specific key or listing all keys if omitted.

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

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

Explicitly states when to use it ('to look up context the agent stored earlier') and how to use it (omit key to list all). Provides context for scope and mentions related tools for saving and deleting.

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

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

The description adds behavioral context beyond annotations: it fans out to SEC EDGAR, GDELT, and USPTO in parallel; accepts both ISO dates and relative shorthand; returns structured changes with citations. Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which are consistent.

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 (5 sentences), front-loaded with purpose and usage, then covers behavior and return structure. Every sentence adds value with no redundancy or fluff.

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

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

Despite no output schema, the description specifies the return format: 'structured changes + total_changes count + pipeworx:// citation URIs.' This, combined with the detailed input schema and annotations, provides sufficient context for an agent to select and invoke the tool 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% (all three parameters have descriptions). The description adds value by clarifying that 'type' only supports 'company', giving examples for 'since' and 'value', and suggesting typical usage like '30d' for the 'since' parameter. This improves parameter understanding beyond the schema.

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

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

The description clearly states the tool's purpose: 'What's new with a company in the last N days/months?' It provides example queries and specifies the verb (fans out to multiple sources) and resource (company changes). It distinguishes itself from siblings like entity_profile and ask_pipeworx by focusing on temporal changes.

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 "what's happening with X?"... or monitoring for changes.' It provides concrete query examples but does not explicitly state when not to use it or name alternative tools. However, the context is clear enough for common use cases.

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 behavior beyond annotations: scope by identifier, retention policy (24 hours for anonymous), and persistence difference for authenticated users. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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?

Mostly concise with front-loaded purpose, but includes some redundant phrasing (e.g., 'Stored as a key-value pair scoped by your identifier' could be tighter). Still, every sentence adds value.

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

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

For a simple write tool with no output schema, description adequately covers behavior, parameters, and pairing with recall. No missing information for effective use.

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

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

Schema coverage is 100%, so description's examples (e.g., 'subject_property') add context beyond schema definitions. While not strictly necessary, the examples improve clarity and usage understanding.

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

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

The description clearly states the tool saves data for reuse across conversations or sessions, with specific examples of when to use it (resolved ticker, target address, user preference). It distinguishes from siblings recall and forget.

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

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

Explicitly tells when to use (discover something worth carrying forward) and when not to use alternatives. Pairs with recall for retrieval and forget for deletion, providing complete usage context.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the tool is known to be safe and non-destructive. The description adds value by detailing what the tool returns (IDs plus pipeworx:// citation URIs) and that it replaces 2-3 lookup calls. It does not mention rate limits or authentication, but the annotations cover safety. No 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 concise (4 sentences) and front-loaded with the main action and purpose. Every sentence provides essential information: purpose, use case, examples, return values, and guidance. No redundant or filler 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?

Given no output schema, the description partially explains return values (IDs and citation URIs) and the ID systems. It covers the key aspects needed for an agent to use the tool effectively. However, it does not detail the exact structure of the response (e.g., whether multiple IDs are returned in a list), which could be improved, but overall it is sufficient for the intended task.

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% for both parameters (type and value). The description adds examples (e.g., 'Ozempic' → RxCUI 1991306) and explains that 'value' can be a ticker, CIK, or name for companies, and brand or generic for drugs. This enriches the schema's enum and free-text descriptions, helping the agent understand valid inputs beyond the 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?

The description clearly states the tool's purpose: look up canonical/official identifiers for companies or drugs. It specifies the types of identifiers (CIK, ticker, RxCUI, LEI) and provides concrete examples (Apple → AAPL/CIK, Ozempic → RxCUI). This distinguishes it from sibling tools by consolidating multiple lookups, and the verb 'resolve' combined with the resource 'entity' is specific and unambiguous.

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 using this tool before calling others that need official identifiers ('Use this BEFORE calling other tools that need official identifiers'). It also describes the context: when a user mentions a name. However, it does not explicitly state when not to use it or mention alternatives among the 23 sibling tools, though the context implies it is the correct choice for identifier lookup.

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 annotations (readOnlyHint: true, openWorldHint: true) already indicate a safe, read-only operation. The description adds no additional behavioral details such as case sensitivity, result limits, or how the substring matching works. It merely restates the basic functionality without enriching the agent's understanding.

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. However, conciseness comes at the cost of missing important details. It is not optimally informative; it front-loads the core idea but lacks necessary context for effective tool usage.

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 has three parameters with low schema coverage and no output schema. The description is too brief to cover the tool's functionality comprehensively. It omits essential information about expected results, parameter combinations, and behaviors beyond the core substring search.

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 only 33% (only 'type' has a description). The description does not compensate by explaining 'query' or 'domain'. It mentions 'substring search' but does not clarify how parameters interact or their purposes, leaving significant gaps.

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 'substring search across the bundle', indicating a specific verb and resource. However, 'the bundle' is vague and not further defined, which slightly reduces clarity. Among siblings, it is distinct from specific entity lookups like 'entity_profile' or 'domains', but the scope of 'bundle' is ambiguous.

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 guidance on when to use this tool versus alternatives like 'discover_tools' or 'domains'. There is no mention of context where substring search is appropriate or when it is not. The description provides no comparative or exclusionary information.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no behavioral context beyond the resource type, failing to disclose any additional traits.

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 (one phrase) but lacks necessary detail. It is not verbose, but its brevity comes at the cost of 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?

For a tool with 2 parameters and no output schema, the description is incomplete. It does not specify return values, parameter usage, or behavior like pagination or filtering.

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 0% schema description coverage, the description must explain parameters. It only gives an example for 'id' and does not clarify the 'domain' parameter at all, providing minimal semantic value.

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

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

The description 'Software/malware (e.g. S0002)' is vague; it does not explicitly state whether the tool retrieves details, lists software, or performs another action. The example only hints at lookup, but purpose is unclear.

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

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

No guidance on when to use this tool versus siblings like entity_profile or search. The description does not provide context for appropriate use cases.

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

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

Annotations already declare readOnlyHint=true, but the description adds no behavioral details beyond that. It does not mention what happens if the tactic is not found, whether it returns one or multiple results, or any other behaviors.

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 short (a sentence fragment), which might be considered concise but lacks structure. It does not earn its place as it omits essential details.

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 low complexity, the description should explain what the tool returns (e.g., tactic details, structure). It fails to provide any such context, making it incomplete for an agent to use correctly.

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

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

The schema has two parameters (domain, id_or_short_name) with 0% description coverage. The description only mentions id_or_short_name, ignoring domain entirely. No explanation is given for the domain parameter or its 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 'Tactic by id or short name' indicates retrieval by identifier, but it doesn't specify the domain (e.g., MITRE ATT&CK) or differentiate from sibling tools like 'technique' or 'mitigation'. The purpose is partially clear but lacks specificity.

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

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

The description provides no guidance on when to use this tool versus siblings such as 'technique' or 'mitigation'. There are no hints about context 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 declare readOnlyHint=true and destructiveHint=false. Description adds no additional behavioral context such as return format, rate limits, or any side effects beyond what annotations provide.

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

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

Single sentence, no redundant information. Efficient but arguably under-specified for a tool with two parameters and no output schema.

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?

No output schema and 0% schema coverage. Description lacks return value details, parameter formats, or examples. Adequate for a simple tool but incomplete for optimal agent usage.

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 0%. Description clarifies that 'id' is an ATT&CK ID, which adds some meaning, but leaves 'domain' undocumented. Minimal enhancement over 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 indicates tool retrieves a technique by ATT&CK ID. It specifies the resource (technique) and the lookup key, but does not differentiate from sibling tools like group or software, though context suggests separate 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?

No guidance on when to use this tool versus alternatives (e.g., group, software) or when not to use it. Missing context like ID format or prerequisite knowledge.

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 (readOnlyHint: true, destructiveHint: false) indicate safe read-only behavior, and the description aligns by detailing return values (verdict, actual value, citation). It adds transparency about the tool's version and supported claim types, which is consistent 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 a single compact paragraph that packs essential details (purpose, usage signals, domain, return structure) without redundancy. It could be slightly more structured with bullet points, but it remains scannable and efficient.

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

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

Despite no output schema, the description fully explains the return format (verdict types, actual value, citation, delta). It also clarifies limitations (v1, company-financial claims). This provides sufficient context for an agent to understand the tool's capabilities and boundaries.

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 single 'claim' parameter is fully described with a natural-language example, and schema coverage is 100%. The description adds meaning by explaining how the tool interprets the claim (NL parsing, entity resolution, comparison) 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 specifies a clear action (fact-check, verify, validate) against authoritative sources, distinguishes the tool's scope (company-financial claims via SEC EDGAR), and provides example queries. It is distinct from sibling tools like 'bet_research' or 'resolve_entity'.

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

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

The description explicitly states when to use the tool (when validating factual claims), gives example trigger phrases, and notes the domain restriction. It does not explicitly list exclusions or alternatives, but the context implies 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.