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

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, any rate limits, or side effects. Since it is a calculation tool, it is likely safe, but the description does not confirm this or address any potential limitations.

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 sentence followed by a clarifying second sentence. It is extremely concise, front-loaded with the core action, and contains no unnecessary words 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?

The tool has no output schema, so the description should ideally hint at the output format or values. It only mentions 'future value' without further details. The description is adequate for a simple calculator but lacks completeness regarding the return structure.

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

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

The schema covers all 4 parameters with descriptions (100% coverage). The description adds context about monthly compounding and general applicability, but it does not significantly enhance understanding beyond the schema. The baseline of 3 is appropriate as the schema already provides adequate meaning.

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

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

The description clearly states the tool calculates the future value of a lump sum principal and monthly contributions with monthly compounding. It explicitly mentions it is a general-purpose tool for investment and time deposit simulations, which distinguishes it from sibling tools like 'calculate_required_monthly' that perform reverse calculations.

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 usage for compound interest simulations and mentions it is usable for NISA and general investments, but it does not provide explicit guidance on when not to use this tool or name alternatives. The context is clear but lacks exclusions or comparative statements.

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

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

No annotations are provided, so the description bears full responsibility. It conveys that the tool performs a calculation (read-only, non-destructive) and mentions that current savings are invested with compounding. It does not disclose any other behavioral traits (e.g., exact formula, assumptions, or response format), which is adequate for a straightforward calculator.

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 consists of two concise sentences in Japanese. The first sentence states the function and inputs/output, and the second gives a concrete usage question. There is no wasted text, and it is front-loaded with essential information.

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

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

For a calculator with four numeric parameters and no output schema, the description is sufficiently complete. It explains the input-output relationship clearly. It could be improved by noting assumptions (e.g., compounding frequency), but it is adequate for an agent to understand and invoke the tool correctly.

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

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

All parameters are described in the schema with high coverage (100%). The tool description adds value by clarifying the overall purpose and providing context for the parameters (e.g., 'reverse calculation' and that current savings are compounded). This reinforces meaning beyond the schema.

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

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

The description clearly states the tool's function: reverse-calculate monthly contributions needed to reach a financial goal, given target amount, current savings, annual rate, and duration. It includes an example question, making the purpose unambiguous. This distinguishes it from siblings like calculate_compound_interest (forward calculation) and plan_retirement (broader planning).

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 frames the tool as answering 'how much to save monthly to reach X in N years', which implicitly guides when to use it. However, it does not explicitly state when not to use it or contrast it with siblings. The context from sibling names suggests alternatives, but the description itself lacks direct usage guidance.

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

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

The description discloses that data is manually curated by the operator and covers only half a year. This is useful beyond the schema, revealing limitations in scope and potential staleness. With no annotations provided, the description carries the burden and does so adequately.

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 sentence that efficiently conveys the tool's purpose and data source. It is well-suited for quick scanning, though could be slightly improved by splitting into two sentences for clarity.

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

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

Without an output schema, the description should ideally explain the return format (e.g., fields like date, event name, importance). It only says 'returns major economic events', leaving ambiguity about the structure. For a simple list tool with good parameter coverage, this is acceptable but not 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?

Schema coverage is 100%; both parameters have enum descriptions and defaults in the schema. The description adds no extra parameter semantics beyond what the schema already provides. Baseline score applies.

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 the tool returns major economic events for today or this week, listing specific examples (FOMC, BOJ, US employment statistics, etc.). It distinguishes itself from sibling tools like get_quote or calculate_compound_interest which serve different purposes.

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 usage for retrieving economic events but does not explicitly state when to use this tool versus alternatives. No direct comparison or when-not-to-use guidance is provided. However, sibling tools have distinct names and functions, so ambiguity is low.

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

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

Despite no annotations, the description provides detailed behavioral information: market-specific hours, status values, handling of weekends and holidays, manual curation of holidays, and limitations regarding daylight saving time and unscheduled closures. This is highly transparent.

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

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

The description is two sentences, well-structured, front-loading the core functionality (markets and status types) and then adding details about holidays and limitations. 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 parameters or output schema, but the description fully explains what it returns (status with market-specific times, holiday names) and covers important edge cases (weekends, manual curation, daylight saving gap). It is complete for a simple status 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?

There are no parameters (0 params, schema coverage 100%). The description adds value by explaining the output context, which is sufficient given no parameters need documentation.

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 returns current trading session status (open/pre-open/closed/holiday) for four major markets with specific times. It distinguishes itself from sibling tools by focusing solely on market session status, not on calculations or quotes.

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 usage for checking market sessions but does not explicitly state when to use this tool vs alternatives or when not to use it. However, sibling tools are clearly different in purpose.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the data source (Yahoo Finance), the delay (約1時間遅れ), and a disclaimer (参考値、投資助言ではありません). This provides good transparency about the tool's read-only nature and data limitations, though it does not mention error handling or rate 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 a single paragraph that front-loads the list of indicators, then concisely states the source, delay, and disclaimer. Every sentence adds value, with no redundant or 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 tool has no parameters and no output schema, the description is nearly complete. It explains what the tool does, what data it retrieves, the source, and the limitations. However, it does not describe the output format (e.g., JSON structure), which could be useful for an agent to parse the response.

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 description does not need to add parameter semantics. According to the guidelines, 0 parameters merit a baseline of 4. The description does not repeat schema information, and there are no parameters to document.

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

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

The description explicitly lists all 28 major indicators (e.g., USD/JPY, 日経平均, S&P 500) and states it retrieves their current values and day-over-day changes from Yahoo Finance. This is a specific verb+resource combination that clearly distinguishes it from sibling tools that retrieve individual quotes or sector heatmaps.

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 the tool is for a broad market snapshot, but it does not explicitly state when to use it over alternatives like get_quote or get_market_thermometer. There is no exclusion or alternative naming, so usage guidance is only implied by the tool's scope.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the score interpretation (50 neutral, 70+ risk-on, 30- risk-off) and disclaims it as non-investment advice. It might benefit from noting it is a read-only operation, but overall transparent.

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

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

The description is a single, well-structured sentence that covers components, thresholds, extra details (30-day history), and a disclaimer. It is concise and front-loaded with the main function.

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 no output schema, the description fully covers what the tool returns: a composite score, component scores, and historical data. It also includes a necessary disclaimer. No gaps remain.

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

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

There are no parameters (100% coverage in schema), so the baseline is 4. The description adds no parameter semantics but enriches understanding of the tool's output, which is acceptable given no 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 it returns a composite risk-on/off score (0-100) synthesizing VIX, S&P 500, 10-year yield, and dollar index. It distinguishes itself from siblings that provide raw quotes or snapshots by offering a synthesized indicator.

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 does not explicitly specify when to use this tool versus alternatives like get_market_snapshot or get_quote. It implicitly suggests use as an overview indicator but lacks direct comparisons or exclusions.

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

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

No annotations are provided, but the description discloses important behaviors: the tool only sorts numbers without investment advice, and it has a limitation on periods (1w/1m only support 7 assets). This effectively communicates the tool's non-destructive, read-only nature.

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

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

Two concise sentences: the first explains the core functionality, the second adds important limitations and disclaimer. No superfluous 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?

For a tool with 2 parameters and no output schema, the description explains the scope, limitation, and non-advisory nature. It could be more explicit about the performance metric (e.g., percent change), but the schema's period descriptions partially cover that. Overall, it is complete enough for typical use.

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

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

Both parameters are fully described in the schema (100% coverage). The description adds the context that topN returns both top and bottom, but this is already implied by '上位 N と下位 N'. So the description adds minimal value beyond the schema.

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

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

The description clearly states it sorts 28 assets by performance over a specified period and returns top and bottom N. It specifies the covered asset classes (forex, stocks, rates, commodities, crypto) and distinguishes itself from sibling tools which deal with calculations, quotes, 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 clear context: for 1w/1m periods only 7 main assets are supported, and it explicitly states it is not an investment recommendation. However, it does not directly compare to alternative tools or specify when not to use it.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It clearly states what data is returned (current price, day change, sparkline) and the data source (Yahoo Finance). While it does not detail rate limits or data freshness, the scope is well-communicated. A slightly higher score would require additional context about response format or update frequency.

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 front-loaded: three sentences deliver purpose, usage guidance, and a disclaimer. Every sentence serves a clear function, with no redundancy or unnecessary detail.

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

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

Despite having no output schema, the description adequately covers what the tool returns (current price, day change, sparkline). Combined with the sibling context and single parameter, the description is complete enough for an agent to understand and use the tool correctly.

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

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

The schema already provides a detailed description of the symbol parameter, including examples and format. The description adds no extra meaning beyond what the schema offers. Since schema coverage is 100%, a baseline score of 3 is appropriate without additional compensation.

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 resource: current price, day change, and sparkline for any Yahoo Finance ticker. It explicitly distinguishes itself from the sibling get_market_snapshot by specifying that it handles tickers outside the 9 indicators covered by that tool.

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

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

The description provides explicit guidance on when to use this tool: for checking indicators other than those covered by get_market_snapshot. It also includes a disclaimer about not being investment advice, setting appropriate expectations.

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

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

No annotations are provided, so the description must bear the full burden. It clearly indicates this is a read operation (取得 - get) and specifies the data (current price and day-over-day change). However, it does not explicitly confirm idempotency, mention whether it calls external APIs, or describe any rate limits. The behavior is implied but not fully disclosed.

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 only two sentences, both dense with information. The first enumerates exactly which ETFs are included and what data is returned; the second provides context for use. Every word is purposeful 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?

The tool has no parameters and no output schema. The description identifies inputs and purpose but does not describe the output structure or format (e.g., JSON with ticker, price, change). For a tool this simple, the missing output details reduce completeness. It is adequate but not fully self-contained.

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 adds value by listing the specific ETFs, which effectively defines the fixed scope of the tool, but since there are no parameters to describe, the score meets the baseline.

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

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

The description explicitly states the tool retrieves current prices and day-over-day changes for 11 specific US sector ETFs (SPDR). The verb '一括取得' (batch get) is precise, and the resource is fully enumerated. This clearly distinguishes it from sibling tools like get_quote which likely handles single quotes.

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 notes the tool is a 'source for understanding US stock market sector rotation', implying usage for market analysis. However, it does not explicitly state when to use this versus alternatives like get_quote or get_market_snapshot, nor does it provide any when-not-to-use 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns the spread and day-over-day change in basis points, and characterizes the output as 'reference information'. However, it does not discuss data sourcing, update frequency, or behavior under extreme conditions (e.g., no 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?

The description is two sentences with no wasted words. It front-loads the core function (return spread), provides technical details (symbols, bp), and concludes with practical context (reference for decisions). Perfectly sized.

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

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

Given no output schema, the description explains what is returned (spread value and bp change) and its significance. It could be slightly more explicit about the return format (e.g., decimal or basis points), but the inclusion of 'bp' strongly implies basis points. The simplicity of the tool (no parameters) makes this 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 no parameters (100% coverage trivially), so the baseline is 4. The description adds significant value by explaining what the return value represents (spread, positive/negative yield curve, bp change), which is essential for correct interpretation.

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 returns the yield spread between US 10-year and 5-year bond yields, specifying the exact instruments (^TNX, ^FVX) and explaining the meaning of positive/negative spread. This differentiates it from siblings like get_quote (individual yields) and get_market_snapshot (broader market 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 use for investment decisions related to yield curve analysis but does not explicitly state when to use this tool over alternatives or provide exclusions. The context is clear enough given sibling tools that handle different aspects, but no direct comparison is made.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool runs three scenarios and auto-back-calculates, which indicates a safe, non-destructive calculation. However, it does not mention any data persistence, privacy, or rate limits, though these are less critical for a simulation tool.

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

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

The description is a single, fairly long sentence but is front-loaded with the core purpose and includes key details. It is clear and efficient, though breaking it into multiple sentences could improve readability.

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 description explains the main outputs (future assets, sufficiency under three scenarios, required monthly amount if shortfall) despite lacking an output schema. This covers the essential return values for a planning tool with 8 parameters.

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

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

Schema coverage is 100% with descriptions for all 8 parameters. The description adds value by explaining how risk tolerance maps to three scenarios and mentioning the auto back-calculation feature, which goes beyond the schema's per-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 the tool estimates future assets and retirement fund sufficiency under three scenarios (optimistic/realistic/pessimistic) based on multiple inputs, and auto-calculates required monthly savings if insufficient. This distinguishes it from siblings like calculate_compound_interest or calculate_required_monthly, which are more specific.

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 usage for comprehensive retirement planning but does not explicitly specify when to use this tool versus alternatives like simulate_nisa or calculate_required_monthly. No when-not-to-use guidance is provided.

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

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

No annotations are provided. The description discloses that calculations use monthly compounding, which is a key behavioral trait. It does not mention side effects (likely none), permissions, or error handling. For a simulation tool, this is minimally adequate but lacks explicit safety/behavioral notes.

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

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

The description is two sentences long, front-loaded with the core function. It is concise and free of unnecessary words. Could be slightly more compact by combining sentences, but overall efficient.

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

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

Given the simple parameter set (3 required numbers) and the absence of an output schema, the description adequately conveys the inputs and the computed outputs (future value, profit, annual progression). It mentions monthly compounding, which is a critical detail. Most agents would be able to use this tool correctly.

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

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

The input schema has 100% description coverage, with each parameter already having clear schema descriptions (e.g., monthly contribution, annual rate as %). The tool description adds no additional semantic value beyond paraphrasing the parameters, meeting the baseline expectation.

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 the tool estimates future value, profit, and annual progression using monthly compounding, with a specific verb (試算します) and resource (将来評価額・運用益・年次推移). It mentions NISA/iDeCo use case, but does not explicitly differentiate from sibling tools like calculate_compound_interest.

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 indicates the tool is for simple simulation of NISA/iDeCo, implying a target use case. However, it does not specify when to avoid using this tool or mention alternative tools (e.g., calculate_compound_interest for general scenarios).

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