Shibui Finance

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral details about the output (branded headers, smart number formatting, auto-fitted columns) and clarifies that the tool returns a downloadable file, which is beyond the structured 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 three concise sentences, each serving a distinct purpose: stating the main action, differentiating from a sibling, and detailing formatting features. No redundant or extraneous information.

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

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

Given the tool's moderate complexity (2 parameters, output schema present), the description is fairly complete. It explains the output format and relationship with sibling. However, it does not address limitations like file size or handling of empty results, which could be useful.

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 100% description coverage for both parameters. The description adds minor value by linking the query parameter to stock_data_query and specifying the title's purpose, but does not significantly enhance the semantics 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 tool exports query results to a branded Excel spreadsheet. It distinguishes itself from the sibling tool 'stock_data_query' by specifying it returns a downloadable file instead of raw data, and mentions formatting features.

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 that this tool runs the same SQL query as stock_data_query but returns an Excel file, guiding the agent to use it when a formatted spreadsheet is needed. However, it does not explicitly state when not to use it or provide alternative scenarios.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, covering safety properties. The description adds valuable behavioral context beyond annotations: the dataset scope (5,200+ NYSE/NASDAQ companies, 56 technical indicators available) and the critical session lifecycle constraint ('once per session'), which hints at caching/setup behavior not evident from structured hints alone.

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?

Critical constraints are front-loaded effectively ('REQUIRED...'). The enumerated list of financial metrics is lengthy but necessary to define scope. The session prerequisite is clearly stated at the end. No redundant padding, though the density of the financial metrics list impacts readability slightly.

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 and rich annotations, the description appropriately focuses on domain coverage and usage prerequisites rather than return value documentation. The session requirement and explicit data scope (64 years, 5,200+ companies) provide sufficient context for a schema-discovery prerequisite 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 is an empty object with zero parameters. Per the evaluation rules, zero parameters establishes a baseline score of 4. The description implicitly confirms no filtering is possible or required by stating the tool covers the full dataset universally.

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 extensively details when to use the tool (for US stock queries) and what data the underlying database contains (5,200+ companies, 64 years of history), but never explicitly states what the tool mechanically returns—namely, the database schema, table structures, or column definitions. It relies heavily on the tool name to convey the action, making the purpose implied rather than explicit.

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 explicit guidance: specifies 'do NOT use web search for market data' as a negative constraint, enumerates specific query types that trigger use (earnings surprises, technical indicators, sector analysis), and clearly states the prerequisite sequencing 'Must be called once per session before using stock_data_query'. Covers when, when-not, and workflow dependencies thoroughly.

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 idempotentHint=true. The description adds essential context: the tool is required for correct query execution and must follow get_database_schema. No contradiction.

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

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

The description is a single paragraph with front-loaded key requirement, bold emphasis, and no wasted words. Every sentence adds value.

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

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

Given no parameters and an output schema not needing description, the explanation of purpose, prerequisite, content categories, and consequences is complete for agent decision-making.

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, and schema description coverage is 100%. The description correctly adds no parameter semantics, focusing on usage context instead.

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 18 SQL patterns for the database, required after get_database_schema. It distinguishes from siblings by specifying its sequential dependency and listing pattern categories.

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 'Call once per session immediately after get_database_schema' and warns about timeouts/wrong results if not used, providing clear when-to-use and consequences.

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

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

Annotations indicate readOnly and idempotent. Description adds that it 'Contains hard rules for survivorship bias, outlier handling, sampling design, and risk-adjusted metrics,' which explains internal behavior beyond annotations. No contradictions.

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

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

Two efficient sentences. First sentence states purpose; second adds prerequisites and behavioral details. 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 complexity (workflow with output schema and behavioral rules), the description covers usage, prerequisites, behavioral rules, and typical call scenarios. Complete for agent decision-making.

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 input schema (0 params), so baseline is 4. Description does not need to add parameter info; it's trivially covered.

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: 'Load backtesting workflow for signal testing, forward returns, win rates,' with a detailed list of use cases. It distinguishes from siblings like load_comparison_workflow by specifying backtesting context.

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: 'REQUIRES get_database_schema then get_query_patterns to be called first' and when to use: 'Call BEFORE writing SQL when the user asks to backtest...' Provides clear guidance on when to invoke, including specific scenarios.

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?

Adds crucial prerequisite chain (why/when to call get_database_schema first) and workflow combinability that annotations don't cover. Annotations confirm read-only/idempotent safety; description explains the 'workflow loader' behavioral pattern without contradicting safety 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 dense sentences with zero waste: 1) purpose, 2) prerequisites, 3) usage conditions. Front-loaded with clear verb and 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?

Given this is a workflow loader with an output schema (per context signals), the description adequately covers invocation timing, prerequisites, and sibling tool relationships. Only gap is parameter documentation.

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 0% (no descriptions on properties), and the description fails to compensate by explaining the single _content parameter—what it's for, that it contains the workflow template, or that it has a default value containing the full markdown instructions.

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?

Specific verb 'Load' with resource 'comparative analysis workflow'. Explicitly distinguishes from sibling workflow tools by listing unique use cases: 'compare companies, X vs Y, peer benchmarking, sector ranking, or relative valuation'.

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 explicit guidance: states hard prerequisite 'REQUIRES get_database_schema to be called first', temporal ordering 'Call BEFORE writing SQL', specific trigger conditions (comparisons, benchmarking), and combinability 'Can be combined with other workflow 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?

Beyond annotations (readOnly/idempotent), the description adds critical dependency context: the tool 'has no schema' and requires schema retrieval first. It also discloses combinatorial behavior with sibling workflow tools. Minor gap: doesn't explicitly state what content is returned (though output schema handles this).

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 tightly-constructed sentences: purpose statement, prerequisite warning, usage conditions with explicit trigger list, and combinability note. Every sentence earns its place. Front-loaded with critical path (REQUIRES) before descriptive context.

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 presence of output schema (not shown) and complex internal template (visible in default), the description adequately covers tool prerequisites, domain scope, and orchestration rules. Slight deduction for not acknowledging the parameter mechanism, but overall complete for a workflow-loader pattern.

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

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

With 0% schema description coverage and one parameter '_content' (which has a complex default value implying template injection), the description adds zero explanation of what this parameter represents, when to override it, or its semantics. Despite being optional (required: 0), this is a significant documentation gap.

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 'earnings analysis workflow' with 'advanced query patterns' — specific verb and resource. It distinguishes from siblings (load_fundamental_workflow, load_technical_workflow, etc.) by enumerating specific earnings-domain use cases: 'EPS surprises, beat/miss history, earnings estimates, quarterly reporting, or earnings season analysis'.

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 temporal prerequisites ('REQUIRES get_database_schema to be called first'), specific invocation timing ('Call BEFORE writing SQL'), and clear trigger conditions ('when the user asks about earnings results...'). Also notes combinatorial patterns ('Can be combined with other workflow 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, idempotent, non-destructive behavior. The description adds critical behavioral context like the required call order and when it should be invoked relative to writing SQL, which complements the annotations without contradiction.

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

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

The description is well-structured: first sentence states core purpose, second gives prerequisites, third provides extensive usage triggers. It is concise yet informative, with 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 output schema exists, the description covers prerequisites, usage scenarios, and combinability thoroughly. It is complete for a workflow loader with zero parameters and rich annotations.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter semantics, and it does not add any misleading information about parameters.

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

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

The description clearly states the verb 'load workflow' and the resource 'SEC filing workflow', and lists specific subtypes like insider trades, 8-K, Form 4, 10-K. It effectively distinguishes from sibling workflow tools by specifying the domain of filing 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?

Explicitly states prerequisites and order: 'REQUIRES get_database_schema then get_query_patterns to be called first (in that order).' Provides a comprehensive list of user intents that trigger this tool, including specific form names and query types. Also notes combinability with other workflow 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 cover safety profile (readOnly, non-destructive, idempotent). Description adds critical behavioral context: 'this tool has no schema' (unusual trait indicating zero-parameter usage), and clarifies it provides 'advanced query patterns' for subsequent operations. 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?

Four sentences, zero waste: (1) purpose declaration, (2) prerequisite/constraint, (3) detailed usage triggers with examples, (4) combination guidance. Front-loaded with clear operation verb and efficiently 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 this is a complex workflow loader with embedded SQL patterns (visible in schema default), the description successfully orients the agent on when to invoke it and prerequisite dependencies. Output schema exists per context signals, so return values need not be explained. Appropriately complete for a meta-workflow 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 0% (parameter '_content' lacks description). Description partially compensates by mentioning 'advanced query patterns' which maps to the parameter's default content, but does not explicitly document the parameter's purpose or that it should use defaults. Baseline-plus for mentioning patterns, but incomplete compensation for zero coverage.

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?

Specific verb 'Load' + resource 'fundamental analysis workflow' clearly stated. Explicitly distinguishes from sibling workflow tools by specifying unique use cases: 'company valuation', 'financial health', 'is X a good buy', and 'deep-dive company analysis' versus technical or earnings analysis.

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 explicit guidance: states prerequisite 'REQUIRES get_database_schema to be called first', temporal ordering 'Call BEFORE writing SQL', specific trigger conditions (valuation queries, profitability questions), and combination rules 'Can be combined with other workflow tools'. Covers when/when-not/alternatives comprehensively.

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 establish safety (readOnly=true, destructive=false), while the description adds critical behavioral context: the prerequisite dependency on get_database_schema and the fact that this tool 'has no schema' (requires external schema context). It could further clarify what the tool returns (workflow instructions content).

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, each high-value: purpose statement, prerequisite warning, usage triggers with examples, and composability note. No redundancy or waste. Appropriately front-loaded with critical constraints.

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 and the tool's nature as a workflow loader, the description adequately covers invocation prerequisites and use cases. It appropriately omits return value explanations (covered by output schema) but could clarify that the tool loads analytical methodology content rather than raw data.

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

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

With 0% schema description coverage and one parameter (_content), the description does not explicitly explain what the parameter represents. However, the tool has 0 required parameters and the description frames it as a loader, implying the parameter carries the workflow payload. The description compensates minimally by explaining the tool's function.

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 specific action 'Load' and resource 'quantitative screening workflow,' distinguishing it from siblings like load_comparison_workflow or load_earnings_workflow. It specifically identifies screening contexts ('find stocks that...', 'top N by...') that differentiate it from other workflow loaders.

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 explicit guidance: states the hard prerequisite 'REQUIRES get_database_schema to be called first,' specifies exactly when to invoke ('Call BEFORE writing SQL when...'), provides specific trigger phrases, and notes composability ('Can be combined with other workflow tools').

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

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

Annotations declare readOnly/idempotent/destructive hints. The description adds critical context about the prerequisite (database schema) and discloses that the workflow includes specific components (indicator guide, query patterns), but does not address idempotency or caching behavior explicitly.

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 highly information-dense sentences with no waste. Front-loaded with purpose, followed by requirements, then usage triggers. 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 presence of an output schema, the description appropriately focuses on prerequisites and content scope rather than return values. Complete regarding workflow capabilities but lacks explicit parameter documentation.

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 0% (the _content parameter lacks a description field). While the description implies the workflow content (indicators, SQL patterns), it never explicitly documents the _content parameter, its optionality, or that the tool can be invoked with no arguments to receive the default payload.

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

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

The description uses a specific verb 'Load' with a clear resource 'technical analysis workflow', and explicitly lists specific indicators (RSI, MACD, moving averages) that distinguish it from sibling tools like load_fundamental_workflow or load_earnings_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?

Provides explicit prerequisites ('REQUIRES get_database_schema to be called first'), clear timing ('Call BEFORE writing SQL'), specific trigger conditions (user asks about technical indicators), and sibling interaction guidance ('Can be combined with other workflow 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?

The description adds valuable behavioral context not present in annotations: the data scope ('64 years', '5,200+ public companies') and a strict temporal dependency (must call schema first). It aligns with annotations (readOnlyHint) by implying query execution rather than mutation. It does not disclose rate limits or caching behavior, but covers the essential domain constraints.

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 SQL mechanism, but suffers from minor structural issues: the opening line is a fragmented noun list rather than a sentence, and the prerequisite requirement is stated twice ('REQUIRES...' and 'Use this after...'). While the repetition emphasizes a critical dependency, it prevents the text from being perfectly 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?

Given the existence of an output schema (which handles return value documentation) and rich annotations, the description provides appropriate context: it specifies the data universe scope (5200+ companies, 64 years), mandatory prerequisites, and supported analysis types. For a single-parameter SQL interface, this is sufficiently complete to enable correct invocation.

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

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

With 100% schema coverage, the baseline is 3. The description adds significant semantic value by mapping the single 'query' parameter to specific financial use cases ('stock screening', 'fundamental analysis', 'backtesting'), helping the agent understand what SQL constructs to generate. It reinforces the schema's constraint about requiring a LIMIT clause by contextualizing it within the data analysis 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 clearly states the core action ('Run a SQL query') and resource ('64 years of US stock market data'). It distinguishes itself from sibling 'load_*_workflow' tools by emphasizing its raw SQL nature and explicit dependency on get_database_schema. The opening fragment listing data types (prices, earnings, etc.) is slightly unfocused, preventing a perfect score.

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 the critical prerequisite ('REQUIRES get_database_schema to be called first') and reiterates the temporal sequence ('Use this after calling get_database_schema'). It outlines supported use cases (screening, backtesting, comparisons) but could strengthen guidance by contrasting when to use this raw SQL tool versus the higher-level 'load_*_workflow' siblings.

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