Shibui Finance

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

Annotations already convey idempotentHint true and destructiveHint false. The description adds details about branding, formatting, and auto-fitting columns, but does not disclose potential side effects, error handling, or file size limits.

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

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

The description is three concise sentences, front-loading the primary purpose and adding relevant details without unnecessary words.

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

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

Given the presence of an output schema, the description adequately explains the Excel file return format and formatting features. It is complete for a straightforward export tool, though it could mention error scenarios.

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 both parameters with clear descriptions (100% coverage). The description reinforces the query parameter's relationship to stock_data_query but does not add new semantic information beyond what the schema provides.

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, and explicitly distinguishes it from the sibling tool stock_data_query by noting it returns an 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?

The description implies when to use (when branded Excel output is desired) and references the alternative stock_data_query for raw data. However, it does not explicitly state when not to use or provide prerequisites.

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 (readOnly, idempotent, non-destructive). Description adds valuable behavioral context: dataset scope (5,200+ companies, 64 years of data, 56 technical indicators) and session lifecycle constraint ('once per session'). 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?

Well-structured with clear paragraph breaks. Front-loaded with critical requirement ('REQUIRED'). Long list of financial terms is justified as it helps the LLM recognize relevant queries. Minor verbosity in the indicators list prevents a 5.

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?

Comprehensive for a schema discovery tool: covers data coverage, prerequisites, sibling relationships, and domain scope. Output schema exists per context signals, so description need not explain return values. Zero parameter count means no parameter documentation burden.

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 zero parameters, setting baseline 4. Description correctly omits parameter discussion since none exist, and does not invent nonexistent constraints.

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 indicates this is a schema retrieval tool for US financial data, though it never explicitly states 'Returns the database schema' or similar verb phrase. The purpose is inferred from 'REQUIRED for... queries' and the tool name, with strong differentiation from siblings via the prerequisite instruction.

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?

Exemplary guidance: explicitly states when to use ('US stock/financial queries'), when NOT to use alternatives ('do NOT use web search'), and provides precise sequencing ('Must be called once per session before using stock_data_query or any workflow tool'). Lists specific financial use cases (EPS, P/E ratios, technical indicators) to trigger selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds crucial context: the tool contains exactly 18 patterns and is essential for correct query results. It does not contradict 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 extremely concise: two sentences plus a warning. Every sentence is essential and front-loaded with the requirement. 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?

The tool has no input parameters and an output schema exists. The description covers when to use, why it's important, and what it contains. It does not detail the output format, but that is handled by the output schema. Complete enough for effective use.

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

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

No parameters exist (0 params) and schema description coverage is 100%. Following the rule for 0 parameters, baseline is 4. The description does not add parameter info because none are needed.

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

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

The description clearly states it provides '18 SQL patterns for this database', with title 'Load Query Patterns'. The verb 'load' is implied and the resource is well-defined. It distinguishes from siblings like 'get_database_schema' and workflow loaders by its specific 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?

The description explicitly states it is 'REQUIRED after get_database_schema' and to 'call once per session immediately after'. It provides a clear prerequisite and warns of consequences ('Queries will timeout or return wrong results without these patterns'). No alternative is needed as it's a required 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context beyond annotations: contains hard rules for survivorship bias, outlier handling, sampling design, and risk-adjusted metrics. No contradiction. Adds value by specifying internal logic without contradicting 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?

Description is moderately sized and front-loaded with main purpose. Every sentence adds value (prerequisites, use cases, behavioral traits). Could be slightly more terse but not excessively wordy. Structure is logical.

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, annotations covering safety, and presence of output schema (not shown but context states it exists), the description is complete. It explains prerequisites, when to use, and internal rules. Return values are covered by 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?

Input schema has zero parameters, so schema description coverage is 100% by default. The description does not need to add parameter info. Baseline for 0 parameters is 4. No additional semantic value needed.

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

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

The description clearly states the tool loads a backtesting workflow for signal testing, forward returns, win rates, etc., and distinguishes it from other workflow tools by mentioning its hard rules for survivorship bias, outlier handling, etc. It also explicitly lists use cases (e.g., 'when the user asks to backtest, test a strategy'). The purpose is specific and distinct from siblings.

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

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

Explicitly states prerequisite calls in order: 'REQUIRES get_database_schema then get_query_patterns to be called first (in that order).' Also provides when to call ('before writing SQL') and lists multiple scenarios. No exclusions but strong guidance; alternatives are implied by 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?

Annotations declare readOnly/idempotent safety profile; description adds critical behavioral context that this 'has no schema' (requires external schema loading) and exposes composability with other workflows. Captures dependency graph information not present in 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 efficient sentences with zero redundancy: (1) purpose definition, (2) hard prerequisite, (3) usage conditions and timing, (4) composability note. Front-loaded with action verb and appropriately sized for the tool's complexity.

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 (return values need not be described) and rich annotations, the description adequately covers the tool's role in the workflow chain. Only gap is the lack of explicit parameter documentation given 0% schema coverage, though the default value compensates practically.

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 0% description coverage for the _content parameter. Description mentions 'advanced query patterns' which semantically maps to the SQL examples in the parameter's default value, providing minimal grounding. However, it fails to explicitly document that _content contains the workflow definition/instructions or explain the parameter's role in the tool's operation.

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 uses specific verb 'Load' with resource 'comparative analysis workflow' and clearly distinguishes from siblings by enumerating specific use cases: 'compare companies', 'X vs Y', 'peer benchmarking', 'sector ranking', or 'relative valuation'. Immediately contrasts with load_earnings_workflow, load_fundamental_workflow, etc.

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 prerequisite chain ('REQUIRES get_database_schema to be called first'), temporal ordering ('Call BEFORE writing SQL'), specific trigger conditions (comparison queries), and sibling interaction pattern ('Can be combined with other workflow tools'). Covers when-to-use and prerequisites 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 declare readOnly/idempotent/destructiveHint=false. The description adds critical behavioral context: 'this tool has no schema' (explains external dependency), 'Can be combined with other workflow tools' (interaction pattern), and implies it provides methodology rather than raw data. Could better clarify that it returns/guides the SQL workflow 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?

Three sentences, zero waste. Front-loaded with purpose, followed by hard requirement (REQUIRES), usage timing (BEFORE), trigger examples, and combinability. Strategic capitalization draws attention to critical sequencing constraints without verbose explanation.

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 complex workflow nature and presence of output schema, the description appropriately focuses on usage prerequisites and domain scope (earnings-specific). It correctly notes the schema dependency gap. Could improve by stating that the tool populates the analytical context with SQL patterns/workflows, but the content is largely complete for agent selection.

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 description). The description compensates partially by explaining what the workflow contains ('advanced query patterns', SQL examples implicitly), but never mentions the _content parameter or explains that the workflow definition is passed/loaded via this parameter. Baseline 3 for high schema coverage not met; description explains concept but not parameter mechanics.

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 'Load[s] earnings analysis workflow with advanced query patterns' — specific verb (load) and resource (earnings workflow). It distinguishes from siblings (load_comparison_workflow, load_technical_workflow, etc.) by specifying 'earnings' and listing earnings-specific use cases (EPS surprises, beat/miss history). Minor deduction because 'load' could ambiguously mean 'execute' vs 'retrieve instructions', though context clarifies.

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 guidance: explicit prerequisite ('REQUIRES get_database_schema to be called first'), clear timing ('Call BEFORE writing SQL'), specific trigger conditions ('when the user asks about earnings results, EPS surprises...'), and combinability note ('Can be combined with other workflow tools'). Provides complete decision framework for the agent.

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, destructiveHint=false, and idempotentHint=true. The description does not contradict these, but adds no behavioral details beyond what annotations provide. With complete annotations, a score of 3 is appropriate.

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

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

The description is two sentences: first states purpose, second gives prerequisites and usage triggers. It is front-loaded with the core function and contains 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 an output schema exists and the tool has no parameters, the description covers prerequisites, usage triggers, and combinability. It lacks a brief note on what 'load' entails (e.g., initializing a session), 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?

The input schema has zero parameters, so there is nothing to document. With 100% schema coverage and no params, the baseline of 4 is correct. The description does not add param info, but none is needed.

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

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

The description clearly states the tool loads a filing workflow for SEC/EDGAR queries, listing specific form types and insider trades. It distinguishes from siblings by being one of several workflow tools, with a focused 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?

The description explicitly requires calling get_database_schema and get_query_patterns first, in order. It provides a comprehensive list of user request types indicating when to use this tool, and notes it 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?

Adds critical dependency context beyond annotations: discloses that the tool lacks database schema ('this tool has no schema'), explaining the hard prerequisite. Annotations cover safety (readOnly/idempotent), while description adds functional context about query patterns and workflow structure.

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?

Perfectly structured and front-loaded: 4 sentences covering purpose, prerequisite, trigger conditions, and combinability. No redundancy, no tautology, every clause 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?

Complete for a workflow tool: covers prerequisites, usage timing, and sibling relationships. Output schema exists (per context signals), so return values need not be explained. Could slightly improve by explicitly stating it returns workflow instructions, but adequate given 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 has 0% description coverage for the single `_content` parameter. Description partially compensates by characterizing the content ('advanced query patterns', 'workflow'), but does not explicitly explain that `_content` contains the workflow template or how the parameter should be used. Baseline 3 appropriate given some semantic hints 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?

Excellent specificity: verb 'Load' + resource 'fundamental analysis workflow' + distinguishes from siblings (technical, earnings, comparison, screening workflows via explicit 'fundamental' scope). Mentions 'advanced query patterns' to differentiate content type.

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?

Exceptional guidance: explicit prerequisite ('REQUIRES get_database_schema to be called first'), explicit trigger conditions ('when the user asks about company valuation...'), ordering constraint ('Call BEFORE writing SQL'), and combination 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?

Annotations cover read-only/idempotent safety. Description adds crucial behavioral context: explains prerequisite chain (why get_database_schema is needed), warns 'this tool has no schema', and clarifies its role in the SQL generation workflow. Could add what the output contains (SQL templates, pitfalls).

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?

Perfectly structured: action statement, prerequisite warning, usage triggers with examples, and integration note. Four sentences with zero redundancy, front-loaded with the most critical information (what it does and requires).

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?

Strong coverage given complexity: explains when/why to use, prerequisites, and sibling relationships. Output schema exists so return values need not be described. Minor gap: does not summarize what the loaded workflow contains (e.g., 'returns SQL templates and screening guidelines').

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). Description mentions 'advanced query patterns' vaguely but fails to explicitly document that _content contains the workflow document, that it has a default value with embedded SQL templates, or what valid inputs might be. Insufficient compensation for zero schema 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?

Clear specific verb ('Load') + resource ('quantitative screening workflow'). Explicitly distinguishes from sibling workflow tools by specifying 'screening' context and noting it 'Can be combined with other workflow tools', placing it within the suite of load_*_workflow 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?

Excellent explicit guidance: states prerequisite 'REQUIRES get_database_schema to be called first', specifies exact trigger phrases ('find stocks that...', 'top N by...'), and defines temporal relationship ('Call BEFORE writing SQL'). Also notes combinatorial usage with other 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 hints. The description adds crucial behavioral context not in annotations: this tool has 'no schema' (requires prior schema fetch) and loads interpretive guidance rather than executing queries. It appropriately sets expectations about workflow sequencing.

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 total, each earning its place: purpose (sentence 1), prerequisite (sentence 2), usage triggers (sentence 3), and sibling relationships (sentence 4). Information is front-loaded and dense 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 presence of an output schema and read-only annotations, the description appropriately covers workflow purpose, prerequisites, and activation conditions without needing to detail return values. The extensive list of technical indicators covered ensures the LLM knows when this tool is relevant.

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% description coverage and provides only a '_content' string property with a complex default value. The description fails to explain the parameter's purpose, valid values, or that it can be omitted to use the default workflow guidance. With low schema coverage and no compensating description, this is under-specified.

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 ('Load') and resources ('technical analysis workflow', 'indicator interpretation guide', 'advanced query patterns'). It clearly distinguishes from siblings like 'load_fundamental_workflow' and 'load_earnings_workflow' by specifying technical analysis domains (RSI, MACD, chart patterns).

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 to be called first'), timing ('Call BEFORE writing SQL'), trigger conditions (specific list: RSI, MACD, moving averages, support/resistance, etc.), and combination rules ('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 the readOnlyHint/idempotentHint annotations, the description adds crucial context: the data scope ('64 years', '5,200+ public companies'), available data types (prices, earnings, P/E), and the prerequisite chain ('this tool has no schema'). It correctly aligns with annotations by emphasizing 'Read-only SQL' in the parameter description. It does not disclose rate limits or pagination behavior, preventing a 5.

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 generally efficient but has minor structural issues. The opening line is a keyword list without verbs ('Stock prices, earnings...'), which is less effective than a proper sentence. There is slight redundancy between 'REQUIRES get_database_schema to be called first' and 'Use this after calling get_database_schema,' though the emphasis on prerequisites is appropriate.

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 (covering return values) and clear annotations (covering safety properties), the description appropriately focuses on prerequisites and data scope. It adequately addresses the tool's complexity by warning about the schema dependency and documenting the historical data range. A 5 would require explicit error handling guidance or rate limit disclosure.

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 description coverage for the single 'query' parameter, the schema already documents the SQL requirements ('Requires shibui. table prefix and a LIMIT clause'). The description does not add parameter syntax, examples, or validation rules beyond what the schema provides, meriting the baseline score for high-coverage schemas.

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 this as a SQL query tool against stock market data ('Run a SQL query against 64 years of US stock market data'). However, while it implicitly distinguishes itself from workflow siblings by mentioning SQL, it doesn't explicitly clarify the relationship between this low-level SQL interface and the higher-level 'load_*_workflow' siblings that cover identical functional domains (screening, comparisons, etc.).

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 sequencing guidance ('REQUIRES get_database_schema to be called first') which is valuable. However, it fails to differentiate when to use this SQL tool versus the five sibling workflow tools (load_screening_workflow, load_comparison_workflow, etc.) despite listing identical use cases ('Supports stock screening...comparisons'). An agent cannot determine whether to use the workflow wrapper or raw SQL.

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