Bls

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

With no annotations provided, the description carries full burden. It discloses key behaviors: uses 'best available data source', automatically picks tool and fills arguments, returns result. Clearly states it's a natural language interface that abstracts away tool selection. No contradictions with annotations (none provided).

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: first states core function, second explains automation, third provides examples. No wasted words. Front-loaded with key action. Highly 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 simple input schema (one param), no output schema, and no annotations, the description sufficiently covers how to use the tool. Examples provide clarity. Could mention potential limitations (e.g., scope of data sources, latency) but is complete 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% (only one parameter 'question' with clear description). The description adds meaning beyond the schema by explaining how the question is used (to select tool and fill arguments) and providing usage examples. This adds valuable context that the schema alone does not convey.

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: answer natural language questions by selecting the best data source. It uses specific verbs ('Ask', 'picks', 'fills', 'returns') and resource ('answer from the best available data source'). Distinguishes from siblings by emphasizing natural language interaction and automatic tool selection, which none of the sibling tools (e.g., bls_get_series, bls_search) offer.

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

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

Explicitly says 'no need to browse tools or learn schemas — just describe what you need.' Provides concrete examples (trade deficit, adverse events, 10-K filing). Does not explicitly state when not to use this tool or mention alternatives, but the examples and context imply it's for general-purpose questions that can be answered by any of the sibling 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 already indicate read-only, open-world, non-destructive behavior. The description adds transparency about internal logic: market resolution, bet classification, automatic fan-out to relevant packs (e.g., crypto+fred+gdelt for BTC bets), and the output structure. This goes beyond annotations without contradicting them.

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 earning its place: first sentence defines purpose and inputs, second details internal process, third gives usage guidance. No fluff, well-front-loaded.

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

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

For a tool with 2 parameters, full schema coverage, and annotations present, the description covers purpose, inputs, internal logic, and output. No output schema exists, but the description outlines the output content, making it complete enough for an agent to understand and 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?

Input schema coverage is 100%; both parameters are well-documented in the schema. The description reiterates the market input types and briefly hints at the depth parameter ('quick = 2-3 evidence sources, thorough = full fan-out'). This adds minimal extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly identifies the tool's purpose: researching a Polymarket bet by aggregating relevant Pipeworx data. It specifies inputs (slug, URL, question text), the resolution/classification process, and the output (evidence packet with market-vs-model comparison). This differentiates it from siblings like ask_pipeworx or validate_claim.

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 lists use cases ('should I bet on X?', 'what does the data say?', 'is there edge?') and frames it as the core demo product. It implies this is the preferred tool for bet research, but does not explicitly state when not to use it or mention alternatives. Still, the guidance is clear and actionable.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description does not mention rate limits, data freshness, whether the tool is read-only, or any side effects. It lacks critical behavioral context for a data retrieval tool.

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

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

The description is two sentences, front-loading the core purpose and then listing supported categories. Every sentence adds value, and there is no waste. It is concise 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?

Given the absence of output schema and annotations, the description should explain what the response looks like or note pagination/format. It does not. However, for a simple data retrieval tool with well-known BLS series, the description is minimally complete but has gaps in behavioral 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?

Schema description coverage is 100%, so baseline is 3. The description adds context about supported series types (employment, CPI, etc.) but does not add meaning beyond what the schema provides for each parameter. The description's value is limited to summarizing the tool's domain.

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

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

The description uses specific verbs and resources: 'Get time series data from the Bureau of Labor Statistics for one or more series.' It clearly states the tool retrieves time series data for multiple economic indicators, and the sibling context includes related BLS tools (e.g., bls_latest, bls_search) which are differentiated.

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

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

The description gives a high-level context of when to use (employment, CPI, wages, etc.) but does not explicitly state when not to use or compare to siblings like bls_latest or bls_search. The agent can infer usage from the mention of 'time series data' vs 'latest data' or 'search,' but no direct guidance is provided.

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

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

No annotations provided, so description must carry burden. Clearly describes read-only behavior ('Get just the most recent data point'), and mentions no destructive effects. Could add details like API rate limits or data freshness, but current is adequate.

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

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

Two concise sentences, front-loaded with action and purpose. 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?

Simple tool with 2 params (one optional), no output schema. Description covers purpose and usage context. Lacks mention of return format or example, but tool is simple enough that this is adequate.

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

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

Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema descriptions; series_id example is already in 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?

Clear verb (Get) + resource (most recent data point for a BLS series). Distinguishes from siblings like bls_get_series (multiple data points) and bls_popular_series (popular series list).

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

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

States 'quick current-value lookups', implying one-off needs. No explicit when-not or alternatives, but sibling names provide differentiation.

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

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

The description states the output includes IDs and descriptions organized by category. Annotations are empty, so the description carries the full burden. It does not mention any destructive behavior, rate limits, or other behavioral traits, but since the tool is clearly read-only (listing), 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?

Two sentences with no waste. Front-loaded with action and result. Every sentence provides value.

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

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

Given no output schema, the description does not detail the return structure (e.g., format of IDs and descriptions). However, for a simple listing tool with one optional parameter and a clear purpose, it is nearly complete. Could mention that the list is static or curated.

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% (the parameter's description is present). The description adds that categories include housing, employment, prices, wages, productivity, but this is already in the schema description. No additional meaning beyond schema is provided.

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 lists curated popular BLS series with IDs and descriptions, organized by category. It uses specific verbs ('list', 'discover') and distinguishes from siblings like 'bls_search' which searches broadly.

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

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

The description says 'Use this to discover available series', which implies a discovery use case but does not explicitly contrast with sibling tools like 'bls_search' or 'bls_get_series'. No exclusions are provided.

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

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

With no annotations, the description carries the full burden. It correctly states it searches a curated catalog and returns matching IDs with descriptions, which implies it's a read operation and not destructive. However, it does not disclose if the catalog is limited in size, whether results are paginated, or if there are rate limits. The description is adequate but not rich in behavioral context.

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

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

The description is two sentences long, concise, and front-loaded with the core action. Every sentence provides essential information: what it does, the source, the domains covered, and the return value. No wasted words.

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

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

Given the tool is simple (one required parameter, no output schema, no annotations), the description is reasonably complete. It explains the source (curated catalog), the search scope (domains), and the return value (series IDs with descriptions). However, it could mention that the search is limited to popular series (implied by 'curated catalog') to set expectations about coverage.

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 baseline is 3. The description adds a sentence about the return value but does not add meaning beyond the schema for the single 'keyword' parameter. The schema already provides example keywords, so the description does not significantly enhance parameter 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 searches for BLS series IDs by keyword from a curated catalog, listing specific domains (housing, employment, etc.) and stating the return value (matching series IDs with descriptions). It distinguishes itself from sibling tools like bls_get_series (which likely retrieves data for a known ID) and bls_popular_series (which likely returns popular series without search).

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

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

The description explicitly says 'Search for BLS series IDs by keyword', implying it should be used when the user wants to find series by keyword, not for retrieving data or listing popular series. However, it does not explicitly state when not to use it (e.g., when you already have a series ID, use bls_get_series instead).

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 transparency burden. It discloses data sources (SEC EDGAR, FDA) and that it returns paired data + URIs, but omits whether data is real-time/cached, authentication needs, side effects (e.g., no destructive actions), or behavior on missing entities. This leaves notable behavioral gaps.

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

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

Three concise sentences with all critical information front-loaded. The description efficiently covers purpose, parameters, data types, and efficiency benefit without fluff. Every sentence 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?

No output schema exists, so description should clarify return structure. It mentions 'paired data' and URIs but not the format (e.g., keys, unit of values). Also missing error handling (e.g., if entities not found or limit exceeded). Adequate for basic use but incomplete for a comparison 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?

Input schema coverage is 100%, baseline 3. The description adds value by explaining the type's impact on fields retrieved and providing examples for values (tickers/CIKs for companies, drug names). This goes beyond the schema's enum and array constraints, aiding correct parameter construction.

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 compares 2-5 entities side-by-side, specifies data fields for 'company' (revenue, net income, etc.) and 'drug' (adverse-event reports, FDA approvals, trial counts), and mentions the return includes paired data and URIs. It distinguishes from sequential calls, making the purpose 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 says this tool replaces 8-15 sequential agent calls, providing a clear when-to-use context. However, it lacks explicit when-not-to-use guidance or prerequisites (e.g., needing resolved entity names via resolve_entity). While siblings don't overlap significantly, the absence of exclusions is a minor gap.

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

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

No annotations are provided, so the description must disclose all behavioral traits. It states that it returns 'most relevant tools with names and descriptions', which is accurate. However, it does not mention idempotency, auth requirements, or rate limits. Since it is a search tool (non-destructive), the lack of side-effect disclosure is acceptable, but a 3 is appropriate given the absence of annotations and no mention of potential errors or performance.

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

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

The description is two sentences, front-loaded with the core purpose. Every sentence adds value: first sentence defines action, second sentence provides usage context. No fluff.

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

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

Given the low complexity (2 parameters, no output schema, no nested objects), the description is complete. It explains what the tool does, when to use it, and the input format. No return value explanation is needed since the tool's output is implied (list of tools with names and descriptions).

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%, meaning the schema already describes both parameters (query and limit). The description repeats the purpose of the query parameter ('describing what you need') but does not add new semantics beyond the schema. The limit parameter is not mentioned in the description. With full schema coverage, baseline is 3.

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 catalog of tools by natural language description. It specifies the action ('search'), the resource ('Pipeworx tool catalog'), and the input format ('describing what you need'). This distinguishes it from siblings that focus on specific data sources (BLS) or memory operations.

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

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

The description explicitly advises to 'Call this FIRST when you have 500+ tools available and need to find the right ones.' This provides clear when-to-use guidance and implies it should be used before other tools. No exclusions or alternatives are needed as it is the entry point.

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 return format (pipeworx:// URIs) and performance benefit (replaces 10-15 calls). With no annotations, it could mention potential timeouts or auth needs, but is still 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?

Concise four-line description with front-loaded purpose. 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?

Covers return format and included sources. Lacks details on error handling or pagination, but for an aggregation tool this is adequate given no output schema.

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?

Adds meaning beyond schema: explains type enum limitation, value formats (ticker/CIK with examples), and names not supported. Schema coverage is 100% and description enriches it.

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

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

The description clearly states it provides a full profile across multiple packs, listing specific data sources (SEC, XBRL, patents, news, LEI) and distinguishing from 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 advises when to use (for comprehensive profile) and when not (for federal contracts, use usa_recipient_profile directly). Also hints that names require 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?

The description implies a destructive action (Delete) but does not elaborate on what happens after deletion, whether it's reversible, or if there are confirmation steps. With no annotations, the description carries the full burden; it provides minimal behavioral context beyond the obvious.

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 unnecessary words. It front-loads the action and specifies the mechanism.

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 required parameter, no output schema, no nested objects), the description is minimally complete. However, it could mention that the key must exist or what error occurs if not. It is adequate but not thorough.

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 description mentions 'by key', which aligns with the required parameter 'key'. The schema already has a description for 'key' ('Memory key to delete'), and the description adds no further semantic detail. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the action (Delete) and the resource (a stored memory) and the means (by key). It effectively differentiates from siblings like 'recall' and 'remember' which imply retrieval and storage respectively.

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 alternatives. It does not mention prerequisites, side effects, or when not to use it. No mention of alternatives like 'recall' for retrieval.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals a rate limit of 5 messages per day and states 'Free', which implies no cost. However, it does not describe what happens after submission (e.g., acknowledgment, storage, or human review), leaving some uncertainty.

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 four sentences long, front-loads the purpose, and each sentence provides distinct information (purpose, usage, content guidance, rate limit). No filler or 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 simple feedback tool with a clear schema and no output, the description covers purpose, usage, content constraints, and limitations. It could mention what the user should expect after sending (e.g., no guaranteed response), but overall it is sufficiently complete for an agent to invoke 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 input schema has 100% coverage with detailed descriptions for all parameters. The description adds a small extra guideline about describing attempts in terms of Pipeworx tools, but this largely echoes schema hints. Thus, the description adds marginal value beyond the schema.

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

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

The description clearly states the tool sends feedback to Pipeworx, listing specific use cases (bug reports, feature requests, missing data, praise). This distinguishes it from sibling tools that focus on data retrieval, ensuring an agent knows exactly when to use it.

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 and provides a negative instruction (do not include end-user prompt verbatim). It also mentions rate limits. However, it does not explicitly name alternative tools for non-feedback tasks, leaving a minor gap.

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 valuable behavioral context: it walks child markets, searches across events, groups them, checks monotonicity, and returns ranked opportunities with reasoning. No contradictions with annotations.

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

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

The description is well-organized with two paragraphs, front-loaded purpose, and numbered mode enumeration. It is slightly long but every sentence adds value; could be trimmed slightly but maintains 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?

Despite no output schema, the description explains the return value (ranked opportunities with suggested trade direction and reasoning). It covers both modes, behavioral details, and limitations, making it fully complete for its 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% with descriptions for both parameters. The tool description adds substantial meaning beyond the schema by explaining mode behavior, providing examples, and clarifying the difference between event slug and topic. This exceeds the baseline of 3.

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 find arbitrage opportunities on Polymarket by checking monotonicity violations. It explains two distinct modes (event and topic) with specific use cases, and effectively distinguishes from siblings like polymarket_edges by detailing cross-event detection.

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

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

The description provides explicit guidance on when to use each mode: event mode for a single Polymarket event slug, topic mode for cross-event searches. It explains the limitation of single-event mode and the advantage of cross-event mode, though it does not mention alternative tools or when not to use this tool entirely.

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 read-only, non-destructive behavior. The description adds substantial detail: uses a lognormal model from FRED + coinpaprika, scans top markets, fetches price history once, computes probabilities, and ranks by edge. This fully discloses the algorithm and data sources.

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?

Description is a single paragraph that front-loads the primary purpose and efficiently explains the process. Every sentence contributes value, though minor redundancy exists (e.g., 'V1 covers crypto-price bets' could be integrated).

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 three well-documented parameters, no output schema, and openWorldHint, the description covers the algorithm, use case, and output type (top N with trade direction). It could be more specific about return fields, but is adequate for agent guidance.

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 covers all three parameters with clear descriptions. The tool description adds no additional context beyond what the schema provides, so baseline score 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 it scans high-volume Polymarket markets to find where Pipeworx data disagrees with market price, then ranks by edge magnitude. It differentiates from sibling 'polymarket_arbitrage' by focusing on model-driven edge detection.

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 the 'what should I bet on today' question, explaining the process and output. It lacks explicit when-not-to-use or alternatives, but the context is clear and sufficient for an agent to decide.

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

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

With no annotations provided, the description carries full burden for behavioral transparency. It explains the dual behavior (retrieve by key or list all), which is accurate and helpful. However, it does not mention any side effects, performance implications, or access restrictions.

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, consisting of two sentences that convey all necessary information without redundancy. It is front-loaded with the main purpose and provides usage nuance efficiently.

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 (1 optional parameter, no output schema, no annotations), the description sufficiently covers the tool's functionality. It could be enhanced by specifying the format of returned memories or whether list returns keys or full memories, but it is largely complete for its simplicity.

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 the parameter 'key' with 100% coverage. The description adds meaning by explaining that omitting the key lists all memories, which goes beyond the schema's description of 'Memory key to retrieve (omit to list all keys)' by contextualizing the action.

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 'retrieve' and the resource 'memory', distinguishing between retrieving by key and listing all memories. It also clarifies the tool's purpose of accessing saved context, differentiating 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 context on when to use this tool ('to retrieve context you saved earlier') but does not explicitly state when not to use it or compare with alternatives like 'remember' or 'forget'. However, the purpose is well-defined.

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

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

Despite lacking annotations, the description discloses key behaviors: parallel fan-out to multiple sources, accepted input formats (ISO date or relative), and output components (structured changes, count, URIs). It does not mention potential side effects, rate limits, or error handling, but the core read-only behavior is 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 three sentences long, efficiently starting with the core purpose, then detailing behavior for the only supported type, and ending with output format and usage guidance. 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?

Given the tool's complexity (parallel sources, multiple input types) and absence of both annotations and output schema, the description is mostly complete. It explains inputs, outputs, and the fan-out mechanism. It falls short by not addressing error scenarios (e.g., missing entity) or the behavior when no changes exist, but remains sufficient for typical 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?

The input schema has 100% coverage, yet the description adds meaningful details: example formats for 'since' (e.g., '7d', '30d') and a recommendation to use '30d' or '1m' for typical monitoring. It also clarifies that 'type' is currently limited to 'company', which is consistent but validates the enum. This enhances usability 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: fetching what is new about an entity since a given time. It specifies the supported entity type (company) and elaborates on the data sources (SEC, GDELT, USPTO) and output format, effectively distinguishing it from sibling tools like 'entity_profile' which provides static 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 recommends usage for 'brief me on what happened with X' or change-monitoring workflows. It does not list when not to use the tool or explicitly name alternatives, but the context is clear enough given sibling tool names.

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

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

With no annotations, description carries full burden. Clearly discloses behavioral traits: session memory (not permanent storage), persistence conditions (authenticated users vs 24-hour anonymous), and no destructive side effects. Good transparency without 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?

Three sentences, each purposeful: defines action, lists use cases, specifies persistence behavior. Efficiently structured with no waste. Could be slightly more concise by combining sentences, but still clear.

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

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

Given low complexity (2 required params, no output schema, no nested objects), description is complete enough. Covers purpose, use cases, and behavioral nuances. No output schema needed since return is implicit acknowledgment.

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 schema descriptions already define parameters well. Description reinforces usage context and provides example keys, adding semantic meaning beyond schema. No further parameter details 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?

Description clearly states the tool stores a key-value pair in session memory, with specific verb ('store') and resource ('key-value pair in session memory'). Distinguishes from siblings like 'recall' and 'forget' by describing storage purpose.

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 use cases: saving intermediate findings, user preferences, or context across tool calls. Provides context about persistence differences for authenticated vs anonymous users, but doesn't explicitly state when not to use or name alternatives.

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

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

No annotations are provided, so the description carries full responsibility. It discloses that the tool accepts ticker, CIK, or name and returns ticker, CIK, company name, and pipeworx:// URIs. It does not cover failure cases or side effects, but for a look-up tool this is adequate.

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

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

The description is two sentences long. The first states the core purpose, and the second provides supported type, input examples, output format, and efficiency benefit. Every word is useful, and the structure is front-loaded.

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

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

Given the tool's low complexity (2 parameters, one enum with one value) and no output schema, the description is complete. It explains what the tool does, what inputs it accepts, and what outputs it returns, plus a practical note about replacing multiple calls.

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 both parameters fully (100% coverage). The description adds value by explaining that 'type' is currently limited to 'company' and provides concrete examples for 'value' (e.g., 'AAPL', '0000320193', 'Apple'), which helps the agent understand valid inputs.

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

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

The description clearly states the tool resolves an entity to canonical IDs, specifies that v1 supports type 'company', and lists accepted input formats (ticker, CIK, name). This distinguishes it from sibling tools like ask_pipeworx or BLS series 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 mentions that the tool replaces 2–3 lookup calls, implying efficiency gains. It also limits usage to v1 'company' type. While it doesn't list alternatives, the context is clear enough for an agent to decide when to use this tool.

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 responsibility. It reveals the output format (verdict categories, structured form, actual value with citation, percent delta) and the supported claim types. It does not discuss error handling or behavior for out-of-domain claims, but for a v1 tool, this is fairly 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, using four sentences with no wasted words. It is front-loaded with the core purpose, followed by details and value proposition. Every sentence adds essential information.

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

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

Given the single parameter, no output schema, and no annotations, the description is fairly complete. It explains the tool's scope, output, and value. However, it does not address error cases or unsupported claim types beyond the financial domain, which is a minor gap.

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 100% coverage with a clear description for the single 'claim' parameter. The description adds value by providing examples and specifying the domain limitation, which helps the agent understand the expected input beyond the schema's natural-language description.

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

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

The description explicitly states the tool's purpose: fact-check a natural-language claim against authoritative sources, with a specific domain (company-financial claims for public US companies) and sources (SEC EDGAR + XBRL). It clearly distinguishes itself from sibling tools by noting it replaces multiple sequential 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 provides clear context on when to use the tool (for fact-checking financial claims) and contrasts it with a multi-step alternative. However, it lacks explicit exclusions (e.g., not for non-financial claims) and does not mention alternatives among sibling tools.

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