Shibui Finance

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

Annotations already indicate destructiveHint: true, but the description does not explain what destructive behavior may occur. It adds output details (branded headers, auto-fitted columns) but does not address the side effects or permissions implied by the annotations. This leaves a transparency gap.

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

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

The description is two sentences, front-loaded with the purpose, and every clause adds relevant information. No fluff or repetition of schema content.

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

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

For a two-parameter tool with a schema and output schema, the description is fairly complete. It mentions the output is a downloadable Excel file and describes formatting. However, given the destructiveHint annotation, a note on side effects or file handling would make it more complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that the 'query' parameter is the same as used with stock_data_query, and provides a concrete example for 'title'. This goes 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?

Description uses specific verb+resource: 'Export query results to a branded Shibui Finance Excel spreadsheet.' It distinguishes from the sibling tool stock_data_query by explicitly stating it runs the same SQL query but 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 provides explicit guidance: 'Runs the same SQL query as stock_data_query but returns a downloadable Excel file instead of raw data.' This clearly contrasts with the sibling tool and indicates when to use this tool (when Excel output is desired) versus the alternative.

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 valuable context about the tool's authoritative scope ('Covers 9,500+ NYSE and NASDAQ companies...') and its session-level prerequisite role, going well beyond what annotations provide.

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

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

The description is front-loaded with the key message 'REQUIRED...call FIRST' and uses clear bullet-like lines. However, there is minor redundancy: 'call FIRST' in the first line is repeated later with 'Must be called once per session,' and the data coverage is stated twice in different forms. Still, it's appropriately sized and readable.

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 a rich output schema already present, the description needn't explain return values. It fully covers the tool's role, data scope, invocation order, and relationship to sibling tools, making it complete for a zero-parameter setup 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 tool has zero parameters, so schema coverage is 100% and no parameter explanation is needed. The description doesn't discuss parameters, but none exist. Baseline 4 applies, and no points are lost since there's no ambiguity to resolve.

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 role as a required first step for US stock/financial queries and an authoritative source for database schema. It lists the covered data (9,500+ companies, 64 years of prices) and distinguishes it from siblings by establishing it as the mandatory precursor before other 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?

Explicit when-to-use guidance is provided: 'Use this tool when the user asks about stock prices, revenue, earnings...' and it names alternatives/sequences: 'Must be called once per session before using stock_data_query or any workflow tool' and 'After this tool returns, call get_query_patterns.' This clearly differentiates it from sibling tools.

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

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

Annotations already provide read-only, idempotent, and non-destructive hints. The description adds valuable context beyond annotations by disclosing that this is a one-time-per-session setup requirement, that it affects stock_data_query behavior, and that omitting it leads to failures. This is meaningful behavioral info not present in structured data.

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, no fluff. The description is front-loaded with the key requirement ('REQUIRED before stock_data_query') and then explains details. Minor redundancy between the first and last sentences (both referencing stock_data_query) slightly reduces conciseness, but it remains 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 the empty schema, present output schema, and rich annotations, the description is largely complete. It explains the tool's position in the session workflow, its purpose relative to siblings, and the consequences of skipping it. The list of pattern categories adds useful scope without overloading. It lacks nothing significant for an AI agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details and instead focuses on the tool's role, which is appropriate for a parameterless setup 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 SQL query patterns that are required before stock_data_query. It differentiates itself from siblings by explicitly positioning it as a mandatory prerequisite in the workflow, and the verb+resource (loads patterns) is concrete.

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?

Explicit when-to-use guidance: must be called once per session immediately after get_database_schema and before stock_data_query. It also states the consequence of not calling it (timeouts/wrong results) and names the follow-up sibling tool, making usage unambiguous.

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 read-only/idempotent annotations, the description reveals internal guardrails (survivorship bias, outlier handling, sampling design, day-of-week filters, risk-adjusted metrics) and the ordering prerequisite, which is useful behavioral context. No contradiction with annotations is present.

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 compact and front-loaded, opening with a summary, then a requirement, then a list of triggering user requests. It is somewhat lengthy but every sentence carries meaningful information without 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 that the tool has no input parameters and an output schema exists, the description fully covers purpose, triggers, prerequisites, and internal rules. It also notes combinability with other workflow tools, leaving no significant gaps.

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

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

The tool has zero parameters, and schema coverage is 100% vacuously. With no parameters to document, the baseline score of 4 applies; the description does not need to add parameter details.

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 that this tool loads a backtesting workflow with guardrails, and enumerates specific use cases (backtest, simulate, validate strategy, compute Sharpe/drawdown, etc.), distinguishing it from sibling workflow tools. The verb 'load' and resource 'backtesting workflow' are unambiguous.

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

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

The description gives explicit when-to-use guidance: call before writing SQL for a long list of backtesting/simulation requests. It also states the prerequisite ordering (get_database_schema then get_query_patterns). However, it does not explicitly name alternative tools or provide when-not-to-use conditions, so it falls short of full marks.

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. Description adds the ordering dependency and position in the query workflow, which is behavioral context beyond annotations. It does not contradict and provides useful operational details.

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

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

Three sentences, each serving a distinct purpose: definition, prerequisites, and usage triggers. Slightly verbose with the trigger phrase list but still efficient and well-structured.

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

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

With output schema present and annotations covering safety, description addresses prerequisites, timing, and combination with other tools. It is sufficiently complete for a zero-parameter loader tool, though it doesn't describe the workflow contents in detail.

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 the schema fully covers semantics. Baseline 4 applies; description need not explain inputs. No additional parameter information required.

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 'Load comparison workflow' for 'X vs Y, peer analysis, relative valuation', naming the specific resource and purpose. It distinguishes from sibling workflow tools by focusing on comparison, with explicit trigger phrases.

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?

Explicit prerequisites: 'REQUIRES get_database_schema then get_query_patterns to be called first (in that order)' and timing: 'Call BEFORE writing SQL'. Also states combinability with other workflow tools, covering both when and how to use.

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 cover read-only, idempotent, and non-destructive hints, so the bar is lower. The description adds non-obvious behavioral context: the required prerequisite calls in strict order and the directive to call before writing SQL. This goes beyond annotations and meaningfully informs the agent.

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

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

The description is concise and well-structured: it opens with the core purpose, then covers prerequisites, usage triggers, and composition with other tools. Every sentence adds value, with no filler or redundancy.

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

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

Given the zero parameters, the presence of an output schema, and strong annotations, the description covers all essential operational details: prerequisites, ordering, when to invoke, and combinability. Nothing critical is missing for an agent to correctly use 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?

The input schema is empty with zero parameters, so the baseline is 4. There are no parameters to document, and the description appropriately avoids adding irrelevant placeholder information. The schema coverage is trivially complete.

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 workflow for specific topics (EPS surprises, beat/miss, estimates, revenue). The verb 'load' and resource are explicit, and the domain-focused topic list distinguishes it from sibling workflow tools. The enumeration of user intents further clarifies its 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 provides strong when-to-use guidance with an explicit list of user queries (e.g., 'did X beat estimates', quarterly earnings) and states a prerequisite call sequence (REQUIRES get_database_schema then get_query_patterns first, in that order). However, it does not explicitly state when not to use or name alternative workflow tools as replacements, so it falls just short of the top tier.

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 significant behavioral context beyond the annotations: it requires get_database_schema and get_query_patterns to be called first in order, must be called before writing SQL, and is scoped to metadata (not transaction detail). No contradiction with readOnlyHint or idempotentHint.

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 information-dense but well-structured: it opens with the core purpose, moves to prerequisites (in order), lists explicit use cases, provides an alternative, and ends with combination flexibility. Every sentence earns its place with no redundancy.

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

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

Given zero parameters, an output schema, and strong annotations, the description is highly complete. It covers purpose, usage triggers, prerequisites, alternatives, and combination options. The output schema handles return values, so no further description is needed.

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 and 100% schema description coverage, so the baseline is 4 per instructions. The description does not need to add parameter details, and it correctly focuses on the workflow's scope.

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

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

The description clearly states the tool loads a workflow for SEC/EDGAR metadata, 8-K events, and 10-K/10-Q reports, using a specific verb and resource. It also differentiates from the sibling tool load_insider_workflow by explicitly noting it handles metadata, not transaction detail.

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 when-to-use guidance with specific triggers ('filing dates', 'who filed', 'SEC filings', etc.) and an explicit alternative ('For insider transaction detail... use load_insider_workflow instead'). It also notes required prerequisite calls and that it can be combined 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 cover readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds meaningful behavioral context by requiring get_database_schema and get_query_patterns to be called first in order, and by stating it can be combined with other workflow tools. This exceeds the baseline for annotation-covered tools.

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 with front-loaded purpose, immediately followed by usage guidance and prerequisites. Every sentence contributes value; no redundancy or 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?

Covers what the workflow includes, when to use it, required prerequisites, and combinability with other tools. Since an output schema exists, the description need not explain return values. For a zero-parameter workflow loader, this description is fully 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?

Tool has zero parameters, so the schema coverage is complete. The description adds no parameter details, but none are needed. With 0 parameters, the baseline score 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 the tool's function: 'Load fundamental workflow for valuation, cash flow, margins, balance sheet.' This specific verb+resource pairing distinguishes it from sibling workflow tools like load_technical_workflow and 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 use cases ('when the user asks about company valuation, "is X a good buy", financial health...'), directs to call before writing SQL, specifies prerequisite order (get_database_schema then get_query_patterns), and notes combinability with other workflows. This is thorough guidance for when to use this tool.

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

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

Annotations already cover readOnlyHint and idempotentHint, and the description adds behavioral context beyond that: the mandatory prerequisite calls ('get_database_schema then get_query_patterns... in that order') and the directive to call 'BEFORE writing SQL'. It also discloses that the tool can be combined with other workflow tools, giving a fuller picture of its behavior.

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?

Despite the length, every sentence adds distinct value: purpose, prerequisites, trigger list, and combination note. The use of 'REQUIRES' and 'Call BEFORE' creates clear structural emphasis, and the information is front-loaded with the main purpose before diving into examples.

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 is simple (0 params) and has an output schema, so the description does not need to explain return values. It fully covers when to invoke, the required sequence of dependent calls, and composability, making it complete for an agent to choose and call this tool without additional guesses.

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, and the schema has no fields to describe. Per the rubric, a zero-parameter tool receives a baseline of 4. The description does not need to explain parameters, and its focus on purpose and usage effectively substitutes for parameter-level detail.

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 states a clear action ('Load insider workflow') and enumerates specific insider-related topics (Form 3/4/5, cluster buy, 13D/G), which distinguishes it from sibling workflow tools like load_filing_workflow or load_screening_workflow. The verb+resource pairing is specific and unambiguous.

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

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

The description provides explicit when-to-use guidance by listing numerous example user queries ('insider buying/selling', '10b5-1 plans', 'who is buying/selling') and a required call order ('REQUIRES get_database_schema then get_query_patterns'). It also mentions combinability with other workflow tools, but does not explicitly name alternative tools or state when not to use this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds important behavioral context: the tool has a mandatory prerequisite sequence and should be invoked before writing SQL. This goes beyond annotation data and helps the agent understand the intended workflow.

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 compact: three sentences covering purpose, prerequisites, and usage timing. It is front-loaded with the main purpose. Minor wording awkwardness ('top N by....') and a slight run-on in the second sentence prevent a perfect score, but it remains 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 the tool has no parameters, an output schema, and complete annotations, the description provides all essential context: what it does, when to use it, prerequisites, and relationship to sibling tools. It even includes examples of user intents that should trigger this tool. No gaps are evident.

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 0 parameters and schema description coverage is 100%. Per the rubric, 0 params yields a baseline of 4. The description adds no parameter details (there are none), so the baseline is appropriate and no deduction 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 opens with a clear verb + resource: 'Load screening workflow to find, filter, scan, rank stocks, top N by...' and then enumerates specific use cases ('find stocks that...', 'top 10 by...', 'best dividend stocks'), which differentiates it from sibling 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?

Explicitly states when to use: 'Call BEFORE writing SQL when the user asks to find, screen, scan, rank, or filter stocks.' It also lists concrete example queries and notes the required call order: 'REQUIRES get_database_schema then get_query_patterns to be called first (in that order).' The addition of 'Can be combined with other workflow tools' gives integration 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?

Beyond the annotations (readOnly, idempotent), the description discloses a critical behavioral dependency: the tool must be preceded by two other calls in a specific sequence. It also states it should be called 'BEFORE writing SQL', adding valuable behavioral context not captured by structured metadata.

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

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

The description is three sentences, but the second sentence is long with an extensive list of trigger phrases. While not overly verbose, it could be slightly tightened. Still, it front-loads the purpose and prerequisites, with no wasted sentences.

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 and zero parameters, the description covers all necessary context: purpose, prerequisites, usage timing, and combinability. It leaves no ambiguity about when to invoke this tool versus alternatives.

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, and the schema coverage is trivially 100%. With no parameters to document, the description doesn't need to add parameter-level meaning, and the 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 'Load technical workflow' and specifies the exact indicators covered (RSI, MACD, SMA, Bollinger Bands, entry/exit). This distinguishes it from sibling workflow tools like load_fundamental_workflow and load_earnings_workflow by naming technical analysis-specific signals.

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?

It explicitly states the required order of prior calls ('REQUIRES get_database_schema then get_query_patterns to be called first (in that order)') and provides concrete trigger phrases for when to use ('when the user asks about RSI, MACD, moving averages, Bollinger Bands...'). It also notes it can be combined with other workflow tools, offering clear guidance on alternatives.

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

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

Beyond annotations that already indicate read-only/idempotent behavior, the description discloses that the tool has no built-in schema/patterns, requires a strict call order, and warns of timeouts or wrong results without prior calls. This adds meaningful operational context.

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

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

The description is concise and well-structured: a domain summary, a one-sentence tool definition, and a clear prerequisites section. Every sentence adds value with 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?

For a tool with an existing output schema and two documented params, the description covers the essential operational context: what data is available, what steps are required, and what can go wrong. The schema covers parameter details, so no important information is 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?

Input schema has 100% coverage and both params (query, user_prompt) are described in detail, including the shibui. prefix and LIMIT requirement. The description supplements this by naming data domains but does not add significant new meaning about parameter usage, earning the baseline score.

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

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

Description states 'Run a SQL query against 64 years of US stock market data', which is a specific verb+resource+scope. It also lists covered data categories and distinguishes itself from sibling tools like get_database_schema and get_query_patterns by noting it has no built-in schema or query 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?

Provides explicit procedural guidance: call get_database_schema then get_query_patterns before using this tool, with warnings about timeouts and wrong results. It does not explicitly name alternatives or say when not to use this tool versus the load_* workflow tools, so it falls just short of a 5.

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