Govcon Intel

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

With no annotations provided, the description carries the full burden. It discloses that the tool selects the right tool and fills arguments, which implies autonomous behavior but does not detail limitations, failure modes, or data freshness. The examples hint at capabilities but a few edge-case disclosures would be helpful.

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

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

The description is three sentences plus examples, with no wasted words. It front-loads the core purpose and immediately gives usage guidance.

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

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

Given the simplicity of the tool (single parameter, no output schema, no nested objects), the description is nearly complete. It explains input, behavior, and provides examples. One could argue for mentioning potential delay or error handling, but it's adequate for the complexity level.

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

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

Schema description coverage is 100% for the single parameter 'question', so the schema already documents it. The description adds context by explaining the parameter's purpose in natural language and providing examples, but does not add constraints or formatting rules 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 natural language question and returns an answer from the best data source, which is a specific verb+resource combination. It distinguishes itself from siblings by emphasizing plain English input and automatic tool selection, contrasting with specialized tools like govcon_opportunity_scan.

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 this tool: when you have a question and want the best data source without browsing tools or learning schemas. It provides example questions to guide the user, effectively communicating 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 and destructiveHint=false, so the safety profile is clear. The description adds context about the tool's process (resolves market, classifies bet, fans out to packs) without contradicting annotations. It also implies no side effects.

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

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

The description is front-loaded with the core purpose and is concise overall. However, it includes some marketing language (e.g., 'This is the core demo product') that is not strictly necessary, slightly reducing 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?

The description explains the tool's inputs, process, and outputs (evidence packet plus comparison). While no output schema exists, the description provides sufficient high-level understanding. It could be more explicit about the evidence packet structure, but it is 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 description coverage is 100%, so baseline is 3. The description restates the market parameter's allowed inputs (slug, URL, question text) but does not add new details. The depth parameter is explained in the schema, not in the description. No additional value beyond schema.

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

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

The description clearly states the tool's purpose: researching Polymarket bets by pulling Pipeworx data. It specifies input types (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). It distinguishes from siblings by positioning itself as the core demo product for bet research.

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 recommends usage for 'should I bet on X?', 'what does the data say about this Polymarket market?', or 'is there edge in this bet?'. It also contrasts with siblings by noting agents get bet-relevant context here rather than discovering packs themselves, but does not provide explicit when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns paired data and resource URIs, and implies it is a read operation by returning data from sources like SEC EDGAR and FDA. However, it does not explicitly state whether it is read-only, describe error handling, or mention any authentication or rate limits.

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

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

The description is two sentences, tightly packed with key information: the action (compare), constraints (2–5), types, data returned, and efficiency benefit. No filler.

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

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

For a tool with no output schema, the description adequately explains what is returned (specific financial metrics for companies, counts for drugs) and mentions resource URIs. It could be more complete by noting potential error cases or data freshness, but it covers the essential context.

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 describes both parameters with 100% coverage. The description adds value by clarifying the format for values (tickers/CIKs for company, names for drug) and reiterating the min/max constraints, which helps 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?

The description clearly states it compares 2–5 entities side by side, specifies two distinct types (company, drug) and what data each returns. It differentiates from siblings like ask_pipeworx or resolve_entity, which are not comparison 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 gives clear context for when to use it (comparing entities) and even quantifies efficiency gains (replaces 8-15 sequential calls). However, it does not explicitly state when not to use it or point to alternatives, though no sibling tool performs similar comparisons.

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 mentions the tool returns 'names and descriptions' but does not disclose any behavioral traits like read-only nature, side effects, or rate limits. For a search tool, read-only is likely, but it's not stated. 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 at two sentences, each adding value: first sentence defines purpose, second gives 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's low complexity (2 params, no output schema), the description is nearly complete. It explains what the tool does, when to use it, and how to formulate queries. It lacks information about return format or whether it's read-only, but these are minor gaps.

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

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

Schema description coverage is 100%, and the description adds value by explaining that 'query' should be a natural language description and suggesting examples like 'analyze housing market trends'. It also clarifies default and max for 'limit'. This goes beyond 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: searching a tool catalog by describing a need. It specifies the verb 'search', the resource 'Pipeworx tool catalog', and the method 'by describing what you need'. The unique use case of discovering tools among 500+ options distinguishes it effectively from sibling tools.

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

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

The description explicitly advises to call this tool FIRST when many tools are available, providing clear when-to-use guidance. It implies it's for initial discovery, not for specific data retrieval, which sets expectations.

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

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

No annotations provided, so the description carries the full burden. It discloses the data sources returned, the format (pipeworx:// URIs), and the bundling behavior. It does not mention auth or side effects, but for a read-only profile tool this is sufficient.

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 well-structured sentences plus a cautionary note. Every sentence adds value: first sentence states purpose and scope, second lists data sources, third provides an exclusion. No redundancy.

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

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

For a tool with 2 parameters, no output schema, and no annotations, the description provides complete guidance: what data is returned, the parameter constraints, and a usage exclusion. An agent can reliably invoke this 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%. The description adds value by explaining the type enum (only company), the value format (ticker or CIK), and the limitation that names are not supported (suggesting resolve_entity). This goes beyond the schema's property 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 specifies the verb (returns full profile), the resource (entity across Pipeworx packs), and distinguishes from siblings like resolve_entity, usa_recipient_profile. It lists concrete data sources (SEC filings, XBRL, patents, news, LEI) and states it replaces 10-15 agent 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?

The description explicitly states when to use (full profile in one call) and when not (federal contracts: call usa_recipient_profile directly). It does not mention other siblings like compare_entities, but provides sufficient context.

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

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

No annotations are provided, so the description carries full burden. It states the action (delete) but does not disclose whether deletion is irreversible, whether confirmation is needed, or any side effects (e.g., cascading deletes). The description lacks behavioral context beyond the basic operation.

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

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

The description is a single, concise sentence that front-loads the action. Every word is essential; no wasted 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 the tool's simplicity (1 required param, no output schema), the description is adequate but could be improved by mentioning that the deletion is permanent or that the key must exist. However, the description is complete enough for a straightforward delete operation.

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 parameter. The description adds no additional meaning beyond what the schema provides for the 'key' parameter. 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 uses a clear verb ('Delete') and specifies the resource ('stored memory') and identifier ('by key'). It distinguishes itself from siblings like 'remember' (store) and 'recall' (retrieve) by indicating the opposite operation.

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

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

The description implies usage when deletion is needed, but does not explicitly state when to use this tool versus alternatives (e.g., 'forget' vs 'remember' vs 'recall'). No guidance on prerequisites or conditions 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?

No annotations are provided, so the description carries the full burden. It does not mention any behavioral traits like data freshness, scope limitations, or any destructive/write operations. It is neutral and does not contradict annotations, but could add more transparency about what is included.

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

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

The description is two sentences long, front-loads the purpose, and provides usage examples. It is concise but could be slightly more structured (e.g., separating overview from usage). 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 only one parameter, no output schema, and no annotations, the description adequately covers the input requirement and high-level output. However, it lacks details on output format, error handling, or scope of data (e.g., time range of trends).

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 already explains the 'agency' parameter as 'Federal agency name' and gives examples. The description adds no further semantic detail 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?

Description clearly states it provides 'Federal agency contracting landscape — spending overview, recent awards, SBIR program stats, and spending trends', which is a specific verb+resource combination. It is easily distinguishable from siblings like 'govcon_contractor_profile' or 'govcon_opportunity_scan'.

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 'Provide an agency name' and gives examples ('Department of Defense', 'NASA', 'NIH'). While it does not mention when not to use it, the context of requiring an agency name implies when it is appropriate. No explicit alternatives are stated.

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 present, so the description carries the full burden. It discloses the tool aggregates data from multiple government sources, implying a read-only, non-destructive operation. However, it does not mention data freshness, rate limits, or whether the API key is required for full functionality.

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-structured sentence that immediately conveys the tool's value proposition. It is concise and front-loaded with the key purpose.

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

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

Given the tool has no output schema and moderate complexity (2 params, 1 required), the description adequately explains what the tool does and what input it expects. It could be improved by hinting at the output structure, but the listed data sources provide reasonable expectations.

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

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

Schema coverage is 100% and the description adds no additional parameter details beyond what the schema provides. The description explains the tool's purpose but does not elaborate on parameters, 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 tool provides a 'complete government contractor dossier' and lists specific data sources (SAM.gov, USAspending, SBIR/STTR grants). It distinguishes itself from sibling tools like govcon_opportunity_scan and govcon_agency_landscape by focusing on company profiles.

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

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

The description explicitly says to 'Provide a company name', making the usage straightforward. It implies this is for looking up a contractor's profile, but does not explicitly contrast with sibling tools or provide 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?

No annotations are provided, so the description carries full burden. It describes the search scope but fails to disclose behavioral traits like rate limits, authentication requirements (API key is optional but not explained), or whether results are real-time or cached. The description is vague about the output format.

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

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

The description is a single sentence that is relatively concise, listing the main search categories. It front-loads the purpose. Could be slightly more structured but is 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?

Given no output schema and moderate complexity (3 parameters, no enums), the description covers the tool's scope but lacks details on result format, pagination, or error handling. It is minimally complete but could be improved.

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 describes each parameter. The description adds context that keywords match against 'open SAM.gov opportunities, set-aside contracts...' but does not explain the set_aside parameter further or the _apiKey parameter. 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 for government contracting opportunities across multiple sources (SAM.gov, set-aside contracts, recent awards, SBIR solicitations). The verb 'search' and the resource 'government contracting opportunities' are specific, and it distinguishes itself from sibling tools like 'govcon_agency_landscape' and 'govcon_contractor_profile' which focus on agencies and contractors.

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

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

The description implies usage for keyword-based searching but does not explicitly state when to use this tool versus alternatives. It mentions various contract types but lacks guidance on when to use filtering (set_aside) or prerequisites. No mention of when not 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?

No annotations provided, so the description carries full burden. It discloses rate-limiting (5 messages per identifier per day) and behavioral guidelines (what to include/exclude). It does not mention output, but given no output schema, this is acceptable.

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

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

The description is concise (two sentences plus rate limit note), front-loaded with purpose, and every sentence adds value. No unnecessary words.

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

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

For a simple feedback tool with three parameters and no output schema, the description provides sufficient context: purpose, constraints, and parameter guidance. It is 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 description coverage is 100% with detailed enum explanations. The description adds minor value (e.g., not including verbatim prompts) but does not significantly enhance parameter understanding beyond schema.

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

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

The description clearly states the tool is for sending feedback to the Pipeworx team, listing specific use cases (bug reports, feature requests, missing data, praise). This distinguishes it clearly from all sibling tools.

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

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

The description provides clear guidance on when to use the tool and includes constraints (do not include end-user prompt verbatim, rate-limited). It lacks explicit when-not-to-use statements, but given distinct purpose, it is sufficient.

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 openWorldHint=true, indicating safe, read-only, non-deterministic behavior. Description adds that output includes ranked opportunities with trade direction and reasoning, fully 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?

One paragraph with front-loaded purpose, clear mode breakdown, rationale for cross-event mode, and output description. Every sentence is informative, no redundancy.

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

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

No output schema, but description covers output format (ranked opportunities with reasoning). Parameters fully documented. Minor gap: does not explicitly state that at least one of event/topic must be provided (both are optional in schema). Otherwise 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%. Description adds value by explaining each parameter's mode context and providing examples (e.g., event slug 'when-will-bitcoin-hit-150k', topic 'Strait of Hormuz traffic returns to normal'), enriching the schema's basic descriptions.

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

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

Description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations, with two distinct modes (event/topic). This differentiates it 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?

Explicitly describes two modes with when to use each: event mode for single-event ordering checks, topic mode for cross-event cases that single-event mode misses. Provides rationale for cross-event mode, aiding correct 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 declare readOnlyHint, openWorldHint, and destructiveHint, which are consistent with the description. The description adds behavioral details: scans top markets, groups by asset, fetches price history once, computes model probability, and ranks by edge. No contradictions. The description enriches the annotation-based safety profile.

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 core purpose. It explains the model and process in detail, but is slightly verbose. Each sentence adds value, though some redundancy could be trimmed. Effective but not maximally concise.

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

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

No output schema is provided, but the description explains the return format (top N ranked by edge magnitude with suggested trade direction) and the model used. Covers the key aspects needed for an agent to understand what the tool does. Slightly lacks detail on output structure (e.g., whether market IDs are included), but sufficient for its purpose.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds default values and limits (e.g., Default 10, max 25) but does not significantly extend beyond the schema. Baseline 3 is appropriate as the schema already provides sufficient semantics.

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

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

The description clearly states the tool scans high-volume Polymarket markets and returns those where Pipeworx data disagrees most with market price. It specifies the model (lognormal from FRED + coinpaprika) and the output (top N ranked by edge magnitude with suggested trade direction). This distinctively addresses the 'what should I bet on today' question, setting it apart from siblings.

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

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

The description explicitly frames it for discovering betting opportunities without manual browsing, stating 'Built for the 'what should I bet on today' question'. It implies when to use but does not compare directly to sibling tools like polymarket_arbitrage. Context is clear but 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?

The description discloses that the tool can retrieve by key or list all memories, and that it works across sessions. No annotations are provided, so the description carries the full burden, and it adequately covers key behavioral aspects (no destructive effects, read-only operation). It does not mention potential side effects or authorization needs, but for a simple retrieval tool this is sufficient.

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 wasted words. The first sentence states the core functionality, and the second provides usage context. 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 the tool's simplicity (1 parameter, no required fields, no output schema), the description is complete. It explains both retrieval modes and cross-session behavior. No output schema exists, so the description could mention return format, but the context of 'retrieve' implies returning the stored data; this is acceptable for a minimal 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?

The input schema has 100% coverage with one parameter ('key'), which is described in the schema as 'Memory key to retrieve (omit to list all keys)'. The description adds that omitting the key lists all stored memories, which aligns with the schema and reinforces the dual behavior. Since schema coverage is high, a baseline of 3 is appropriate, and the description adds context about session persistence, raising the 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 tool's purpose: to retrieve a previously stored memory by key, or list all stored memories when the key is omitted. The verb 'retrieve' and resource 'memory' are specific, and the behavior for both cases is explicitly described, distinguishing it from sibling tools like 'remember' 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?

The description provides clear guidance on when to use this tool: to retrieve context saved earlier. It implicitly distinguishes from 'remember' (save) and 'forget' (delete) by focusing on retrieval. However, it does not explicitly mention when not to use it or alternative tools beyond the context of the session.

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 fully discloses behavior: parallel fan-out to SEC EDGAR, GDELT, USPTO; accepted date formats; return structure (structured changes, count, URIs). It implies read-only operation, and no contradictions 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?

The description is a single paragraph but packs essential information efficiently. It is well-organized, starting with purpose, then mechanics, then usage suggestion. Slightly dense but not verbose.

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

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

Given the tool's complexity (multiple data sources, specific input formats, structured output) and lack of output schema, the description covers all necessary aspects: what it does, how to call it, what to expect back, and when to use it. Leaves no major gaps.

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

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

Schema covers 100% of parameters with descriptions, but the description adds valuable context: type enum is currently limited to 'company', since accepts relative and ISO formats with examples, and value can be ticker or CIK. This enriches the schema information.

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: retrieving recent changes for an entity since a given time. It specifies the supported entity type (company) and elaborates on the data sources used. This distinguishes it from sibling tools like entity_profile (static profile) or compare_entities (comparison).

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

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

The description explicitly recommends use cases: 'brief me on what happened with X' or change-monitoring workflows. It does not directly exclude alternatives but provides clear context for appropriate usage.

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 discloses behavioral traits: persistence differences for authenticated users (persistent) vs anonymous (24-hour expiry). This adds valuable context beyond what annotations would typically 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?

Three sentences, each serving a distinct purpose: first defines action, second advises when to use, third notes persistence behavior. No filler or repetition.

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

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

Given the simplicity (2 required params, no output schema), the description is complete. It covers purpose, usage, and persistence behavior. A minor gap is not mentioning that values can be overwritten on same key, 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 description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter details beyond the schema, but the examples in the schema are sufficient. 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 stores a key-value pair in session memory. It specifies the resource ('session memory') and the action ('store a key-value pair'), distinguishing it from siblings like 'recall' (retrieve) and 'forget' (remove).

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 this tool: to save intermediate findings, user preferences, or context across tool calls. It provides usage context but does not explicitly state when not to use it or name alternatives, though siblings imply alternatives for retrieval and 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 provided, the description carries full burden. It discloses the operation (resolve, read-like) and outputs but does not mention idempotency, authentication needs, rate limits, or potential side effects. The description is adequate but leaves behavioral aspects unspecified.

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

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

The description is concise at three sentences, front-loading the key action and benefit. Every sentence adds relevant information without redundancy.

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

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

Given the tool's simplicity (two parameters, no output schema), the description covers purpose, input examples, and output elements. It lacks details on error handling or edge cases, but for the stated scope it is reasonably 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 description coverage is 100%, baseline 3. The description adds value by providing example formats (e.g., 'AAPL', '0000320193') and clarifying the version constraint for type, but does not significantly extend beyond the schema descriptions.

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

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

The description clearly states the action ('resolve an entity') and the resource ('canonical IDs across Pipeworx data sources'). It specifies outputs (ticker, CIK, name, URIs) and mentions efficiency gain over multiple calls. However, it does not explicitly differentiate from sibling tools like ask_pipeworx.

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

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

The description provides clear context on when to use the tool: for resolving entities to canonical IDs with examples of input formats (ticker, CIK, name). It implies efficiency ('replaces 2-3 lookup calls') but lacks explicit when-not-to-use guidance or alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: returns specific verdict types, extracted structured form, actual value with citation, and percent delta. It also notes the underlying data sources (SEC EDGAR+XBRL). This provides good transparency without listing destructive actions or auth needs, which are not applicable.

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 remarkably concise: two sentences that cover purpose, supported domain, output details, and value proposition. 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 low complexity (single parameter, no output schema), the description is quite complete. It explains what claims are supported, what the output includes, and why it's efficient. It could optionally mention error handling or unsupported claim types, but overall it's sufficient.

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

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

Schema coverage is 100% with only one parameter (claim) already described. The description adds value by giving concrete examples of valid claims, which helps the agent understand the expected input format and scope.

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: fact-checking natural-language claims against authoritative sources, specifically company-financial claims via SEC EDGAR+XBRL. It distinguishes from siblings like entity_profile and resolve_entity which focus on entity resolution rather than claim validation.

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

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

The description provides clear context for when to use the tool (financial claims for public US companies) and hints at limitations ('v1 supports'). It also explains the efficiency gain over sequential calls. However, it does not explicitly state when not to use it or list alternatives.

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