FinanceGenius.AI

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

With no annotations, the description does not disclose edge cases, return format (e.g., percentage or decimal), or error conditions. It simply states the calculation without further behavioral details.

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

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

The description is extremely concise, using a single sentence for the purpose and three bullet points for parameters. No unnecessary words or redundancy.

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

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

For a simple calculation tool, the description is adequate but lacks completeness: no output schema, no mention of assumptions (e.g., compounding frequency), and no example values. Could be more self-contained.

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

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

Although the schema has no property descriptions (0% coverage), the description adds explanatory text for each parameter (e.g., 'in rupees'), enhancing understanding beyond the bare schema names.

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 'Calculate CAGR' using a specific verb and resource, making the purpose unambiguous. It is distinct from sibling tools like calculate_emi or calculate_sip.

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 is provided on when to use CAGR over other investment calculation tools. The description only explains what the tool does, lacking context for selection.

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

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

With no annotations, the description carries full burden. It states return values (EMI, total interest, total payment, amortisation schedule) but does not disclose calculation assumptions (e.g., reducing balance method), rounding, or data precision.

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

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

Description is concise with a clear docstring structure: one-line purpose followed by Args and Returns sections. Every sentence adds value without redundancy.

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

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

Given no output schema, the description adequately explains return values. However, it does not specify the format of the amortisation schedule (e.g., list of yearly breakdowns), which would be helpful for an AI agent.

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

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

Schema has 0% description coverage. The description compensates fully by explaining each parameter: principal in rupees, annual_rate as percentage (e.g., 10.5), and tenure_months in months. This adds essential 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?

Description clearly states 'Calculate EMI for a loan with year-by-year amortisation schedule.' It identifies the specific verb (calculate) and resource (EMI with amortisation), distinguishing it from sibling tools like calculate_sip or calculate_fd_maturity.

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?

Description implies usage for loan EMI calculation but provides no explicit guidance on when to use or avoid this tool versus alternatives. No mention of prerequisites or exclusions.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It mentions compounding and gives an example for years, but it does not specify what the tool returns (e.g., only maturity amount or also interest earned), any assumptions about rounding or precision, or error conditions.

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

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

The description is concise and uses a clear Args block. Every sentence adds value, though the Args format is slightly verbose. No redundant 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 tool has no output schema, so the description should indicate what the function returns, but it does not. It also lacks information about error handling or edge cases (e.g., negative rates, zero deposit). This leaves the agent guessing about the return value.

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 has 0% description coverage, so the description must clarify each parameter. It explains deposit_amount as 'Principal deposit in rupees,' annual_rate as 'Annual interest rate as a percentage,' years with an example, and compounding with a list of options and a default note. This adds essential 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 function: 'Calculate FD maturity amount with compounding.' It specifies the verb (calculate), resource (FD maturity amount), and context (compounding). This distinguishes it from sibling tools like calculate_cagr or calculate_emi.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. The only contextual hint is 'Most Indian FDs compound quarterly,' which is a factual note but not usage guidance.

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

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

With no annotations, the description carries the full burden. It discloses deduction applicability per regime and return structure, though it omits details on error handling or edge cases.

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

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

The description is concise, uses clear bullet points for parameters, and contains no superfluous sentences, making it easy to scan and understand.

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 complexity (5 parameters, no output schema), the description adequately covers all inputs and the return value, though it lacks mention of potential errors or limitations like surcharge.

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 adds crucial meaning: it explains each deduction's purpose, maximum limits, and regime applicability, far beyond the schema's bare titles and types.

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 computes Indian income tax for FY 2025-26 under old or new regime, using specific verbs and resource, distinguishing it from sibling financial 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 usage for tax calculation but does not explicitly state when to use this tool vs alternatives, nor provides guidance on regime selection or prerequisites.

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

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

No annotations are provided, so the description carries full burden. It does not disclose important behavioral traits such as compounding frequency (monthly vs annual), rounding, or whether contributions are made at the beginning or end of the period. This is critical for financial calculations.

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

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

The description is concise with a clear docstring format. It includes the main purpose and parameters in a structured 'Args' list. No redundant sentences.

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

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

No output schema is present, so the description should explain the return value. It does not mention that the tool returns the future value of the SIP. Additionally, details like compounding frequency are missing, which are essential for accurate usage.

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 add meaning. It provides clear explanations for each parameter: 'monthly_amount' in rupees, 'annual_return_pct' as a percentage (e.g., 12), and 'years' as the horizon. However, it could be more precise (e.g., implying monthly compounding).

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

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

The description clearly states the tool calculates the future value of a SIP and lists the three parameters. It distinguishes from sibling tools like calculate_cagr and calculate_emi by specifying 'SIP' and the parameters specific to SIP calculations.

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

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

The description implies usage for SIP calculation but does not explicitly state when to use this tool over alternatives like calculate_cagr or calculate_fd_maturity. No guidance on prerequisites or exclusions.

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

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

No annotations are provided. The description discloses the constraint of same category and the return format (markdown table). It does not discuss error handling or side effects, but for a read-like tool, this is reasonable.

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

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

The description is concise: one sentence for purpose, one for args, one for returns. Front-loaded with the core action. No redundant 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 tool with one parameter and no output schema, the description covers purpose, parameter constraints, and return format. It does not explain what a 'slug' is, but that is minor. Overall, it is complete enough for an agent to use 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 description bears the full burden. It adds meaning to the 'product_slugs' parameter: list of 2-4 slugs, same category. This compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool's action ('compare'), resource ('products'), and constraints ('2-4 products of the same category'). It distinguishes from siblings like get_product_details (single product) and search_indian_products (discovery).

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 specifies the required input conditions (2-4 products, same category) but does not explicitly state when to use this tool vs alternatives. However, the context of comparison vs. detail retrieval is 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?

Given no annotations, the description provides good transparency by detailing the search method (BM25 + semantic + product DB with Reciprocal Rank Fusion). It implicitly indicates a read-only operation but lacks explicit statements about destructiveness or side effects, which is acceptable for a query tool.

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

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

The description is well-structured with a clear summary and bullet-like parameter list. It is slightly verbose but each sentence adds value, making it appropriately sized for a tool with moderate complexity.

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

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

Given no output schema, the description covers the tool's purpose, search methodology, and parameters adequately. It does not describe the output format, but for an explainer tool this is not critical. The description is complete for its context.

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 fully compensates by clearly explaining both parameters: query ('The financial question or concept to explain') and institution ('Optional — narrow search to one institution'). This adds significant 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 answers financial questions using a hybrid knowledge base, with specific examples like 'what is a critical illness rider?'. It effectively distinguishes itself from sibling tools that focus on calculations (e.g., calculate_cagr) or product lookups (e.g., get_product_details), making its purpose unambiguous.

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

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

The description offers strong usage guidance by listing example queries and noting that it is 'Best for explainers like: ...'. However, it does not explicitly state when not to use this tool or name alternative tools for different tasks, which would improve clarity.

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 discloses output as top 5 cards with estimated cashback, but does not explain how recommendations are determined, data sources, accuracy, or limitations. Adequate minimally.

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

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

Description is concise with a clear structure: one-sentence purpose, Args section detailing each parameter, and Returns section. No redundant or unnecessary text. Front-loaded for quick understanding.

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 4 parameters and no output schema, the description specifies output format (top 5 cards with estimated annual cashback). It is sufficiently complete for a recommendation tool, though details on recommendation logic are absent but acceptable.

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 description must document parameters. It explicitly lists all four parameters with meaningful descriptions: monthly_spend in rupees, primary_category with enumerated valid values, annual_income for eligibility filtering, and prefer_no_annual_fee for card type preference. Adds significant value beyond 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 states 'Recommend Indian credit cards based on spending pattern,' which clearly identifies the action (recommend) and resource (credit cards) with geographic and contextual specificity. It distinguishes from sibling tools like calculators and stock queries.

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?

Context implies the tool is for card recommendations, distinct from siblings. However, no explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned. The required parameters are stated, but no exclusionary 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?

No annotations are provided, so the description carries the full burden. It discloses that FD interest is fully taxable and that the tax slab is used for net-yield ranking. It also explains what the tool returns (top 5 FDs sorted by net-of-tax maturity with gross and net amounts). However, it does not mention whether the operation is read-only or destructive, or any authorization needs. Given no annotations, it does a good job, but could be more explicit about safety.

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 well-structured with a clear heading, Args, and Returns sections. The core purpose is front-loaded in the first line. However, it is somewhat verbose, especially the parameter descriptions which could be more concise. Overall, it is efficient but not maximally succinct.

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 there is no output schema, the description fully explains the return (top 5 FDs with gross and net amounts). It covers all four parameters, their meanings, and the ranking logic. The tool is not overly complex, and the description provides enough context for an agent to use it correctly without additional structure.

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

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

Schema description coverage is 0%, so the description must compensate. It does so excellently, explaining each parameter: amount ('Investment amount in rupees'), years ('FD tenure in years, e.g. 1.5 for 18 months'), is_senior_citizen ('True to use senior-citizen rates, typically +0.5%'), and tax_slab_pct ('Investor's income tax slab as a percentage (5/10/20/30). FD interest is fully taxable; this is used for net-yield ranking'). This adds significant meaning beyond the schema's basic type and default.

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: 'Rank Indian Fixed Deposits by net-of-tax yield for a given amount + tenure.' It uses a specific verb ('Rank') and specifies the resource ('Indian Fixed Deposits') and the metric ('net-of-tax yield'). This distinguishes it from sibling tools like calculate_fd_maturity, which likely just calculates maturity value, and find_best_card_for_spend, which handles cards.

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

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

The description implies the tool should be used when ranking FDs based on net-of-tax yield, but does not explicitly state when to use this tool versus alternatives like calculate_fd_maturity or compare_products. No when-not or alternative tool references are provided, leaving the agent to infer usage context from the purpose alone.

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 provided, so description carries full burden. It discloses the return fields (price, change, volume, updated). Could mention if data is real-time or delayed, but still clear.

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?

Brief and well-structured with Args and Returns sections. Every sentence adds value; 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?

Single required parameter, no output schema needed; description covers input format, examples, and return fields. Complete for a stock quote 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%, but description fully explains the single parameter 'symbol' with format, examples, and exchange rules. This compensates entirely for the lack of schema detail.

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

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

The description clearly states it gets the live price for Indian stocks on NSE or BSE. It distinguishes from sibling tools like search_indian_stocks by mentioning when to use that tool instead.

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?

Includes explicit guidance: if unsure of the symbol, call search_indian_stocks first. Also specifies exchange suffixes (.BSE, .NSE) and provides examples of correct usage.

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 provided, so description must carry full burden. Discloses operation is to get NAV and lists return fields. Does not mention potential issues like invalid codes, rate limits, or that it's read-only.

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 concise sentences covering purpose, parameter, and returns. Well-structured with Args and Returns sections. No unnecessary words.

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

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

For a simple tool with one parameter and no output schema, description adequately covers purpose, parameter details, and return fields. Minor gap: no mention of error handling or geographic scope (India).

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

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

Schema has 0% description coverage, but description fully explains the parameter: what it is (AMFI scheme code), provides an example, and tells where to find codes. Adds essential meaning beyond 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?

Description clearly states 'Get the latest NAV of an Indian mutual fund by AMFI scheme code.' Provides specific verb, resource, and method. Easily distinguished from sibling tools like calculate_cagr or get_indian_stock_quote.

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 guidance. Does not mention alternatives among sibling tools. Instructions on finding scheme codes are helpful but not exclusionary.

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 description bears full burden. States it gets live quotes but does not mention that the list is fixed or provide details about rate limits or output. Could be more transparent about exact stocks.

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, no wasted words. Front-loaded with action 'Get live quotes'. Highly concise and 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?

Adequate for a simple tool with no parameters and no output schema. Explains purpose and use case, though could mention output format or fixed list.

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

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

No parameters; schema coverage 100% (empty). Baseline 4 for zero parameters is appropriate as description adds no parameter info but also no need.

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 states it gets live quotes for 10 popular Indian stocks with examples. Distinct from sibling tools like get_indian_stock_quote (requires symbol) and search_indian_stocks (searches).

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 says 'useful for a market overview without specifying individual symbols,' indicating when to use. Lacks explicit when-not or alternatives, but context with siblings implies appropriate use.

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

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

No annotations are provided, so the description carries full burden. It only states the basic function without disclosing potential errors, rate limits, or authentication needs. The description is too minimal for full 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?

The description is short and front-loaded with the purpose. The Args section is somewhat redundant but adds value. Could be more concise, but adequate.

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 single-parameter tool with no output schema, the description covers purpose, parameter meaning, and source of slug. Missing return format and error cases, but overall complete for its simplicity.

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

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

Schema has 0% coverage for product_slug description. The description explains the slug is a URL-safe identifier, gives an example, and tells where to obtain it, adding significant meaning beyond the schema's property title 'Product Slug'.

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 verb 'Get', resource 'full details of a specific product', and identifier 'by its slug'. This distinguishes it from sibling tools like search_indian_products which retrieves slugs, and compare_products which compares products.

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 direction to get slugs from search_indian_products, implying this tool is used after obtaining a slug. It doesn't specify exclusions, but the context is helpful.

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 behavioral burden. It states the tool returns up to 10 results sorted by popularity, but omits details on authentication, rate limits, empty result handling, or error cases. Basic behavior is covered, but not comprehensively.

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

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

The description is concise and well-structured with Args and Returns sections. Every sentence adds value with no redundancy. The purpose is front-loaded, and the structure is easy to parse.

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

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

Given no output schema, the description adequately describes return value (up to 10 products sorted by popularity). However, it does not specify product structure or indicate if additional results exist beyond 10. Still, for a search tool, it is reasonably 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 has 0% description coverage for parameters, so the description fully compensates. It explains each parameter: product_type lists valid values and effect of omission, search_query gives examples, min_rating specifies scale (1-5). This adds significant meaning beyond the schema which only defines types.

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 searches FinMall.AI's catalog of Indian financial products, with specific verb 'search' and resource 'catalog of Indian financial products'. It distinguishes from sibling tools like search_indian_stocks (stocks) and get_product_details (details by ID) by its broad coverage across product types.

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 parameter options and examples (e.g., 'cashback', 'home loan', 'HDFC') but does not explicitly state when to use this tool versus alternatives like compare_products or calculate_emi. The context implies general search, but explicit when-not-to-use instructions are missing.

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 discloses it returns top matching symbols with names and region, which is adequate for a read-only search tool.

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

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

The description is very concise, front-loads the purpose, and uses a clear Args/Returns format with 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?

For a simple tool with one parameter and no output schema, the description fully covers what the tool does, what input to provide, and what output to expect.

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%, but the description adds examples and clarifies 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 finds Indian stock symbols by company name. It distinguishes from sibling tools like 'get_indian_stock_quote' and 'get_popular_indian_stocks'.

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

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

The description implies when to use (search by company name) but doesn't explicitly advise against using alternatives or provide exclusions.

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