India's financial MCP — Indian cards, loans, FDs, MFs; EMI/SIP/tax calcs; NSE/BSE quotes; RAG.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: calculators for specific financial formulas, search/query tools for product discovery, and recommendation tools for specific product types. No two tools appear to overlap; even the calculators are clearly differentiated by their inputs and outputs.
All tool names follow a consistent verb_noun pattern (e.g., calculate_*, get_*, search_*, find_best_*, compare_products, explain_financial_concept). The verbs clearly indicate the action, and the nouns specify the target resource or domain. Naming is uniform with lowercase underscores throughout.
With 12 tools, the server provides a comprehensive yet focused set of capabilities for a financial assistant. The count is well within the ideal range for a specialized domain, with each tool contributing a distinct function without unnecessary bloat.
The server covers a broad range of financial needs: calculations, product search, comparison, recommendations for credit cards and FDs, fund NAV lookup, and concept explanations. Minor gaps exist, such as no dedicated loan or insurance recommendation tools, but these can be worked around using search and compare tools.
calculate_cagrAInspectCalculate 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it offers no details about return format (e.g., decimal vs percentage), handling of edge cases (e.g., zero or negative values), or any side effects. It only describes the calculation intent, which is minimal.
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, starting with the purpose and immediately listing parameter definitions. Every sentence earns its place, with no fluff or 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 simple calculator, the description covers purpose and all parameters, but it lacks an explicit statement about the return value or output format. Since there is no output schema, this missing information is a notable gap. The description is adequate but not fully self-contained for an agent to know exactly what to expect from the invocation.
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 provides zero description coverage, but the description compensates well by explaining each parameter: 'initial_value: Initial investment in rupees', 'final_value: Final value in rupees', and 'years: Holding period in years'. This adds unit and context beyond the bare schema types, though constraints and value ranges are still absent.
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 the Compound Annual Growth Rate (CAGR) of an investment' with a specific verb and resource. The name and description distinguish this from sibling tools like calculate_emi and calculate_fd_maturity, which involve different 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 provides no guidance on when to use this tool versus alternatives. It simply states what it does, leaving the agent to infer usage from the name alone. No prerequisites, exclusions, or comparisons to sibling tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_emiAInspectCalculate 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?
With no annotations, the description must disclose behavior. It returns monthly EMI, total interest, total payment, and an amortisation schedule. However, it does not mention rounding, input validation, interest calculation assumptions, or any side effects. For a pure calculation, this is adequate but not rich.
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 efficiently structured: a one-sentence purpose followed by clean Args/Returns sections. Every line adds value, particularly the units and schedule detail, and there is no redundancy with the schema.
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 three-parameter calculator with no output schema, this description provides sufficient context: inputs, units, and output components including the schedule type. It lacks edge-case handling or precise schedule structure, but remains complete for typical 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 compensate. It does: all three parameters are explained with units ('rupees', 'percentage', 'months') and an example ('10.5 for 10.5%'). This adds meaning beyond the schema's bare titles, though it lacks explicit constraints like positive values or reasonable ranges.
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: 'Calculate EMI for a loan' with a specific qualifier 'year-by-year amortisation schedule.' This distinguishes it from sibling finance calculators like calculate_sip and calculate_cagr by naming the exact resource and operation.
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 the tool by specifying loan-related inputs and outputs (EMI, amortisation schedule). However, it does not explicitly compare against alternatives or provide exclusion criteria, so it stops short of being fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_fd_maturityAInspectCalculate 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?
With no annotations, the description carries behavioral disclosure. It explicitly says the calculation uses compounding, lists allowed compounding frequencies, and adds a real-world note about Indian FDs. It does not describe the return format or edge case handling, but for a calculator this covers the key behavioral choice.
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 concise one-line purpose followed by an Args section. Each parameter is documented in a single, readable line with no filler 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?
For a simple calculation tool with no output schema, the description covers all parameters and provides domain context. The only gap is that it doesn't explicitly state that the return value is the maturity amount in rupees, leaving that slightly implied.
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 0% description coverage, and the description fully compensates: it gives units (rupees, percentage, years), an example for years ('1.5 for 18 months'), and explicit allowed values for compounding. This adds significant meaning beyond 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?
The description opens with 'Calculate FD maturity amount with compounding,' a specific verb plus resource. This clearly distinguishes it from sibling financial calculators 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 tool is clearly implied for FD maturity calculations, and the note that 'Most Indian FDs compound quarterly' provides contextual guidance. However, it does not explicitly state when to use this tool over alternatives or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_indian_income_taxAInspectCompute 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?
With no annotations, the description carries the behavioral transparency burden. It discloses that deductions are 'old regime only', mentions maximum values for 80C, and specifies the return format (slab breakdown, total tax, effective rate, regime comparison). However, it does not explain nuances like tax slabs, cess, or edge cases, which could be relevant for a tax 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 well-structured as a docstring with Args and Returns sections. It is concise, with no filler, and every sentence contributes to understanding the tool's input and output. The format is appropriate for a multi-parameter calculation tool.
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 income tax calculation and the absence of annotations or output schema, the description is reasonably complete. It covers key parameters, restrictions, and return values. However, it could be more explicit about whether it compares both regimes or only the selected one, and could mention assumptions about income types or tax rates.
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 fully compensates by explaining each parameter in the Args section, including constraints (e.g., max ₹1,50,000 for 80C, 'old regime only' for deductions). This adds significant meaning beyond the raw schema 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 computes Indian income tax for FY 2025-26 under old or new regime, which is a specific verb (compute) and resource (income tax). It distinguishes itself from sibling tools like calculate_emi or calculate_sip by focusing on income tax with regime options and deduction parameters.
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: for calculating Indian income tax with regime and deduction options. It does not explicitly mention alternatives or exclusions, but the parameter details and return description imply its specific use case, which is distinct from the financial calculators available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_sipAInspectCalculate 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?
No annotations are provided, so the description must disclose behavioral traits itself. It only restates that it calculates a value, with no mention of assumptions, return format, or whether this is a pure read-only 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?
The description is short, front-loaded with purpose, and the Args block adds necessary parameter context without redundant prose.
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, inputs are well covered, but there is no statement about the return value or compounding assumption. Without an output schema, this leaves the agent to infer the result format.
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 coverage, the description compensates by explaining each parameter with units and an example: monthly amount in rupees, annual return as 12 for 12%, and years as horizon. This is sufficient for an agent to supply correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line specifies the tool's exact operation: calculating the future value of an SIP. It clearly distinguishes this from sibling calculators like calculate_cagr and calculate_emi by naming the specific financial instrument.
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 given about when to use this tool versus other financial calculators. It neither mentions alternatives nor describes scenarios, leaving the agent to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_productsAInspectSide-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?
With no annotations, the description carries the full burden. It discloses the return format ('markdown comparison table highlighting feature differences') and the categorical constraint on inputs. It does not mention error handling for invalid slugs or mixed categories, but for a read-only comparison tool, the disclosed traits are meaningful and go 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 two sentences plus a structured Args/Returns section. It is concise, front-loaded with the purpose, and every sentence adds value—the Args section clarifies constraints, and the Returns section sets expectations for the output.
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 single parameter and no output schema, the description adequately covers input requirements and output format. It does not explain how to obtain product slugs or what happens if categories are mixed, but these are likely handled by sibling tools like search_indian_products and are not critical for the tool's core purpose.
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 only defines product_slugs as an array of strings with no description and 0% coverage. The description fully compensates by explaining the allowed count (2-4), the same-category requirement, and giving concrete examples (credit cards, FDs), making the parameter semantics clear.
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 specific verb 'compare' and resource 'products', and clarifies the scope with 'side-by-side' and '2-4 products of the same category'. This clearly distinguishes it from sibling tools like get_product_details (single product) or 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?
It explicitly states the prerequisite that all products must be in the same category, with examples (credit cards, FDs), which guides when to use. However, it does not mention alternatives like 'use get_product_details for a single product' or 'use search_indian_products to find products first', so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_financial_conceptAInspectAnswer financial questions using FinMall.AI's hybrid knowledge base.
Searches across product brochures, regulatory guides, calculators help,
and live product database using BM25 + semantic + product DB search
fused with Reciprocal Rank Fusion. Best for explainers like:
'what is a critical illness rider?', 'how does APR work?',
'difference between ELSS and PPF?'.
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?
With no annotations, the description carries the full burden, and it does reveal the hybrid search mechanism (BM25 + semantic + product DB with Reciprocal Rank Fusion) and the sources searched. However, it does not disclose what the response format looks like (e.g., a single answer with citations) or any limitations such as coverage or latency. It adds some behavioral context but not complete 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 concise and well-structured: a one-sentence purpose, a method explanation, example queries, and a clear parameter list. Every sentence adds value, and the formatting makes it easy to parse. No redundancy or 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 moderately complex with two parameters and no output schema. The description adequately explains the purpose, usage context, and parameters, but it omits details about the return value or output structure. Given the lack of an output schema, this is a notable gap, though the description is otherwise complete for selecting and invoking the 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 fully explain the parameters. It does: 'query: The financial question or concept to explain' and 'institution: Optional — narrow search to one institution (e.g. 'hdfc-bank')'. This adds meaningful semantics beyond the bare schema, including optionality and an example, fully compensating for the lack of schema 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 function: 'Answer financial questions using FinMall.AI's hybrid knowledge base.' It provides specific examples like 'what is a critical illness rider?' and 'how does APR work?', which distinguish it from sibling tools focused on calculations and product searches. The verb 'explain' and resource 'financial concept' are 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 explicitly says 'Best for explainers like...' and provides example queries, indicating when to use the tool. It does not explicitly exclude alternative tools or name them, but the context clearly differentiates it from calculation and product-lookup siblings. This gives clear usage context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_card_for_spendAInspectRecommend 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'.
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 | Yes | ||
| prefer_no_annual_fee | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the return format (Top 5 cards with estimated annual cashback/rewards) and mentions eligibility filtering and fee preference, but does not discuss limitations, assumptions, or whether this is a read-only operation.
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 a clear purpose and structured with Args/Returns blocks. Every sentence adds value with no filler 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?
Despite lacking an output schema, the description explains the tool's purpose, all parameters, and the return value. It is adequately complete for a straightforward recommendation tool, though it could elaborate on what 'best' means (e.g., ranking criteria) or mention any data sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all four parameters, explaining units (rupees), category options, eligibility filtering, and prioritization behavior. This compensates for 0% schema coverage, though detailed constraints like ranges are not provided.
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 'Recommend Indian credit cards based on spending pattern' – a specific verb and resource that distinguishes it from sibling tools like calculate_* and compare_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?
The description implies its usage context (when you need credit card recommendations) but does not explicitly state exclusions or alternatives. No guidance is given for when not to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_best_fdAInspectRank 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?
No annotations are provided, so the description must fully disclose behavior. It does so by explaining that results are sorted by net-of-tax maturity, that FD interest is fully taxable, and that it returns top 5 FDs with gross & net amounts. It stops short of mentioning data source or limitations, but the core behavior is 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 well-structured with a clear purpose statement followed by a concise Args section and a Returns note. Every sentence adds value; there is no unnecessary fluff. The docstring format is appropriate for the complexity, and the key information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is remarkably complete. It covers all inputs, the ranking logic, special cases (senior citizen, tax slab), and the output structure (top 5, gross and net). This enables an agent to use the tool correctly without additional 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?
Schema description coverage is 0%, so the description must compensate, and it does comprehensively. Each parameter is explained in the Args section: amount, years, is_senior_citizen (with typical rate increment), and tax_slab_pct (with valid values and its role in net-yield ranking). This adds far more meaning than the schema's property titles alone.
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 primary function: 'Rank Indian Fixed Deposits by net-of-tax yield for a given amount + tenure.' This specific verb ('rank') and resource ('Indian Fixed Deposits') distinguishes it from siblings like 'calculate_fd_maturity' and 'compare_products', which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when ranking FDs by net-of-tax yield for a specific amount and tenure. It also explains the role of key parameters like is_senior_citizen and tax_slab_pct. However, it does not explicitly mention alternatives or when not to use it, so it misses the highest level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsAInspectGet 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?
With no annotations provided, the description must carry the transparency burden. It states 'Get full details' which implies a read-only operation, but does not describe the return format, potential errors, or any limitations. It is minimally adequate but lacks depth.
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 clear docstring style with an Args section. Every sentence serves a purpose: defining the tool and explaining the parameter. No filler 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 tool with one parameter and no output schema, the description covers the essential purpose and parameter acquisition. However, 'full details' is vague about what fields or structure to expect in the response, which would be helpful given no 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 coverage is 0%, so the description fully compensates. It explains the slug format ('URL-safe identifier'), provides a concrete example, and tells where to obtain valid values, adding significant meaning beyond the schema's '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 uses a specific verb ('Get') and resource ('full details of a specific product by its slug'), clearly distinguishing it from siblings like search_indian_products (which finds products) and compare_products (which compares).
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 tells the agent to get slugs from search_indian_products, establishing a clear prerequisite and usage context. It doesn't mention exclusions, but the purpose is sufficiently distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_indian_productsAInspectSearch FinMall.AI's catalog 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?
With no annotations, the description carries the full burden. It discloses match logic ('matches name + description'), result cap ('up to 10'), and sorting ('by popularity'). This provides solid transparency for a read-only search operation, though it doesn't mention error behavior 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 concise and well-structured: a clear purpose sentence, an Args section for parameter details, and a Returns section for output. Every line adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately covers all aspects: parameter semantics, return format, and limitations. It is complete enough for an agent to invoke correctly, including examples and defaults.
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 fully compensates by explaining each parameter: product_type's enum values, search_query's free-text behavior with examples, and min_rating's threshold. This goes far beyond 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?
The first sentence clearly states the tool searches FinMall.AI's catalog of Indian financial products, using a specific verb ('Search') and resource. This distinguishes it from sibling tools like compare_products or find_best_card_for_spend, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter-level guidance (e.g., 'Omit to search across all categories') but no explicit when-to-use versus alternatives. Usage is implied from the clear purpose, but there are no exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!