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 and does well by explaining the computation logic (NAV on/before investment date, units valued at latest NAV). It also discloses the risk of wrong results from incorrect scheme codes. It doesn't cover error handling or data availability, but provides solid operational context.

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

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

The description is two sentences, front-loaded with the core function, and adds a critical usage caveat. No filler words or redundant details; 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?

For a simple 3-parameter tool with no output schema, the description is largely complete: it explains inputs, computation, and outputs. It could mention edge cases like missing NAV or holiday handling, but it's sufficient for an agent to select 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?

The input schema already describes all three parameters with high coverage, so the baseline is 3. The description adds critical semantic context that schemeCode must originate from search_mutual_funds and never be guessed, and explains the 'on/before' logic for the investment date. This enriches the parameter 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 it computes real returns for lump-sum mutual fund investments using live NAV history, and specifies the outputs (absolute return, CAGR, XIRR). This distinguishes it from siblings like get_fund_nav which only provide NAV, making the purpose unmistakable.

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

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

The description gives explicit instructions that schemeCode must come from search_mutual_funds and warns against guessing, which is a strong usage guideline. It also scopes the tool to lump-sum investments, implying it is not for SIPs. However, it does not explicitly name alternative tools for different calculation scenarios, so it falls short of a 5.

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

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

With no annotations, the description fully discloses the tool's behavior: it uses real Finance Act 2025 slabs, includes Section 87A rebate, surcharge, cess, returns a slab-by-slab breakdown, and recommends a cheaper regime. It also notes the limitation that deductions only apply to the old regime. This gives the agent a precise understanding of what the tool does and returns.

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

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

The description is three sentences, front-loaded with the primary purpose, followed by the key output and a caveat on deductions. Every sentence carries useful information with no redundancy or irrelevant details, making it an exemplary concise and well-structured description.

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 Indian income tax, the description covers the essential context: the specific FY/AY, regimes, components included (rebate, surcharge, cess), and output format. Even without an output schema, it explicitly states that a slab-by-slab breakdown and a recommendation are returned. This is complete enough for an agent to 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?

The schema provides 100% parameter description coverage, including details like caps and the fact that deductions are old-regime only. The description adds no extra parameter-specific semantics beyond what the schema already states. Thus it meets the baseline for full schema coverage but does not exceed it.

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 with a specific verb phrase ('Calculate and compare Indian income tax') and resource ('under the OLD vs NEW regime for FY 2025-26'). It distinguishes itself from sibling tools like optimize_deductions and estimate_capital_gains by focusing on regime comparison and providing actionable output.

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 when to use the tool (Indian income tax calculation for FY 2025-26, with both regimes) and highlights a key caveat (deductions only apply to old regime). It does not explicitly name alternative tools or state when not to use it, but the context is specific enough for an agent to select it appropriately.

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 openly states the methodology (projecting guaranteed interest saved vs realistic investment return over a horizon) and that it issues a recommendation. It stops short of disclosing limitations like tax assumptions or prepayment penalties, but provides a reasonable behavioral sketch for a 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 is a single sentence that front-loads the purpose and gives enough specificity in the remainder. Every clause contributes to understanding the tool's decision-support role; no filler words or repeated schema details.

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 5 parameters, no annotations, and no output schema, so the description must carry a balanced load. It does explain the core question and the comparison method, but it omits output format and key assumptions (e.g., tax effects, compounding), making it somewhat incomplete for a decision-critical finance 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 100%, so the baseline is 3. The description adds context for compareAgainst by specifying 'equity ~12% or FD' and 'over a horizon,' which loosely maps to compareAgainst and horizonYears, but it doesn't materially enhance what the schema already documents for parameters like expectedReturnPct.

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

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

The description opens with a clear title and answers a specific financial question ('should I prepay my loan or invest the surplus?'), identifying the resource (loan vs investment comparison) and the core action (projecting and recommending). This distinguishes it from siblings like calculate_fund_returns or get_benchmark_rates, which don't compare prepayment vs investing.

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 establishes a clear context: decision-makers with surplus cash weighing loan prepayment against investing, citing equity ~12% or FD as benchmarks. However, it does not name alternative tools or explicitly state when not to use it, so while the context is clear, exclusions are absent.

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 and does disclose deterministic behavior, zero extra LLM calls, and the reconciled output. However, it instructs passing `task: {}` while the schema disallows additional properties, making the augmentation feature misleading. This inconsistency lowers the score.

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

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

Three sentences, front-loaded with the core purpose and output. It is efficient, though 'deterministic' appears twice, creating slight 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?

For a 9-parameter tool with no output schema, the description explains the output well (weighted recommendation, agreement level, confidence) but leaves the `task: {}` augmentation ambiguous and does not detail what streaming each lens entails. The schema covers params, but the task contradiction remains a gap.

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 provides 100% parameter documentation, so the description adds little beyond the task augmentation mention (which is not schema-valid). The regime default is already documented in the schema, so the description adds minimal value beyond the structured fields.

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 is a 'Deterministic advisory council' for 'should I invest my surplus or prepay my loan?' decisions, evaluating three lenses and producing a weighted recommendation with agreement and confidence. This is a specific verb-plus-resource that distinguishes it from generic financial planning 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 explicitly frames when to use the tool: for invest-vs-prepay decisions, and highlights the single-call deterministic advantage. However, it does not mention alternatives or exclusions, such as when to use compare_emi_vs_investment instead.

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 full responsibility. It discloses that the tool uses live NAV when schemeCode is provided, applies specific tax rates (STCG 20%, LTCG 12.5% with exemption, debt slab rates), and bases rules on fund type and holding period. It does not mention output format or edge cases, but the provided behavioral details exceed basic expectations.

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

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

The description is three concise sentences with clear front-loading of purpose. Every sentence contributes: purpose and timing, tax rule specifics, and the two valuation modes. No unnecessary words or repetition.

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 8 parameters, no output schema, and complexity around tax rules. The description covers main usage modes and tax categories but omits what the returned estimate looks like (e.g., breakdown, status messages) and does not clarify hybrid fund handling beyond mentioning fund types. Given the lack of output schema, more detail on return values would improve completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema by explaining the relationship between schemeCode and currentValue (live vs manual) and linking fundType to equity/debt tax rules. This enriches parameter understanding.

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: estimating capital-gains tax before selling a mutual fund, with specific FY 2025-26 rules. It also distinguishes it from siblings by focusing on capital gains rather than general income tax or fund returns, and mentions specific modes (schemeCode vs currentValue).

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 clear context: 'before selling/redeeming a mutual fund' and explains two valuation approaches (live NAV via schemeCode or manual currentValue). However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit 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?

With no annotations provided, the description carries the full burden. It discloses that values carry an as-of date and source, and that data is authoritative but dated due to RBI lacking a free live API, with an env override. This is transparent about the recency and customizability, going beyond a simple 'returns data' statement.

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

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

The description is two sentences, front-loaded with a clear title-like phrase and immediately states the return values. Every word earns its place, covering purpose, use case, data provenance, and configuration in a compact, scannable format.

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

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

Given the tool's simplicity (no params, no output schema), the description is complete. It explains what data is returned, the source limitations, the as-of date, the override mechanism, and the intended use case. No critical information is missing for an agent to select and invoke it correctly.

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

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

The input schema has zero parameters, and schema coverage is 100%, so the baseline is 4. The description does not add parameter-specific details, but none are needed. It does mention env override, which is related to configuration rather than parameters, so the baseline 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 the tool returns the current RBI repo rate and representative bank fixed-deposit rates with a specific verb ('returns') and resource (rates). It differentiates from siblings by focusing on benchmark rates, which no other tool covers, and adds the purpose of comparing safe returns against mutual fund returns.

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 a clear use case: comparing safe returns (repo/FD) against mutual fund returns. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to know when to invoke it, especially given the unique purpose among sibling tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys the comprehensive nature ('full', 'all statutory due dates') but omits details like response format or data source. This adds some context beyond the 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 description is a single concise sentence, immediately stating what the tool does and the key optional filter. No filler 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 simple read-only tool with one optional parameter and no output schema, the description sufficiently conveys the return value (a calendar of due dates). The distinction from 'get_upcoming_deadlines' is subtle but implicit through 'full' vs. 'upcoming'.

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 fully describes the single optional 'category' parameter with an enum, and the description restates the same categories. The 100% schema coverage means the description adds no additional parameter semantics.

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

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

The description uses the verb 'Get' and specifies the resource 'full Indian tax compliance calendar' with 'all statutory due dates', clearly defining the tool's purpose. It also distinguishes from sibling 'get_upcoming_deadlines' by emphasizing 'full' and 'all'.

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 provides a comprehensive calendar but does not explicitly contrast it with alternatives like 'get_upcoming_deadlines'. The optional category filter implies usage but lacks explicit guidance on when to choose this tool over others.

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 transparency burden. It discloses a live AMFI ping (a network operation) and clarifies the data is not hardcoded, which is valuable behavior context. It does not mention potential latency or failure modes, but for a simple read-only freshness check this is reasonably complete.

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 and gets to the point, but the opening 'Data Freshness Indicator —' is redundant with the tool name, and the phrase 'making it visibly clear...' is somewhat promotional. Still, it remains concise and front-loaded with the core 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?

For a zero-parameter tool with no output schema, the description provides the key reported fields (last fetch date, latest data date) and the mechanism (live AMFI ping). There is slight ambiguity about which data sources are covered ('each live data source' vs. only AMFI), but overall it gives sufficient context for an agent to invoke it.

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

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

The tool has zero parameters, so the empty schema is complete. No parameter explanation is needed, and the description does not attempt to describe nonexistent parameters. This matches the baseline for parameterless tools.

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 reports freshness metadata (last fetch time and latest data date) for each live data source, using a specific verb ('reports') and resource. It distinguishes itself from sibling tools like get_fund_nav or get_market_news by focusing on data recency rather than the data itself.

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 context is implied through phrases like 'making it visibly clear the numbers are current and real,' suggesting it is for verifying data recency. However, there is no explicit when-to-use instruction, no mention of when not to use it, and no alternatives named.

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 data comes 'from live MFAPI.in data' and, more importantly, that 'a wrong code silently returns a completely different fund.' This goes beyond the basic action and warns of a critical failure mode, which is valuable transparency.

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 pack a clear purpose and a critical usage warning. Every clause adds value, and the description is appropriately sized for the tool's simplicity.

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 single-parameter tool without an output schema, the description covers the essential operational context: the live data source, the need to use search_mutual_funds for the code, and the danger of incorrect codes. It doesn't describe the return format, but that is less critical for a NAV getter.

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 covers the parameter well (description and example), so baseline is 3. However, the tool description adds crucial semantics: the schemeCode must come from search_mutual_funds and must never be guessed or reused, with the consequence of silent wrong results. This adds 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: 'Get the latest Net Asset Value (NAV) for a mutual fund scheme from live MFAPI.in data.' It uses a specific verb and resource, and the explicit link to search_mutual_funds distinguishes it from sibling tools like get_benchmark_rates or calculate_fund_returns.

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 usage guidance by stating the schemeCode 'MUST be obtained from search_mutual_funds output' and warning 'NEVER guess a code or reuse one from memory.' This clearly instructs the agent on the required prerequisite and the correct alternative tool to use, though it doesn't explicitly mention competing tools for the same task.

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 discloses ordering ('newest first') and the dataset's curated, non-live nature, which are valuable behavioral traits. It does not cover pagination or return field details, but as a read-oriented search tool, the disclosed traits are sufficiently 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, with the first front-loading the verb and resource, and the second adding a caveat. There is no filler, and every phrase 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?

The tool has 9 parameters, no output schema, and no annotations. The description provides context about the dataset type, filter options, ordering, and curation status. The schema already documents parameters, so the description fills the main gaps, though a note on returned event fields would make it more complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists filters already present in the schema and adds no additional syntax or format details beyond them. The 'newest first' note pertains to output ordering, not parameter semantics.

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 ('Search') and a clear resource ('market news & events dataset'), and enumerates filter dimensions. This differentiates it from sibling tools like get_market_sentiment, which focuses on sentiment rather than news/event search.

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 clearly indicates when to use the tool: when searching a market news and events dataset with various filters. However, it does not explicitly mention when not to use it or name alternative tools, so it lacks explicit 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, so the description carries full burden. It discloses output structure but not data freshness, limitations, or how sentiment is computed. It is a read-only summary, but additional behavioral context (e.g., data coverage range) would improve transparency.

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: the first states the core purpose and filters, the second lists the returned information. No unnecessary words, front-loaded with the main action.

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 no output schema, the description enumerates the return structure. For a tool with 4 optional params and no required fields, the description is sufficient for invocation. It could add a usage example or explicit alternative, but overall it covers all key aspects.

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. It explicitly mentions optional filters for sector/index/date, which maps to the 'sector' and 'index' parameters and 'to'/'from' as a date range. This adds meaning beyond the bare property names, though it doesn't detail formats or constraints.

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

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

The description uses a specific verb ('summarize') and resource ('market news & events dataset') and lists concrete outputs ('counts by sentiment and impact', 'top sectors', 'net bullish/bearish read'). This clearly distinguishes it from siblings like get_market_news, which likely returns raw news.

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 states optional filters by sector/index/date, implying use when a sentiment overview is needed. However, it does not explicitly contrast with get_market_news or other alternatives, so it provides clear context but no 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, so the description carries the full burden. It does disclose ordering (soonest-first) and that results include days remaining. However, it doesn't explicitly state that this is a read-only operation, what fields each deadline entry contains, or any data-freshness limitations. This leaves some behavioral ambiguity.

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 filler. The first sentence packs essential information (scope, sorting, days remaining) and the second clarifies the intended use case. It is well-structured and front-loaded.

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 list tool with no output schema, the description provides sufficient scope (specific AY/FY), ordering, and usage context. It would benefit from a brief note on response format or read-only nature, but given the simplicity and full schema coverage, it is largely 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?

The input schema already provides complete descriptions for both parameters (limit and withinDays), so schema coverage is 100%. The description does not add any additional context about parameter usage, defaults, or interactions, so it doesn't go beyond the schema 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 clearly states it lists upcoming Indian tax and compliance deadlines for a specific assessment year, sorted soonest-first with days remaining. This is a specific verb+resource+scope. However, it doesn't explicitly distinguish from the sibling tool get_compliance_calendar, which likely has overlapping functionality.

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

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

Provides a clear use case: 'Use this to remind a taxpayer what is due next.' This gives context for when to invoke the tool. It doesn't explicitly mention when not to use it or alternatives, but the intended scenario is clear enough.

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 disclosing behavior. It clearly explains the tool flags over-cap amounts and unused headroom, and quantifies potential tax savings. It does not mention side effects, but the language implies a read-only analysis, which is adequately 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 three sentences with no filler. Each sentence serves a distinct purpose: naming the tool's function, explaining its outputs, and stating its applicability. It is front-loaded and well-structured.

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

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

Given the moderate complexity and no output schema, the description sufficiently explains the tool's return value (flags, unused headroom, quantified savings). It does not mention edge cases or behavior under the new regime, but the statement 'Applies to the OLD regime' covers the main constraint.

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 high (75%), so the schema already explains parameters well. The description adds context by clarifying that deductions apply only in the old regime and that the tool audits against caps, but it does not detail individual parameter semantics 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 uses a specific verb ('audits') and identifies the precise resource (taxpayer's Chapter VI-A deductions) and scope (against statutory caps). It clearly distinguishes itself from siblings like calculate_income_tax by focusing on optimization, not just calculation.

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

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

The description explicitly states 'Applies to the OLD regime', providing a clear contextual constraint. However, it does not name alternative tools or provide explicit 'when not to use' guidance, though this is partially implied.

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 orchestrates multiple data sources, runs asynchronously with `task: {}`, and provides live progress updates. However, it does not mention failure modes, rate limits, or whether it causes side effects beyond computation.

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 purpose, and the second sentence adds an important async usage detail. Every clause earns its place with no fluff.

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

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

The tool is a complex orchestrator with no output schema and no annotations. The description states it returns a coherent plan with summary and action items, and mentions async progress updates, but it does not describe the exact output shape, error handling, or how the sub-tools' results are combined.

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 71%, but the description adds little beyond what the schema already states. It calls out gross income, mutual fund holding, and IFSC, but does not clarify the purpose or interactions of ageGroup, deductions, isSalaried, or deadlineWindowDays beyond what the property descriptions provide.

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

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

The description uses a specific verb ('orchestrates') and names the resource ('tax calculator, live mutual-fund NAV/XIRR, IFSC verification, compliance calendar') and clearly distinguishes itself from siblings by offering a one-shot composite plan with a summary and action items.

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 phrase 'One-shot personal finance & tax plan' and the explicit mention of orbital sub-tools imply this is for comprehensive planning rather than using individual tools. It clearly states that income is required and fund/IFSC are optional, and notes the async task augmentation. However, it does not explicitly say 'use this instead of sibling tools' or list 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?

With no annotations to convey safety or side effects, the description carries full burden and does so well: it discloses a curated verified-code map for popular funds (handling renames), a live relevance-ranked MFAPI.in dataset for the long tail, and the fact that the returned code must be passed verbatim downstream. This goes beyond the tool name and explains important search 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?

Three sentences: a one-line purpose, a concise explanation of the data source/behavior, and a workflow directive. No filler; each sentence adds information, with the 'ALWAYS' callout highlighting the critical usage instruction.

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?

No annotations or output schema, so the description must carry more weight. It covers purpose, behavior, data source, and downstream use, and tells the agent that the returned schemeCode should be passed verbatim. However, it does not explicitly describe the full result shape (e.g., that the search returns a list of matches with metadata), leaving a small gap.

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 both params (query, limit) with descriptions, so baseline is 3. The description adds meaningful nuance by giving a concrete query example and explaining that old/popular names are resolved through a verified map to current scheme codes, which clarifies query semantics.

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?

Clearly identifies the tool as a search over Indian mutual fund schemes by name, with specific scope (Indian, by name). It distinguishes itself by noting its role as the mandatory first step to obtain a schemeCode and by explaining the curated map for renamed funds, which separates it from downstream data-retrieval 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?

The description explicitly says 'ALWAYS call this first' and instructs passing the returned schemeCode to get_fund_nav or calculate_fund_returns, giving clear when-to-use context. It lacks an explicit 'when not to use' or alternative mention, but the 'first' directive makes the workflow unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses the use of 'the free, live Razorpay IFSC API' and lists the return information (bank name, branch, full address, payment rails). However, it does not explain behavior on invalid IFSC codes, potential network/API errors, rate limits, or response structure. This is a meaningful gap, but the description does provide the source and data 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?

The description is two sentences long, front-loaded with the purpose, and contains no redundant information. Every clause adds value: the operation, the output fields, the data source, and the use case.

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?

This is a simple read-only lookup tool with a single parameter and no output schema. The description compensates well by specifying the exact output fields (bank name, branch, full address, payment rails) and the use context. It does not mention the response format (e.g., JSON), but for an agent deciding whether to call it, the description is sufficiently 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?

The schema already provides 100% coverage for the single parameter 'ifsc', including length and an example. The description adds 'Indian bank' and mentions the API, but this does not significantly enhance the parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Verify an Indian bank IFSC code and return the bank name, branch, full address and supported payment rails'. The verb 'verify' is specific, and the resource (IFSC code) is identified. It is distinct from all sibling tools, which focus on mutual funds, taxes, market data, etc., none of which overlap with IFSC verification.

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 includes a concrete use case: 'Useful before setting up a refund/payout account.' This provides clear context for when to use the tool. However, it does not mention when not to use it or name alternatives, though no direct sibling alternative exists.

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