Shibui Finance

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

The description does not disclose any behavioral traits beyond annotations, and there is a contradiction: destructiveHint=true but the tool runs an SQL query for export, typically a read operation. No additional behavioral context is 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?

Four sentences, front-loaded with purpose, and each sentence adds value (purpose, relation to sibling, features). No wasteful 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?

With an output schema present, the description need not explain return values. It covers purpose, usage hints, and features. Missing any prerequisites or performance considerations, but overall adequate.

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

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

Schema coverage is 100%, and the description adds useful context beyond the schema: 'Same query used with stock_data_query' for the query parameter and 'Title for the spreadsheet header' for title, enhancing meaning.

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 exports query results to a branded Excel spreadsheet. It specifies the verb 'export' and resource, and distinguishes from sibling tool stock_data_query by noting it returns a downloadable Excel file instead of raw data.

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?

Description explicitly contrasts with stock_data_query, indicating when to use this tool (for Excel output). However, it does not mention when not to use or suggest alternatives beyond the sibling, but the context is clear.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: coverage of 9,500+ companies, 64 years of data, and specific types of data (e.g., technical indicators, SEC filings). No contradictions with annotations. The description enhances transparency beyond annotations.

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

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

The description is longer than necessary, containing repeated instructions ('call FIRST', 'Must be called once') and a verbose list of use cases. While the important info is front-loaded, the redundancy and length detract from 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?

For a tool with no parameters and an existing output schema, the description is comprehensive. It covers the tool's role, scope (9,500+ companies, 64 years), data types, and sequence with sibling tools. No gaps are apparent given the output schema handles return values.

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

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

With zero parameters, schema coverage is trivially 100%. The description does not add parameter-level detail, but none is needed. Baseline of 4 is appropriate given no parameters to document.

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 loads the database schema and is required for US stock queries. However, the purpose is somewhat overshadowed by extensive usage instructions, making the verb+resource slightly less prominent. Still, 'Load Database Schema' from the title and 'authoritative source' clarify the purpose well.

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?

Excellent usage guidance: explicitly states when to use ('US stock/financial queries'), orders as 'call FIRST', specifies prerequisites ('must be called once per session before stock_data_query or any workflow tool'), and tells what to do next ('call get_query_patterns'). Clearly distinguishes from sibling tools by being a prerequisite.

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 readOnly, idempotent, non-destructive. The description adds behavioral context: it is a prerequisite, must be called once per session, and prevents query failures. No contradiction.

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

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

Concise yet comprehensive: 5 sentences covering requirement, timing, content, consequences, and next step. No wasted words, front-loaded with key info.

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 zero parameters, presence of output schema, and clear annotations, the description fully covers the tool's role, prerequisites, and usage flow. Nothing missing.

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?

No parameters to describe; schema coverage is 100% trivially. Baseline for 0 parameters is 4. The description adds value by explaining why no parameters are needed (it loads predefined patterns).

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 loads SQL query patterns required for stock_data_query. It specifies the content (time-series, screening, etc.) and distinguishes from siblings by naming the required call sequence with get_database_schema and stock_data_query.

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 it must be called once per session immediately after get_database_schema and before stock_data_query. Describes consequences of skipping (timeouts/wrong results) and provides clear next step.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it reveals hard rules for survivorship bias, outlier handling, sampling design, day-of-week filters, and risk-adjusted metrics, which explains what the tool does internally without contradicting the safety hints.

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 prerequisites, followed by use cases and internal details. While slightly lengthy due to the list of use cases, each sentence serves a purpose and is well-organized. It could be trimmed slightly but remains effective.

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

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

Given zero parameters, rich annotations, and an existing output schema, the description covers prerequisites, when to call, and what the tool contains. It does not explain the output, but the output schema handles that. The description is sufficiently complete for an agent to decide to 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?

No parameters in the input schema, so the description does not need to add param details. Baseline for zero-param tools is 4, and the schema coverage is 100% (empty schema), so this 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 the tool loads backtesting and simulation guardrails, listing specific metrics and biases (survivorship, drawdown, Sharpe, day-of-week). It distinguishes from sibling workflow tools by specifying use cases like backtesting, simulating, validating strategies, which are unique to this tool.

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

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

Explicitly requires calling get_database_schema and get_query_patterns in order first, and instructs to call before writing SQL for a wide range of backtesting tasks. While it does not explicitly say when not to use, the specific use cases and the mention that it can be combined with other workflows provide clear context for when it is appropriate.

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 and idempotent behavior. The description adds valuable context about prerequisite ordering (requires get_database_schema then get_query_patterns in that order), which is behavioral nuance not captured by annotations. No contradiction.

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

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

Extremely concise: three sentences covering purpose, prerequisites, and usage context. Front-loaded with core action and key examples. No wasted words.

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

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

Given the simple signature (0 params), rich annotations, and output schema, the description provides all necessary context: purpose, when to call, prerequisites, and combinability. Fully sufficient for correct agent invocation.

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

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

Tool has zero parameters, so schema covers all. Description doesn't need to elaborate on param semantics. Baseline of 4 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 loads a comparison workflow for 'X vs Y', peer analysis, and relative valuation. It lists specific user intents (compare companies, 'X vs Y', peer benchmarking) and distinguishes from sibling workflow tools by its specialized focus on comparison tasks.

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

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

Explicitly provides when-to-use criteria (user asks to compare, 'X vs Y', peer benchmarking) and when-not-to-use (should call get_database_schema then get_query_patterns first). Also mentions combinability with other workflow tools. This is exemplary 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?

Discloses required call order (prerequisites) beyond annotations. Annotations already indicate read-only, idempotent, non-destructive; description adds workflow combination hint.

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: purpose, prerequisites, usage. No fluff, 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?

Complete for a zero-parameter workflow loader with output schema. Covers prerequisites and usage scenarios. Could elaborate on workflow internals, but output schema handles return.

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?

No input parameters, so baseline 4. Description adds no parameter info, but schema coverage is 100%.

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

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

Clearly states it loads an earnings workflow for EPS surprises, beat/miss, estimates, revenue. Distinguishes from sibling workflow tools by specifying earnings domain.

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 when to use (earnings-related queries) and prerequisites (get_database_schema, get_query_patterns). Lacks explicit when-not or alternatives, but context is clear.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about the required order of operations and combinability with other workflows, enhancing transparency without contradictions.

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

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

The description is detailed and front-loaded with purpose and prerequisites. While it lists many examples, it remains focused and avoids verbosity, though slightly longer than necessary.

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

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

Given the presence of an output schema (no need to describe return values), zero parameters, and thorough annotations, the description fully covers prerequisites, usage context, and differentiation from sibling tools.

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 tool has zero parameters, so schema coverage is 100%. The description does not need to explain parameters further; it appropriately focuses on the tool's context and 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 the tool loads a workflow for SEC/EDGAR metadata, 8-K events, and 10-K/10-Q reports. It lists specific queries and differentiates from the insider workflow, 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?

Explicitly states prerequisites (get_database_schema then get_query_patterns in order), when to call (before writing SQL for specific queries), and provides an alternative sibling tool for insider transactions. This provides comprehensive usage guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint; description adds value by specifying ordering constraints and the tool's role in a multi-step workflow, but does not mention what the workflow entails beyond loading.

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 conveying essential information without redundancy. Could be slightly more compact, but overall 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 zero parameters and existence of an output schema, the description adequately covers purpose, usage, and prerequisites. It does not explain the output format, but that is expected to be covered by the 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?

No parameters exist, so baseline score is 4. The description does not need to explain parameters.

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

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

Clearly indicates it loads a fundamental analysis workflow for valuation, cash flow, etc. However, it does not explicitly differentiate from sibling workflow tools like load_earnings_workflow or load_technical_workflow.

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 prerequisites (call get_database_schema then get_query_patterns first), specific conditions for use (e.g., 'is X a good buy', financial health), and notes combinability with other workflows.

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, idempotentHint, and destructiveHint. The description adds behavioral context by specifying the required call order and that it's a workflow loader, which implies state preparation.

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 purpose and provides comprehensive details. It could be slightly more concise but 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 has no parameters and an output schema (not shown), the description covers prerequisites, usage scenarios, and combinability. It does not explain return values, but the output schema likely handles that.

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

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

No parameters exist, so schema coverage is 100%. The description adds value by listing the specific insider topics covered, which is not evident from the empty 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 loads an insider workflow and lists specific topics (Form 3/4/5, insider buy/sell, etc.). This distinguishes it from sibling workflow tools like load_earnings_workflow or load_filing_workflow.

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 prerequisites (get_database_schema then get_query_patterns) and provides detailed when-to-use conditions (user asks about insider transactions, etc.). Also notes combinability with other workflows.

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 cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds context about prerequisites and sequencing but does not disclose what the workflow does beyond loading (e.g., state changes or output behavior). With good annotations, the description adds marginal but not rich 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?

Description is concise with front-loaded purpose and specific examples. Minor ellipsis and informal phrasing, but overall efficient and clear.

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

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

Given no parameters and an output schema, the description explains when to use (precursor to SQL, for screening tasks) and prerequisites. It does not detail combination with other tools or output, but the output schema is provided separately, making it mostly 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?

Input schema has 0 parameters with 100% coverage, so baseline is 4. The description adds purpose and usage context, which is sufficient for a parameterless tool.

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

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

The description clearly states the tool loads a screening workflow for finding, filtering, scanning, and ranking stocks, with specific examples. However, it does not explicitly differentiate from sibling workflow tools like load_earnings_workflow, though the examples provide implicit distinction.

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

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

Provides explicit usage scenarios (e.g., 'find stocks that...', 'top 10 by...') and prerequisites (calling get_database_schema then get_query_patterns in order). Lacks explicit when-not-to-use or alternative tool guidance, but the positive usage 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly safe and non-destructive. The description adds behavioral context by specifying the prerequisite order and that it should be called before SQL writing, indicating it sets up a technical analysis context. This adds value beyond annotations.

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

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

The description is moderately concise but contains some redundancy (e.g., listing multiple user query examples). It front-loads the purpose and prerequisites, and the information is well-structured. A slight trim could improve conciseness.

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

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

Given the tool has no parameters and the output schema exists, the description adequately covers the tool's purpose, prerequisites, usage context, and when to call it. It is complete for an agent to select and invoke this 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?

There are no parameters (0 params, schema coverage 100%), so the description does not need to explain parameters. Baseline for 0 params is 4, and the description correctly avoids adding any parameter information since there are none.

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 loads a technical workflow for specific indicators (RSI, MACD, SMA, Bollinger Bands, entry/exit), which is a specific verb+resource. It distinguishes from sibling workflow tools by specifying the technical analysis domain and listing related user queries.

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 (before writing SQL when user asks about listed topics), the required order of prerequisite tools (get_database_schema then get_query_patterns), and that it can be combined with other workflow tools. This provides clear 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?

Description adds critical details beyond annotations: requires shibui. table prefix and LIMIT clause, notes timeout risks, specifies read-only nature. Consistent with readOnlyHint=true and destructiveHint=false.

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

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

Description front-loads purpose with a list but then repeats the call order ('Call get_database_schema once, then get_query_patterns once') twice. Could be more tightly structured without losing clarity.

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

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

Given tool complexity (SQL queries), description covers prerequisites, required syntax, and parameter usage. Output schema exists but description doesn't need to explain returns. Missing some error handling info but points to patterns for 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?

Schema has 100% coverage but description adds value: for 'query' it specifies required prefix and LIMIT; for 'user_prompt' it explains how to handle follow-ups and self-containment, going beyond 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 tool executes SQL queries against US stock market data, listing specific data types (prices, earnings, etc.) and distinguishes it from sibling tools like get_database_schema and load_*_workflow which handle other tasks.

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 REQUIRES calling get_database_schema and get_query_patterns first, warns of timeout/wrong results without them. Lacks mention of when not to use, but the prerequisite order is very clear.

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