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

No annotations are provided, so the description carries the full behavioral burden and discloses almost nothing. It does not say the tool is a side-effect-free computation, how the year fraction is derived (365-day vs. actual days), what happens when start_date equals end_date, or whether non-positive values are rejected.

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?

A single front-loaded sentence fragment with zero waste, but it is terse to the point of under-specification for a four-parameter tool with no other documentation.

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?

An output schema exists, so return-value explanation is not required. Still, with 0% schema coverage and no annotations, the description should do more to specify date formats and edge-case behavior for a 4-required-parameter computation.

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 description coverage is 0% — the four parameters carry only bare titles with no format hints. The description only loosely maps its phrasing ('two values', 'date range') to initial_value/final_value and start_date/end_date, and adds nothing about date string format or value 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?

Names a specific computation (CAGR) and the inputs it operates over (two values, a date range), so an agent immediately knows what it produces. It does not, however, distinguish itself from the closely related sibling calculate_xirr, which computes a different return rate over cash flows.

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?

There is no when-to-use or when-not guidance. The agent must infer that this is for a single start/end pair rather than irregular cash flows (which is calculate_xirr's domain) purely from the name and parameters.

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, so the description must carry behavioral disclosure. It does state the computed outputs and the amortization convention, but says nothing about assumptions the result depends on — currency/units of principal, whether rate is nominal annual compounded monthly, rounding, or whether all three outputs are always returned.

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?

A single terse sentence, front-loaded with the primary output and trailing the method qualifier. Zero padding, though it is terse to the point of omitting needed unit context.

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

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

An output schema exists, so return values need not be described. However, with three fully undocumented parameters and no annotations, the definition leaves unit and rate-convention assumptions unstated for what is otherwise a simple deterministic calculator.

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 description coverage is 0% and the description never mentions any of the three parameters. The schema titles ('Principal', 'Annual Rate Pct', 'Years') give the names but no unit conventions (e.g., percent vs decimal, years vs months), and the description does not compensate.

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?

Names the resource (loan EMI) and the three computed outputs, plus the interest method (reducing balance), which cleanly separates it from deposit calculators like calculate_fd or calculate_rd. It is a noun phrase with no verb, but the intent is 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?

No explicit when-to-use or when-not-to-use statement, and no routing to siblings such as calculate_fd for deposits. The 'reducing balance' qualifier implicitly scopes it to reducing-balance amortizing loans rather than flat-rate loans.

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 explicitly states a critical behavioral trait: the compounding frequency is quarterly by default. Since there are no annotations, this is essential context that informs the agent's expected output logic.

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 single sentence is highly efficient, front-loading the primary purpose and the default calculation behavior without unnecessary 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?

It covers the necessary calculation logic (outputs and default compounding), but lacks input context, leaving the agent to rely heavily on the schema definitions for unit clarification and parameter meaning.

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

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

With 0% schema description coverage, the description provides almost no semantic guidance on the parameters (e.g., unit of principal, what 'years' represents beyond a number). It describes the outcome, not the input variables.

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 the resource ('Fixed deposit') and the specific outputs ('maturity amount and effective yield'). It is highly distinct from the wide variety of sibling tools, such as SIP or CAGR calculators.

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 correct usage context (FD calculations), but it does not explicitly state when to use this tool versus other related calculation siblings (e.g., when to use this over a generic interest calculator).

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 burden. It usefully discloses the key assumption of a constant annual return and a one-time investment, but it omits important behavioral details such as compounding frequency and whether fees or taxes are ignored.

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, front-loaded sentence with no filler. Every word contributes to identifying the calculation.

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 simple calculator with 3 required parameters and an output schema, the description is minimally adequate. However, it leaves out compounding frequency and parameter-unit details that would help an agent 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?

Schema description coverage is 0%, so the schema has only bare titles. The description implicitly maps one-time investment to principal and constant annual return to expected_return_pct, but it does not explicitly explain units, formats, or the role of the years parameter.

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 specific calculation: future value of a one-time investment at a constant annual return. This clearly distinguishes it from periodic-investment siblings like project_sip and calculate_sip_returns, though it does not explicitly name alternatives.

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 no explicit when-to-use or when-not-to-use guidance. An agent can infer it is for lump-sum future value calculations, but there is no direction on choosing between this and related tools such as calculate_fd or project_sip.

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 exist, so the description carries the full burden. It does disclose a meaningful behavioral trait beyond the schema: quarterly compounding, which determines the actual math and differs from other calculators in the family. It says nothing about whether the result includes a principal/interest breakdown or assumes a fixed rate throughout.

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?

A single compact sentence with the key qualifier front-loaded; nothing is wasted. Brevity here borders on under-specification rather than verbosity, so it is not a flaw of structure.

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 zero-coverage, zero-annotation, three-required-parameter financial calculator, the description is too thin. An output schema exists so return values needn't be explained, but units, rounding, and the handling of non-quarter-aligned month counts are all left unaddressed.

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 description coverage is 0% and all three parameters (monthly_deposit, annual_rate_pct, months) are undocumented in the schema. The description only indirectly clarifies that annual_rate_pct is a nominal annual rate compounded quarterly; it never states currency, that months may be non-multiples of three, or how partial quarters are handled.

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 names the specific computation - recurring deposit maturity amount - and the compounding convention (quarterly), which is enough to separate it from calculate_fd or calculate_emi. It is a noun phrase rather than a verb+resource statement, but the resource is 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?

There is no explicit guidance on when to pick this over calculate_fd, calculate_sip_returns, or project_sip, nor any stated prerequisites (e.g. that deposits are monthly and fixed). The only cue is the word 'recurring', which the agent must infer means recurring-deposit products.

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 behavioral burden. It usefully discloses the output fields (invested amount, units, current value, absolute return, XIRR), the end_date default, and accepted date formats, but omits whether the call makes a live data fetch, what happens for an invalid or delisted scheme_code, and whether the operation is side-effect free.

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 short lines, front-loaded with the purpose, then the return values, then the operative defaults and formats. No filler and nothing important buried at the end.

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?

An output schema exists, so explaining return values is optional (and here slightly redundant); the real gaps are elsewhere — the provenance of scheme_code, error behavior on missing NAV data, and how the monthly installment dates roll from start_date are all unstated. Adequate but not sufficient for a numeric simulation tool with zero annotation and zero schema-doc support.

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 description coverage is 0%, so all four parameters are undocumented in the schema. The description compensates for end_date (defaults to today) and start_date (accepted formats) and implies monthly_amount via 'monthly SIP', but leaves scheme_code completely unexplained — an agent is not told it must come from search_schemes.

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?

States a specific verb and resource — 'Simulate a monthly SIP in a scheme using its real NAV history' — which is concrete enough for an agent to act on. It implicitly separates itself from the forward-looking 'project_sip' by emphasizing real NAV history, but never names that sibling, so full differentiation is left to inference.

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?

Usage is only implied: 'real NAV history' hints this is the historical/backtest counterpart to project_sip, but the description never states when to pick this over project_sip, calculate_lumpsum_value, or calculate_xirr, nor any prerequisites such as needing a valid scheme_code.

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, yet it discloses nothing about assumptions: withdrawal timing (start/end of month), compounding convention, whether returns are nominal/annual, or whether the result is deterministic. It does at least imply the output concerns survival and remaining balance, but an agent cannot predict the calculation model.

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?

A single tight sentence with the key output questions front-loaded; nothing is padded. It is efficient, though the brevity comes at the cost of the missing specification noted elsewhere.

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?

Four required parameters, zero annotation coverage, and no parameter documentation: the description would need to state input units/conventions and the calculation assumptions to be callable with confidence. An output schema exists, so return-shape explanation is not required, but the input-side gaps are significant.

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 description coverage is 0% — the four required parameters carry only titles. The description adds no unit or format information: currency scale of corpus and monthly_withdrawal, and crucially whether expected_return_pct is 12 or 0.12, are left unstated. Titles alone are only marginally self-explanatory.

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 names the domain (systematic withdrawal plan) and frames the two questions the tool answers — corpus longevity and residual amount — which distinguishes it from accumulation tools like project_sip or calculate_lumpsum_value. However, it never uses a concrete verb ("calculates") and the question-style phrasing leaves the operation itself implicit.

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?

There is no guidance on when to use this versus siblings such as project_sip (accumulation) or plan_retirement, nor any stated preconditions. The only routing signal is the domain name itself.

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?

Since no annotations were provided, the description carries the full burden. It excels here by defining the sign convention for financial flows (Investments are negative, redemptions positive), which is critical behavioral information not captured in the generic input schema.

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 definition is highly efficient, using two sentences to provide the core function and all necessary input constraints (sign convention and structure) without introducing 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 requiring a complex nested array of specific financial objects, the description provides all necessary structural and behavioral information (sign conventions, required fields, date format). Since an output schema exists, the focus on input completeness is appropriate and fully satisfied.

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?

Given the input schema provided almost zero structural information (0% coverage), the description is vital. It explicitly defines the required properties for each item in the 'cashflows' array (date and amount) and specifies the expected date format.

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 purpose is immediately clear and identifies the specific calculation (XIRR) and its required data structure (dated cash flows). It is distinct from the other financial calculation tools in the sibling list.

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 input format constraints (date and amount) which implicitly guides usage. While it doesn't explicitly compare itself to all siblings, the strict requirement for 'dated' flows sets a clear usage context.

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 bears the full burden of transparency. It explains the functional impact ('so the next call fetches fresh NAVs') and the constraint (24-hour cache limit), adding high-value behavioral context.

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

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

The description is highly efficient. Both sentences provide crucial, distinct pieces of information (what it clears and when to use it) with zero 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 that this is a zero-parameter tool, the definition is maximally complete. It informs the agent when, why, and how this tool functions in the broader data retrieval workflow.

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?

Since there are no parameters, the baseline score of 4 applies. The description adds value by defining the nature of the data being acted upon (AMFI data) rather than just leaving the action undefined.

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

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

The description clearly states the tool's purpose: to 'Clear cached AMFI data.' This is a specific action that clearly distinguishes it from the sibling data retrieval and calculation 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?

It provides critical usage context by defining the cache lifespan (24 hours) and giving specific timing advice ('clear the cache after [9 PM IST]') based on external data publication schedules.

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. It does useful work by disclosing the returned metrics, the 1–5 fund cap, and the null-if-too-new behavior, but it never states that the call is read-only, what happens if more than 5 codes are passed, or how lookup failures are reported.

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

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

Two sentences, front-loaded with the core action and scope, then a compact enumeration of what each fund contributes. No filler and no repetition of schema metadata.

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?

An output schema exists, so the description need not enumerate return fields, yet the required scheme_codes argument and the over-limit error path remain undocumented. Adequate for a simple read tool, but the required-parameter gap keeps it at minimum viable.

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%, so the description should compensate more than it does. It explains risk_years as the window for volatility/drawdown/Sharpe and implies risk_free_rate_pct via 'Sharpe ratio', but leaves the required scheme_codes parameter (format, source, uniqueness) entirely undefined.

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?

States a specific verb and resource ('Compare ... mutual funds side by side') and quantifies the scope (1 to 5). The multi-fund framing implicitly distinguishes it from single-fund siblings like get_scheme_quote and get_scheme_details, but no sibling is named explicitly.

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 'side by side' phrasing implies the comparison use case, and the return list hints at what you get instead of single-fund data. However, there is no explicit when-to-use/when-not, no mention of the alternative single-fund tools, and no prerequisite such as obtaining scheme codes from search_schemes first.

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 and does well: it discloses the rate logic (20% STCG, 12.5% LTCG above remaining exemption, slab rate for debt/other) and two important scope limits ('Excludes surcharge and loss set-off') plus a professional-confirmation caveat. It does not state precision/rounding behavior or that results are estimates only in a numeric sense, so not 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?

Four tight sentences, front-loaded with purpose, then input modes, then rate rules, then caveats — no filler. Slightly telegraphic in places ('remaining annual exemption'), but every sentence carries decision-relevant 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 an 8-parameter, unannotated estimation tool with an output schema present, the description covers the inputs that matter for correctness (holding period determination, fund classification, exemption handling) and the known omissions (surcharge, set-off). Only minor gaps remain around defaults and validation of date formats.

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%, so the description must compensate, and it does: it explains the holding_days vs. purchase_date/sale_date trade-off, reveals the accepted fund_type values ('equity', 'debt', 'other') that the schema leaves as an unconstrained string, and clarifies that slab_rate_pct applies to debt/other and that ltcg_exemption_available is a consumable annual exemption. purchase_amount/sale_amount are self-evident, though defaults (slab_rate_pct=30, exemption=125000) are not restated.

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?

States a specific verb and resource ('Estimate capital gains tax on a mutual fund redemption') plus the governing rule set (FY 2026-27). This is clearly distinct from sibling calculators like calculate_xirr or calculate_sip_returns, which compute returns rather than tax liability.

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 tells the agent how to supply the holding period: 'Supply holding_days, or both purchase_date and sale_date for exact calendar holding-period classification.' It gives clear input-selection guidance but does not name when to prefer this tool over siblings or note prerequisites such as the need for a redemption scenario.

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. Saying 'Latest level' usefully signals a current snapshot rather than a time series, but it says nothing about data freshness (live vs delayed), rate limits, or failure behavior when an invalid index is supplied.

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?

One sentence, front-loaded with the verb and resource, then the enumeration. 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?

An output schema exists so return values need not be described, and the parameter values are fully enumerated. Only the data-freshness and default-value details are missing, which are small for a single-parameter lookup tool.

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

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

Schema coverage is 0% and the 'index' property has no enum or description, so the description must compensate — and it does by listing the five accepted values, which is exactly what the agent needs. It doesn't mention the 'nifty50' default, a minor omission.

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?

States a specific verb (return latest level) and resource (Indian index), and enumerates the five supported indices. The resource noun separates it from get_stock_quote and get_scheme_quote, though it never explicitly says so.

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?

Usage is only implied: the tool is evidently for fetching a current index snapshot, and the valid values are given. There is no explicit when-to-use, no exclusion of historical data (unlike get_stock_history/get_nav_history), and no mention of 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?

Without annotations the description carries the full burden, and it delivers a genuinely non-obvious behavior: responses are silently truncated to the most recent `max_points` within the range, which prevents an agent from assuming full-range data. It also discloses accepted date formats. Gaps remain on what happens when start/end are omitted (schema default null is unexplained) and whether NAV is adjusted.

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 short sentences, zero filler, with the resource scope front-loaded and the truncation caveat immediately after. Every sentence 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?

An output schema exists so return values need no explanation, but with no annotations and 0% schema coverage the description should also state default-range behavior when dates are null and how to obtain a scheme_code. Adequate for a simple read, but leaves real decisions to inference.

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 description coverage is 0%, so the description must compensate — and it does for most params: it names the two accepted date formats for start_date/end_date and clarifies that max_points caps the most recent points, not arbitrary ones. It does not explain the semantics of null dates or where scheme_code comes from.

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?

States the resource precisely ('NAV history for a scheme') and implicitly the operation (retrieve). An agent can distinguish it from get_scheme_quote (current price) and get_scheme_details by the 'history' term, though it never explicitly contrasts with siblings like get_stock_history.

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?

No guidance on when to use this versus get_scheme_quote, get_scheme_details, or get_rolling_returns, and no exclusions or prerequisites. The only implied usage comes from the tool name itself.

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. It does disclose the valuation basis (latest NAVs), which is the key behavioral trait, and the input shape example. It does not say whether NAVs are live or cached, what happens if a scheme_code is invalid or delisted, or whether the call does any network/IO — meaningful gaps for a data-fetching 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?

Two short sentences plus a concrete example, all front-loaded with no filler. The example is the highest-value content and it is placed immediately after the purpose statement.

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 output schema exists, so return values need not be explained, and the single required parameter is illustrated. However, for a portfolio valuation call the description omits error handling for unknown scheme codes and NAV freshness/caching semantics, which an agent would want before invoking it in a multi-step workflow.

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% and the schema is nearly opaque (array of objects with additionalProperties: true), so the description does real work by giving a concrete holding example with scheme_code and units. It stops short of stating whether extra keys are allowed or how partial/duplicate holdings are treated.

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?

States a specific verb+resource ('Current value of a mutual fund portfolio') and the valuation basis ('at latest NAVs'), which is enough to separate it from scalar calculators like calculate_lumpsum_value. It never names the closest sibling alternatives explicitly, so an agent still has to infer that this is the multi-holding rollup.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is referenced. The word 'portfolio' hints that this aggregates multiple holdings rather than a single position, but that distinction is left entirely to inference against the many calculate_* siblings.

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?

Without annotations, the description details key behavioral outputs, specifying that it returns min, max, mean, median, and frequency counts. However, it lacks crucial operational details, such as how many historical windows are generated or if the data is guaranteed to be current.

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 definition is highly structured and flows logically: first defining the resource, then listing the contents of the result, and finally providing the unique value proposition. It is concise without being overly simplistic.

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 is complete enough to define the value and structure of the output metrics (min, max, mean, median). However, it falls short on technical completeness by not clarifying how the input parameters like 'step days' affect the calculation granularity.

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?

Given 0% schema coverage, the description is required to clarify parameter roles beyond the schema. It mentions `window_years` and `threshold_pct`, but fails to provide semantics or context for the remaining technical parameters, `step_days` and `scheme_code`.

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 defines the purpose as generating a 'Rolling-return distribution for a fund.' It distinguishes this from standard returns by stating it is 'Better than a single start-to-end return,' effectively differentiating it from calculation 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?

It provides strong conceptual usage guidance by comparing the tool's output to 'a single start-to-end return.' This establishes a clear context for when the agent should select it over simpler historical return functions.

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 carry the full behavioral burden. It discloses the returned fields but says nothing about lookup failure behavior, whether the scheme code must be an AMFI code, authentication, or any other operational trait.

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 short and front-loads the useful field list, but as an unpunctuated fragment it is under-structured rather than optimally concise. It could be a single clear sentence with a verb and lookup context.

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

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

An output schema exists, so exact return structure need not be explained. For a simple one-parameter read tool, the field list gives minimal context, but the missing verb, parameter format, and usage guidance leave it only barely 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 description coverage is 0% and the sole parameter, scheme_code, has no schema description. The phrase 'for a scheme code' only restates the parameter name; it does not clarify format, source, or expected values.

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 lists the specific metadata fields returned (fund house, scheme type, category, start date) for a scheme code, which distinguishes it from price-oriented siblings like get_scheme_quote. However, it is a sentence fragment with no verb, so the action is only implied by the tool name rather than stated.

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?

There is no explicit guidance on when to use this tool versus search_schemes or get_scheme_quote. The field list implies a metadata lookup, but no conditions, alternatives, or exclusions are 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, so the description carries the burden; it establishes this is a read of the latest value only (not historical), which is meaningful behavioral context. It omits freshness/caching semantics, whether scheme_code must exist or how a missing code behaves, and any rate or auth information.

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?

A single front-loaded sentence with no filler; every clause ('latest', 'basic', 'by AMFI scheme code') adds 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?

The output schema covers return values and there is only one parameter, so the remaining gap is guidance on sourcing a valid scheme_code and on how this differs from the history/detail siblings. Adequate but with clear omissions for an agent choosing among 20 siblings.

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%, so the description must compensate; it does identify that the identifier is an AMFI scheme code (not a name or ISIN), which is genuinely useful. It gives no format, example, or guidance on obtaining a valid code via search_schemes.

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?

States a specific verb ('get'), resource ('scheme quote'), and the returned content ('Latest NAV and basic quote'), which distinguishes it from the detail and history siblings well enough. It does not explicitly differentiate from get_scheme_details or get_nav_history, so it stops short of a 5.

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?

Usage is only implied: 'Latest' hints at a current-snapshot read versus get_nav_history, and 'basic quote' hints at a lighter alternative to get_scheme_details. Neither alternative is named and no when-not-to-use condition is given.

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 behavioral burden; it does disclose the useful truncation rule ('Returns at most max_points recent rows'), clarifying ordering and row-count behavior. However, it is silent on data staleness/delay, caching, error behavior for invalid symbols, and permission needs for what is presumably a public read.

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 short sentences, purpose front-loaded, followed by the two enumerated parameter families and the truncation note. No filler; every line adds 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 read-style data retrieval tool with an output schema documenting return values, this is largely complete: purpose, valid period/interval values, and row limits are covered. The missing piece is exchange semantics and what happens on invalid or delisted tickers.

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%, so the description must compensate — and it does for three of five parameters: it enumerates valid period values, valid interval values, and explains max_points truncation semantics. The gap is 'exchange': NSE/BSE are mentioned but the parameter's default (NSE) and how it interacts with symbol prefixes is never explained.

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?

States a specific resource and format — 'Price history (OHLCV) for an NSE/BSE stock or index ticker' — with a concrete example ticker ('^NSEI'). An agent can distinguish it from get_stock_quote/get_index_quote by the 'history' vs 'quote' resource framing without opening the schema.

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 its use case (historical prices for stock/index tickers) and lists valid period/interval values, but never states when to prefer this over get_stock_quote, get_index_quote, or get_nav_history. No exclusions or routing guidance are given.

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?

Since there are no annotations, the description must carry the behavioral burden. It provides critical operational context by labeling the source as 'Yahoo Finance (unofficial)' and warning about 'may be delayed,' which is vital information for 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 definition is highly efficient; both sentences serve a distinct purpose—the first defining functionality, the second defining operational constraints—and are placed front-loaded for maximum impact.

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?

It is highly complete for a lookup function, covering the goal, the scope (NSE/BSE), and the data quality caveats (unofficial/delayed). It achieves a high standard of usability without being verbose.

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

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

With 0% schema description coverage, the description must explain parameters. It successfully defines the purpose of 'symbol' and 'exchange' by providing concrete examples of what values are expected and how they relate.

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 is extremely clear, stating the specific action ('Latest price'), the resource ('NSE/BSE stock'), and providing a concrete example ('RELIANCE' on 'NSE') to ground the intent.

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 by detailing the necessary inputs (symbol and exchange) and an example, but it does not explicitly state when to use this tool over alternatives like 'get_index_quote' or 'get_stock_history' among the siblings.

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 behavioral burden for a multi-parameter financial projection. It does not disclose assumptions (inflation, pre/post-retirement returns), whether outputs are nominal or real, or any caveats about required inputs; only the output concept is stated. The existence of an output schema reduces the need to describe return values, but the calculation behavior remains opaque.

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 single sentence is front-loaded and waste-free, but its brevity reflects under-specification rather than disciplined concision. It does not earn its place as a complete tool definition for an 8-parameter calculator.

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?

An output schema exists, so return values need not be described. However, for a complex retirement projection with 8 parameters, 0% schema coverage, and no annotations, the description is far too thin to guide correct invocation or convey assumptions.

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 description coverage is 0% across 8 parameters, and the description supplies no parameter meaning at all. Required inputs such as current_monthly_expense and life_expectancy are not explained in units, currency, or interpretation, so the description does nothing to compensate for the schema gap.

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

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

The description names the two concrete outputs (retirement corpus and required monthly SIP), which lets an agent distinguish this from sibling SIP projection or return calculators. It lacks an explicit verb like 'calculate' and does not name alternatives, but the resource and computation are 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to any alternative tool such as project_sip or calculate_sip_returns. The purpose implies retirement planning, but the agent must infer all usage conditions.

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?

Since no annotations are provided, the description must carry the full burden. It clearly defines a core behavioral trait—that the calculation relies on an 'assumed constant return' rather than real market data, which is vital context for a financial projection 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 definition is extremely lean. It front-loads the core function in the first sentence and uses the second sentence to provide critical, high-value differentiation, making every word contribute maximally.

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 complexity of financial modeling, the description provides the necessary conceptual context regarding its 'what-if' nature and how it relates to other available tools. It does not overpromise or omit key contextual limitations.

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 description provides semantic value by framing the inputs as an 'assumed constant return' and an 'optional yearly step-up,' giving context to the parameters rather than just listing them. However, it does not clarify unit conventions (e.g., if the return is annual or monthly percentage).

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 purpose is to 'Project a SIP' and specifies the scope as using 'an assumed constant return.' Crucially, it distinguishes itself from the sibling tool, 'calculate_sip_returns,' by defining its function as a 'what-if projection'.

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 excellent usage guidance by defining the operational boundaries: it uses assumed returns (what-if) and explicitly directs the user to the correct alternative ('calculate_sip_returns') when they require real fund history.

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 behavioral disclosure burden. It helpfully states that results include AMFI scheme codes and names and that those codes are inputs to other tools, but it does not describe matching behavior, ambiguity handling, or rate/limit 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?

The description is short, front-loaded with the core action, and includes only useful details: search example, return values, and downstream use. There is no wasted text.

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 simple two-parameter search tool with an output schema, the description covers purpose, query intent, return values, and downstream usage. The main gap is the undocumented limit parameter and lack of detail about search matching behavior.

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 description coverage is 0%, so the description needs to compensate. It explains the required query parameter well with an example search phrase, but it does not explain the optional limit parameter or its default of 20.

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 specific verb and resource: search Indian mutual fund schemes by name. It includes a concrete example and clarifies that results return AMFI scheme codes and names, which distinguishes this lookup tool from the calculation and quote 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?

It implies usage by saying the returned code should be used with the other tools, which gives downstream context. However, it does not explicitly say when to choose this over siblings such as get_scheme_details or get_scheme_quote, nor does it describe 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.