India's financial MCP — cards, loans, FDs, insurance, MFs; EMI/SIP/tax calcs; NAV lookup; RAG.
Scored across 12 tools
Tools have distinct purposes: calculators for numeric computations, search/retrieval for product data, and comparison/recommendation tools. However, `explain_financial_concept` and `search_indian_products` both retrieve from the product catalogue, creating some ambiguity, though the former claims to explain concepts while the latter finds products.
All tool names follow a consistent snake_case verb_noun pattern: `calculate_*`, `get_*`, `find_*`, `search_*`, `compare_*`, `explain_*`. This is predictable and easy to parse.
12 tools is well within the ideal range. The server covers financial calculations, product search, comparison, and recommendations without feeling bloated or thin.
The surface covers key financial calculations (CAGR, EMI, FD, SIP, tax), product retrieval, comparison, and recommendation. However, some common operations like currency conversion or stock price lookup are missing, and there's no tool to list all available product categories or institutions, which could be a minor gap for exploration.
Calculate the Compound Annual Growth Rate (CAGR) of an investment.
Args:
initial_value: Initial investment in rupees.
final_value: Final value in rupees.
years: Holding period in years.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| final_value | Yes | ||
| initial_value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so an agent knows this is a safe offline computation; the description does not contradict that. Beyond the safety profile it adds units ('in rupees', 'in years'), which is useful, but says nothing about return format or edge cases (e.g., zero/negative growth). With annotations carrying the safety burden, a 3 is appropriate.
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 tool's purpose is front-loaded in the first sentence, followed by a compact Args block. No wasted prose. The Args list partially restates schema titles, which is mildly redundant, but the units justify including it.
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?
There is no output schema, so the description should ideally state what is returned (a percentage vs. a decimal ratio) and handle edge cases, but it stops at explaining inputs. For a simple three-parameter calculator the definition is workable, but the return-value gap is real.
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 carries the full burden, and it does so well: all three parameters are defined with meaning and units (initial investment in rupees, final value in rupees, holding period in years). This goes beyond the bare schema titles ('Initial Value', 'Years'). A 4 rather than 5 because ordering/format constraints of the parameters are not discussed.
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: 'Calculate the Compound Annual Growth Rate (CAGR) of an investment.' An agent immediately knows this is a computation tool. It does not, however, distinguish itself from the many sibling calculators (calculate_emi, calculate_sip, calculate_fd_maturity), so a 5 is not warranted.
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 choose CAGR over the sibling calculators (SIP, EMI, FD maturity), and no prerequisites or input constraints. The only implied usage is the formula itself. This is pure 'what', with no 'when'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate EMI for a loan with year-by-year amortisation schedule.
Args:
principal: Loan amount in rupees.
annual_rate: Annual interest rate as a percentage (e.g. 10.5 for 10.5%).
tenure_months: Loan tenure in months.
Returns:
Monthly EMI, total interest, total payment, and amortisation schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | Yes | ||
| annual_rate | Yes | ||
| tenure_months | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description nonetheless adds genuinely useful behavior beyond the annotations by specifying the return contents (monthly EMI, total interest, total payment, amortisation schedule), which matters because no output schema exists.
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 one-line summary is front-loaded and the Args/Returns layout is standard and scannable. It is slightly verbose relative to the information conveyed, but nothing is redundant or wasted.
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 pure-computation read-only tool with three required scalar params and no output schema, the description supplies the units, the interpretation of each input, and the expected outputs. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden — and it does: principal in rupees, annual_rate as a percent (with a concrete 10.5 example), tenure_months in months. This resolves the realistic ambiguities (currency, percent vs decimal, month vs year) that the bare schema leaves open.
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 (calculate) and resource (loan EMI) and adds scope detail — year-by-year amortisation schedule — that separates it from the other numerical siblings like calculate_cagr, calculate_sip, and calculate_fd_maturity. An agent can identify the tool 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?
There is no guidance on when to use this tool versus the many sibling calculators, no prerequisites, and no exclusions. Usage must be inferred entirely from the tool name and the word 'loan'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate FD maturity amount with compounding.
Args:
deposit_amount: Principal deposit in rupees.
annual_rate: Annual interest rate as a percentage.
years: FD tenure in years (e.g. 1.5 for 18 months).
compounding: One of 'monthly', 'quarterly', 'half_yearly', 'yearly'.
Most Indian FDs compound quarterly.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| annual_rate | Yes | ||
| compounding | No | quarterly | |
| deposit_amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and openness. The description adds useful behavioral context about compounding options and notes that most Indian FDs compound quarterly, which helps an agent choose default parameters in a domain-specific way. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then uses an Args block that is well-structured for a function signature. It is slightly verbose but each sentence adds value, 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?
Given no output schema, the description could clarify the return value (e.g., whether it returns a number or object). However, it fully covers inputs, safety via annotations, and a domain-specific default recommendation, making it nearly complete for a calculator 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%, so the description must fully document parameters. It provides clear semantics for each: deposit_amount as principal in rupees, annual_rate as percentage, years as tenure with an example, and compounding with an enumerated list and a domain hint about quarterly 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 states a specific verb ('Calculate') and resource ('FD maturity amount with compounding'), distinguishing it from siblings like calculate_emi or calculate_sip. An agent can immediately tell this computes fixed deposit 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?
No guidance is provided on when to use this tool versus alternatives (e.g., find_best_fd or compare_products). While the purpose is clear, the agent must infer usage context without any explicit when/when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute Indian income tax for FY 2025-26 under old or new regime.
Args:
annual_income: Gross annual income in rupees.
regime: 'new' (default) or 'old'.
deductions_80c: Section 80C deductions in rupees (max ₹1,50,000, old regime only).
deductions_80d: Section 80D health-insurance premium (old regime only).
hra_exemption: HRA exemption amount (old regime only).
Returns:
Slab breakdown, total tax, effective rate, regime comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| regime | No | new | |
| annual_income | Yes | ||
| hra_exemption | No | ||
| deductions_80c | No | ||
| deductions_80d | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm this is a safe read-only, non-destructive, closed-world calculation. The description adds that it returns a slab breakdown, total tax, effective rate, and regime comparison, which is useful return info not covered by annotations. However, it doesn't clarify edge cases, rounding, or whether assumptions are documented.
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?
Uses a structured Args/Returns format that is front-loaded and information-dense without wasted sentences. Slightly verbose for an agent but well organized and every section 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?
No output schema exists, so the description usefully summarizes returns. Parameter semantics are strong. Missing explicit usage guidance and edge-case behavior, but overall sufficient for a read-only calculation 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 description coverage is 0%, so the description must carry parameter meaning. It documents units (rupees), defaults ('new'), maximum cap for 80C (₹1,50,000), and regime applicability for 80D and HRA. This substantially 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?
States a specific verb (Compute) and resource (Indian income tax) with version/regime scope (FY 2025-26, old/new). Clearly distinguishable from the financial calculator siblings like calculate_emi or calculate_cagr.
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 guidance on when to use this tool vs siblings or when not to use it. Domain is evident from the name, but alternatives like explain_financial_concept are not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate future value of a Systematic Investment Plan (SIP).
Args:
monthly_amount: Monthly SIP contribution in rupees.
annual_return_pct: Expected annual return (e.g. 12 for 12%).
years: Investment horizon in years.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| monthly_amount | Yes | ||
| annual_return_pct | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a pure, side-effect-free computation. The description adds nothing beyond that behavioral profile (no compounding assumption, no rounding/currency caveats), so it neither earns extra credit nor contradicts anything.
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 one-line purpose is front-loaded, and the Args block is terse and structured with no filler. Every line contributes information about the calculation inputs.
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 pure-math tool with no output schema and no nested objects, the description covers purpose and all three inputs completely. It could go further by stating the compounding assumption behind the result, which matters for an agent explaining figures to a user.
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 carry the parameter burden, and it does: it gives units (rupees for monthly_amount), format (12 for 12%), and meaning (investment horizon in years) for all three required arguments. It lacks compounding-frequency assumptions, which keeps it out of 5 territory.
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 (Calculate) and resource (future value of a SIP), so an agent can distinguish it from calculate_cagr, calculate_emi, or calculate_fd_maturity. It does not explicitly name those siblings, 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?
There is no guidance on when to prefer this tool over the many sibling calculators, nor any stated preconditions or exclusions. The name implies 'SIP projection', but the agent must infer that all on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side compare 2-4 products of the same category.
Args:
product_slugs: List of 2-4 product slugs. All must be in the same
category (e.g. all credit cards, or all FDs).
Returns:
A markdown comparison table highlighting feature differences.
| Name | Required | Description | Default |
|---|---|---|---|
| product_slugs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return format (a markdown table highlighting feature differences) and the same-category precondition, which is not in any structured field.
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?
Short and front-loaded, with the core behavior in the first line and supporting detail in Args/Returns blocks. Slightly boilerplate-heavy for a one-parameter tool, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully describes the return (markdown comparison table), and it documents the single parameter's constraints. Complete enough to invoke correctly; only the source/format of valid product slugs is left implicit.
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 carries the burden for the single parameter and does so well: it specifies the type (slugs), the valid range (2-4), and the cross-parameter constraint (all same category with concrete examples). A minor gap is that slug format/source is not 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 verb ('side-by-side compare') and resource ('2-4 products of the same category'), which cleanly separates it from siblings like get_product_details and search_indian_products. An agent can identify the tool's job 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 usage via the 'same category' constraint and the count range, but never states when to prefer this over get_product_details or find_best_card_for_spend. No explicit when/when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Indian financial products and terms in FinanceGenius.AI's catalogue.
Hybrid retrieval (BM25 + semantic + product database, fused with
Reciprocal Rank Fusion) over our product records. Good for questions
anchored to real products: 'which HDFC cards waive the annual fee?',
'what does the Bajaj FD pay for 3 years?', 'ELSS options with a 3-year
lock-in'.
Not a general financial encyclopedia: the curated explainer knowledge
base is not loaded in production, so abstract questions ('how does APR
work?') fall back to product matches. Say so rather than dressing a
product listing up as an explanation.
Args:
query: The financial question or concept to explain.
institution: Optional — narrow search to one institution (e.g. 'hdfc-bank').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| institution | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial non-obvious behavior: the hybrid BM25+semantic+RRF retrieval over product records, and the critical disclosure that the curated explainer KB is not loaded in production so conceptual queries degrade to product matches. That is a real operational caveat an agent could not infer from annotations.
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?
Purpose and retrieval behavior are front-loaded, and the Args block is tight. The docstring-style formatting adds a little structural overhead versus prose, but no sentence is filler — each one (retrieval mechanism, examples, limitation) carries 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 2-param read-only retrieval tool with no output schema, the definition covers purpose, routing, retrieval mechanics, and the failure mode. What it does not describe is the shape of the returned matches (fields, count, pagination), which would help an agent consume results, though it is a minor gap given no output schema is declared.
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 carries the full burden, and it does document both params: query as the financial question/concept, and institution as an optional narrowing filter with a concrete format example ('hdfc-bank'). The query description is close to restating the name, which keeps this from a 5.
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 concrete verb+resource (look up Indian financial products and terms in a specific catalogue) and immediately scopes it against the sibling set of calculators/comparators. The 'not a general financial encyclopedia' clause further sharpens what kind of lookup this is.
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?
Gives explicit when-to-use examples ('which HDFC cards waive the annual fee?'), an explicit when-NOT-to-use case (abstract questions like 'how does APR work?'), and instructs the agent how to behave in the fallback case rather than misrepresenting results. This is exactly what routing guidance should look like.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend Indian credit cards based on spending pattern.
Args:
monthly_spend: Total monthly card spend in rupees.
primary_category: One of 'grocery', 'fuel', 'dining', 'travel',
'online_shopping', 'utilities', 'general'.
Defaults to 'general' — "which card for ₹40,000 a
month?" is a complete question, and making this
required turned it into a validation error.
annual_income: Annual income to filter cards by eligibility (optional).
prefer_no_annual_fee: True to prioritise lifetime-free cards.
Returns:
Top 5 cards with estimated annual cashback/rewards value.
| Name | Required | Description | Default |
|---|---|---|---|
| annual_income | No | ||
| monthly_spend | Yes | ||
| primary_category | No | general | |
| prefer_no_annual_fee | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so safety is covered. The description adds real behavioral value by disclosing the return shape ('Top 5 cards with estimated annual cashback/rewards value') in the absence of an output schema, and notes annual_income acts as an eligibility filter.
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?
Purpose is front-loaded in the first sentence, and the Args/Returns blocks are compact. The parenthetical 'which card for ₹40,000 a month?' is borderline verbose but justifies the default choice, so it 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?
With no output schema, 0% schema coverage, and only generic annotations, the description supplies everything an agent needs: all four parameters documented, the enum values, defaults, units, and the expected return format. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden and does so well: it gives units for monthly_spend (rupees), enumerates all seven valid primary_category values, states its default and rationale, marks annual_income optional, and defines prefer_no_annual_fee as prioritizing lifetime-free cards.
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+domain: 'Recommend Indian credit cards based on spending pattern.' The 'Indian' qualifier and 'spending pattern' input distinguish it from sibling calculators (find_best_fd, calculate_cagr) and from generic product 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?
Explains that monthly_spend alone is a complete question and why primary_category defaults to 'general', which implies usage, but never names an alternative tool or states when NOT to use this versus search_indian_products or compare_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank Indian Fixed Deposits by net-of-tax yield for a given amount + tenure.
Args:
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%).
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.
Returns:
Top 5 FDs sorted by net-of-tax maturity, each showing gross & net amount.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | ||
| amount | Yes | ||
| tax_slab_pct | No | ||
| is_senior_citizen | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns the top 5 FDs sorted by net-of-tax maturity, each showing gross and net amount. This output behavior goes beyond the annotations, though it doesn't discuss data freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then structured into Args and Returns sections. It is appropriately sized with no redundant sentences; each line adds necessary information, especially given the zero schema description coverage.
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 no output schema and 0% schema description coverage, the description is fairly complete: it documents all parameters, the ranking method, and the return format. It lacks context about the underlying FD data source (e.g., whether rates are current or which providers are included), but this is a minor gap given the closed-world annotation.
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 carry the full burden, and it does. It defines each parameter: amount (in rupees), years (tenure, with example 1.5 for 18 months), is_senior_citizen (uses senior-citizen rates, typically +0.5%), and tax_slab_pct (income tax slab as 5/10/20/30, noting FD interest is fully taxable and used for net-yield ranking). This adds clear meaning beyond the bare schema titles.
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 (Rank) and resource (Indian Fixed Deposits) with the ranking criterion (net-of-tax yield) and required inputs (amount + tenure). This clearly distinguishes it from sibling tools like calculate_fd_maturity, which computes maturity for a given FD, without needing to open either 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 explains what the tool does but gives no explicit guidance on when to use it versus alternatives such as calculate_fd_maturity or compare_products. There are no when-not conditions or named alternatives, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific product by its slug.
Args:
product_slug: The URL-safe identifier (e.g. 'hdfc-millennia-credit-card').
Get slugs from search_indian_products.
| Name | Required | Description | Default |
|---|---|---|---|
| product_slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so safety is covered. The description adds only the slug-source dependency and nothing about the shape, size, or freshness of the 'full details' 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?
One-line purpose sentence is front-loaded and followed by a compact Args block. The Args formatting mirrors the schema, adding slight redundancy, but nothing is wasted.
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 read-only lookup with full annotation coverage, the description supplies everything needed to call it correctly, including value provenance. The only omission is what fields the returned details contain, which is a minor gap without an output schema.
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 carries the semantic load: it defines product_slug as a URL-safe identifier, gives a concrete example ('hdfc-millennia-credit-card'), and tells the agent where to source valid values. That meaningfully compensates for the bare 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?
States a specific verb and resource ('Get full details of a specific product') with the lookup key (slug), and names the sibling that produces slugs (search_indian_products). It does not say what 'full details' comprises or contrast directly with compare_products, so it is clear but not fully sibling-differentiated.
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?
Gives a concrete prerequisite workflow: obtain the slug from search_indian_products before calling. It stops short of stating when not to use this tool (e.g. use compare_products or search_indian_products for browsing), so no exclusions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search FinanceGenius.AI's catalogue of Indian financial products.
Args:
product_type: One of 'credit_card', 'loan', 'deposit', 'insurance', 'investment'.
Omit to search across all categories.
search_query: Free-text search (matches name + description).
E.g. 'cashback', 'home loan', 'HDFC'.
min_rating: Filter to products with rating >= this value (1-5 scale).
Returns:
Up to 10 matching products, sorted by popularity.
| Name | Required | Description | Default |
|---|---|---|---|
| min_rating | No | ||
| product_type | No | ||
| search_query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world scope, so safety is covered. The description adds genuinely useful behavior beyond that: results are capped at 10, sorted by popularity, and free text matches name + description. It doesn't discuss pagination or how to get more than 10 results, which is the only real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then cleanly structured into Args and Returns sections. Every line conveys actionable information with no filler or repetition of the tool name.
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 exists, but the Returns section covers the result shape, cap, and ordering. Parameters are fully documented and annotations cover the safety profile, so an agent has everything needed to call this 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 must carry the full burden — and it does. Each of the three parameters is given type, allowed values, omission behavior, and concrete examples ('cashback', 'home loan', 'HDFC', 1-5 rating scale).
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 ('Search') and a well-scoped resource (FinanceGenius.AI's catalogue of Indian financial products), naming the domain explicitly. An agent can distinguish it from get_product_details (single item lookup) and compare_products (side-by-side comparison) from the description alone.
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 Args block implies usage ('Omit to search across all categories') and the free-text examples hint at query style, but there is no explicit statement of when to prefer this tool over siblings like compare_products or find_best_card_for_spend. Usage is implied, not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_best_card_for_spend2 fields changedInput schema / properties / primary_category / defaultAdded value: +"general"Input schema / requiredPrevious value: -[
- "monthly_spend",
- "primary_category"
-]New value: +[
+ "monthly_spend"
+]calculate_cagrcalculate_emicalculate_fd_maturitycalculate_indian_income_taxcalculate_sipcompare_productsexplain_financial_conceptfind_best_card_for_spendfind_best_fdget_mutual_fund_navget_product_detailssearch_indian_productsFinancial simulator for Indian salaries: loans, taxes, SIPs and 50-year FIRE plans.
MFAPI.in MCP — Indian mutual-fund NAV (net asset value) data.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp
Add one secure layer between your agents and this server.
