MCP server wrapping the calcnook financial engine. Gives any MCP-compatible AI agent (Claude Code, Cursor, Goose, Continue, etc.) native access to 17 calculation tools across compound interest, SIP/DCA, loans, retirement planning, BMI/BMR, Islamic finance, income tax (US/UK/CA/AU/India), VAT, End of Service Gratuity, and more.
Preferred — zero setup via uvx:
uvx calcnook-mcpOr pip:
pip install calcnook-mcp
calcnook-mcpRelated MCP server: Finance MCP Server
Add to claude_desktop_config.json (or your MCP settings):
{
"mcpServers": {
"calcnook": {
"command": "uvx",
"args": ["calcnook-mcp"]
}
}
}{
"mcpServers": {
"calcnook": {
"command": "uvx",
"args": ["calcnook-mcp"]
}
}
}Use the same JSON block in the respective mcp_servers config section.
Tool | What it does | Example query |
| Future value of a lump-sum at compound interest | "What will ₹1L grow to in 10 years at 7%?" |
| SIP (India) / DCA (global) with optional annual step-up | "SIP ₹5000/month for 15 years at 12%" |
| EMI / mortgage amortization with optional extra payment | "EMI for ₹30L home loan at 8.5% for 20 years" |
| Corpus needed, monthly SIP to reach corpus, safe withdrawal (4% rule) | "How much SIP to reach 2Cr in 20 years?" |
| BMI + WHO category, BMR (Mifflin-St Jeor), TDEE | "BMI for 70kg 175cm" |
| Convert between any currencies using caller-supplied rates | "Convert $1000 to INR at 83.5" |
| Format amount as currency string; INR supports lakh/crore | "Show 25000000 as crores" |
| Zakat al-Mal (2.5% wealth obligation): all asset categories, nisab check | "Zakat on $25k savings + $5k stocks" |
| Murabaha, Ijarah, or Mudarabah financing calculator | "Murabaha for $100k house at 30% markup over 5 years" |
| Monthly savings needed to fund Hajj by target year | "Save monthly for Hajj costing $8000 in 5 years" |
| AAOIFI Sharia compliance screen (debt, cash, receivables, haram revenue ratios) | "Is this tech stock halal given these financials?" |
| Federal/national income tax for US, UK, CA, AU, India (2026) | "India income tax on ₹12L new regime" |
| Traditional 401(k) contribution analysis or Roth IRA phase-out check | "Am I eligible for Roth IRA at $155k income?" |
| End of Service Gratuity for UAE or Saudi Arabia | "UAE gratuity for 7 years at AED 8000 basic salary" |
| VAT for UAE (5%) or Saudi Arabia (15%) | "UAE VAT on AED 1000 product" |
| ZATCA-collected Zakat estimate for Saudi/GCC nationals (2.5% of base) | "Saudi corporate zakat on SAR 1M base" |
| India electricity bill with BESCOM/MSEB/BSES presets or custom slabs | "BESCOM bill for 250 units in Bangalore" |
calcnook engine — the open-source personal finance calculation library.
DISCOM presets (BESCOM_RESIDENTIAL, MSEB_RESIDENTIAL, BSES_RESIDENTIAL) are importable directly from calcnook.countries.india.electricity_bill for custom slab configuration.
MIT
Health metrics in three modes: (1) bmi — Body Mass Index and WHO category; (2) bmr — Basal Metabolic Rate (Mifflin-St Jeor); (3) tdee — Total Daily Energy Expenditure from BMR and activity level. Example queries: 'BMI for 70kg 175cm', 'BMR for 30-year-old male 80kg 180cm', 'TDEE for moderately active person with BMR 1700'.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Which health metric to compute. | |
| weight_kg | No | [bmi, bmr] Body weight in kilograms. | |
| height_cm | No | [bmi, bmr] Height in centimetres. | |
| age_years | No | [bmr] Age in whole years. | |
| sex | No | [bmr] Biological sex for the Mifflin-St Jeor equation. | |
| bmr_kcal | No | [tdee] Basal Metabolic Rate in kcal (output of bmr mode). | |
| activity_level | No | [tdee] Activity level: sedentary, light, moderate, active, very_active. |
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 states the tool computes metrics using specific formulas (e.g., Mifflin-St Jeor) and mentions WHO categories for BMI. However, it does not detail return format, rounding, or constraints. This is adequate for a straightforward calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with embedded examples, making it concise and informative. It front-loads the three modes and uses parentheses to clarify. Every element serves a purpose.
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 7 parameters and no output schema, the description explains the three modes and their associated outputs (BMI category, BMR value, TDEE from BMR+activity). It covers the essential context for an agent to select and invoke the correct mode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the bar is lower. The description adds value by grouping parameters by mode (e.g., [bmi, bmr] for weight_kg) and providing example queries that illustrate parameter usage. This exceeds what the schema alone offers.
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 specifies the tool computes three distinct health metrics (bmi, bmr, tdee) using named formulas (Mifflin-St Jeor) and provides example queries. This clearly distinguishes it from sibling calculator tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the three modes and gives example queries for each, making it clear when to use each mode. It does not explicitly state when not to use or compare to alternatives, but the mode separation is intuitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the future value of a single lump-sum investment at compound interest. Universal — no country specifics. Example queries: 'What will ₹1L grow to in 10 years at 7%?', 'future value of $5000 invested at 8% annually for 20 years compounded monthly'.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | Yes | Initial deposit amount (any currency). | |
| annual_rate | Yes | Decimal annual interest rate, e.g. 0.07 for 7%. | |
| years | Yes | Time horizon in years. | |
| compounding_per_year | No | Compounding frequency: 12=monthly (default), 4=quarterly, 1=annual. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is a universal mathematical calculation with no side effects, but does not disclose the output format, return value details, or edge case behavior (e.g., zero principal). Adequate but 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?
Two concise sentences plus examples, front-loaded with the core purpose. No wasted words; every sentence serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple compound interest calculator with full schema coverage and no output schema, the description is fairly complete. It includes purpose, scope, and usage examples. Minor gap: no explicit description of the return value, but it is 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?
Schema coverage is 100%, so baseline is 3. The description does not add additional semantic meaning beyond the schema descriptions and examples, which are helpful but not necessary for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Compute the future value of a single lump-sum investment at compound interest', using a specific verb and resource. It distinguishes from siblings by indicating 'single lump-sum' (vs SIP) and 'Universal — no country specifics' (vs country-specific 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?
Description provides examples of queries to illustrate usage but does not explicitly state when to use this tool versus sibling tools (e.g., SIP calculator, loan payment). No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate End of Service Gratuity (EOSG) for UAE or Saudi Arabia. UAE: Federal Decree-Law 33/2021 — 21 days/year for first 5 years, 30 days/year after. Saudi: Saudi Labour Law Articles 84-87 — ½ month/year first 5 years, 1 month/year after; resignation factor applies. Example queries: 'UAE gratuity for 7 years service at AED 8000 basic salary', 'Saudi EOSG if I resign after 6 years on SAR 5000 salary'.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country: 'ae' (UAE) or 'sa' (Saudi Arabia). | |
| monthly_basic_salary | Yes | Monthly basic salary in local currency (AED for UAE, SAR for KSA). Excludes allowances. | |
| years_of_service | Yes | Total years of service (fractional years accepted, e.g. 5.5). | |
| contract_type | No | [ae] Contract type — both compute identically under 2021 Decree-Law. | limited |
| end_reason | No | [sa] Reason for leaving — affects entitlement factor for resignation. | termination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the calculation formulas for each country and notes that contract type is identical under UAE law and end reason affects Saudi entitlement. However, it does not mention response format, rounding behavior, or handling of invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with key information front-loaded. It includes formulas and examples efficiently. Slightly verbose but generally well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return value. It does not specify what the output looks like (e.g., a number with currency). Also lacks details on edge cases or fractional calculations, which are likely relevant for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the formulas, providing example queries, and clarifying that contract_type has identical effect for UAE and that end_reason affects Saudi entitlement. This goes beyond the schema's parameter 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 calculates End of Service Gratuity for UAE or Saudi Arabia, which distinguishes it from sibling calculator tools. It provides specific verbs ('Calculate') and resources (EOSG for two jurisdictions), making the 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 includes example queries and references to specific laws, giving clear context for when to use the tool. However, it does not explicitly state when not to use it or list alternative tools for related calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the monthly savings needed to fund a Hajj pilgrimage by a target year. Accounts for existing savings and halal investment returns (sukuk/equity). Example queries: 'how much to save monthly for Hajj costing $8000 in 5 years', 'hajj savings plan with ₹50000 already saved, 6% return, 3 years'.
| Name | Required | Description | Default |
|---|---|---|---|
| hajj_cost_target | Yes | Total estimated cost of Hajj in today's currency. | |
| years_to_hajj | Yes | Number of years until Hajj trip. | |
| current_savings | No | Existing savings already set aside. | |
| expected_annual_return | No | Expected annual halal investment return as decimal (e.g. 0.06 for 6%). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool calculates monthly savings and considers savings and returns, but does not disclose key behavioral traits like the formula used, compounding frequency, or whether inflation is considered. This is adequate for a straightforward financial calculation but could be more detailed.
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 two sentences plus example queries. It is front-loaded with the core purpose. Every sentence adds context, and the examples efficiently illustrate usage. A slight deduction for missing output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does not explain the return format beyond implying a monthly savings amount. It also does not mention handling of edge cases like zero returns or existing savings exceeding target. For a simple calculator with 4 parameters, this is adequate but not comprehensive.
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 100% description coverage, so the schema already explains the parameters. The description adds value through example queries that demonstrate parameter usage but does not provide additional semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates monthly savings needed for a Hajj pilgrimage, using a specific verb and resource. It provides example queries that illustrate the use case. However, it does not explicitly differentiate from sibling calculators like 'calculate_islamic_financing' or 'calculate_compound_interest', though the Hajj-specific context makes it distinct.
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 that the tool accounts for existing savings and halal investment returns, and gives example queries that imply typical usage scenarios. However, it lacks explicit guidance on when not to use this tool (e.g., for non-Hajj savings) or mention of alternative tools for similar calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate income tax for US, UK, Canada, Australia, or India (2026 / FY 2025-26). country='us': federal tax with brackets by filing_status. country='uk': income tax + National Insurance (2025/26). country='ca': federal tax with Basic Personal Amount credit. country='au': income tax + Medicare Levy + optional HECS-HELP. country='in': India new/old regime with 87A rebate + cess. Example queries: 'US tax on $85000 income married filing jointly', 'UK income tax on £50000 salary', 'India income tax ₹12L new regime'.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country code: us, uk, ca, au, in. | |
| income | Yes | Gross annual income in local currency. | |
| filing_status | No | [us] Filing status. Default: single. | |
| has_hecs_debt | No | [au] Whether HECS-HELP compulsory repayment applies. | |
| regime | No | [in] Tax regime: 'new' (default, lower rates) or 'old' (with deductions). | new |
| province | No | [ca] Province/territory code (e.g. 'ON'). Accepted but provincial tax not yet computed. | |
| year | No | Tax year. Only 2026 is supported across all countries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses country-specific tax components (e.g., 'federal tax with brackets', 'income tax + National Insurance') and acknowledges accepted-but-uncomputed province parameter. Missing details on errors or 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 slightly verbose but each sentence adds unique context. Front-loaded with purpose. Could be more concise by grouping country details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return values (e.g., breakdown). It omits what the tool returns (total tax? breakdown?). For 7 parameters, it covers input well but misses output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented). Description adds value by explaining country-specific behavior (e.g., 'required if country=us') and providing defaults, going beyond basic 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 specifies the tool calculates income tax for five countries, with distinct per-country details (e.g., brackets, NI, Medicare Levy). It clearly distinguishes from sibling tools like calculate_vat or calculate_loan_payment by focusing on income tax.
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?
Example queries show usage patterns for different countries. However, no explicit guidance on when not to use this tool versus alternatives; context is inferred from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate an Indian electricity bill using progressive slab tariffs. Use a built-in DISCOM preset ('BESCOM' for Karnataka, 'MSEB' for Maharashtra, 'BSES' for Delhi) or supply custom slabs. The constants BESCOM_RESIDENTIAL, MSEB_RESIDENTIAL, BSES_RESIDENTIAL are importable from calcnook.countries.india.electricity_bill for custom use. Example queries: 'electricity bill for 250 units in Bangalore (BESCOM)', 'Delhi BSES bill for 400 units with ₹100 fixed charge'.
| Name | Required | Description | Default |
|---|---|---|---|
| units_consumed | Yes | Total electricity consumption in kWh for the billing period. | |
| preset | No | Pre-built DISCOM tariff: BESCOM (Karnataka), MSEB (Maharashtra), BSES (Delhi). | |
| slabs | No | Custom slab list: each item is [upper_units, rate_per_unit]. Last upper_units can be 'inf'. | |
| fixed_charges | No | Monthly fixed / demand charges in ₹. | |
| fuel_surcharge_per_unit | No | Fuel adjustment charge per unit in ₹/kWh. | |
| electricity_duty_percent | No | State electricity duty as a percentage of energy + fuel charges. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It explains progressive slab tariffs, presets, custom slabs, fixed charges, fuel surcharge, electricity duty, and mentions importable constants. However, it lacks details on error handling 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 three sentences and efficiently conveys the tool's purpose, presets, examples, and importable constants. It is front-loaded with the primary purpose and well-structured, though slightly dense.
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 annotations and no output schema, the description covers usage, presets, custom slabs, and examples. It references importable constants for custom use. The return format (calculated bill) is not explicitly detailed but can be inferred for a 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?
Input schema coverage is 100% with each parameter having a description. The description adds value by explaining the slab format (last can be 'inf'), mentioning importable constants, and providing example queries that demonstrate parameter usage. This goes beyond the schema 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 purpose: calculating Indian electricity bills using progressive slab tariffs. It mentions specific presets (BESCOM, MSEB, BSES) and custom slabs, distinguishing it from sibling tools which handle different calculations (BMI, compound interest, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidelines are provided via example queries ('electricity bill for 250 units in Bangalore (BESCOM)', 'Delhi BSES bill for 400 units with ₹100 fixed charge'), indicating typical use cases. While it doesn't explicitly state when not to use, the sibling list implies this is the only Indian electricity bill tool, making context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate Islamic financing arrangements — Sharia-compliant alternatives to conventional loans. Three instruments: (1) murabaha — cost-plus sale (Sharia mortgage/asset purchase); (2) ijarah — lease-to-own (Sharia auto-loan/equipment); (3) mudarabah — profit-sharing investment (Sharia FD alternative). Example queries: 'murabaha financing for $100k house at 30% markup over 5 years', 'ijarah lease for car worth $30k at $600/month for 5 years', 'mudarabah: investor puts $100k, profit $20k split 70/30'.
| Name | Required | Description | Default |
|---|---|---|---|
| instrument | Yes | Which Islamic financing instrument to compute. | |
| asset_cost | No | [murabaha/ijarah] Asset purchase price. | |
| markup_percent | No | [murabaha] Total markup as % of asset cost, e.g. 30.0 for 30%. | |
| tenure_years | No | [murabaha] Repayment tenure in years. | |
| down_payment | No | [murabaha] Upfront payment by client. | |
| monthly_rent | No | [ijarah] Agreed monthly lease payment. | |
| lease_years | No | [ijarah] Lease duration in years. | |
| transfer_fee | No | [ijarah] Token ownership-transfer fee at end of lease. | |
| capital | No | [mudarabah] Capital provided by investor. | |
| actual_profit_amount | No | [mudarabah] Realised profit (positive) or loss (negative). | |
| investor_share_ratio | No | [mudarabah] Investor profit share as decimal, e.g. 0.70 = 70%. | |
| years | No | [mudarabah] Optional: years to compute annualised return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains the three instruments and their mechanics but does not explicitly state that this is a non-destructive calculator with no side effects, auth requirements, or rate limits. Since annotations are absent, the description carries the full transparency burden but is not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus examples, tightly packed with information. Uses clear structure with numbered instruments and example queries. No unnecessary words—every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters and three instruments, the description covers the purpose and usage well. However, it does not explain what the tool returns (no output schema), so the agent must infer output format from examples. Slightly incomplete for a fully self-contained definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by grouping parameters per instrument and providing realistic examples that illustrate usage, e.g., 'markup as % of asset cost' and profit split ratio. This reinforces understanding beyond schema 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?
Description clearly states it calculates Islamic financing arrangements, lists three specific instruments (murabaha, ijarah, mudarabah) with brief explanations, and provides example queries. This distinguishes it from sibling tools like calculate_loan_payment or calculate_compound_interest.
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?
Examples show when to use each instrument (e.g., 'murabaha financing for $100k house...'), providing practical guidance. However, it lacks explicit when-not-to-use or comparison with conventional loan tools, so not a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate monthly EMI / mortgage payment for a fixed-rate loan. Returns total interest, total payment, and optional full amortization schedule. Works for home loans, car loans, personal loans, mortgage. Example queries: 'EMI for ₹30L home loan at 8.5% for 20 years', '$300k mortgage at 6.5% for 30 years', 'what if I pay $200 extra per month on my car loan'.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | Yes | Loan principal amount. | |
| annual_rate | Yes | Decimal annual interest rate, e.g. 0.085 for 8.5%. | |
| years | Yes | Loan tenure in whole years. | |
| extra_monthly_payment | No | Additional monthly payment above EMI (reduces tenure). | |
| include_schedule | No | If true, include the full month-by-month amortization table. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it returns total interest, total payment, and optional amortization schedule, and notes the extra payment reduces tenure. However, it does not mention assumptions like monthly compounding, rounding behavior, or currency handling, which would help the agent assess side effects or 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?
The description is extremely concise: two sentences plus example queries. Key information (purpose, return values, supported loan types, example inputs) is front-loaded with no wasted words. Every sentence serves a purpose.
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 5 parameters and no output schema, the description adequately covers what the tool does and returns (total interest, total payment, optional schedule) and provides realistic examples. It could optionally mention that the output currency matches the principal input, but overall it is sufficiently complete for an agent to understand its return value and use it alongside sibling financial calculators.
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 schema coverage is 100% and each parameter is described in the schema, the description adds valuable context: example queries show how parameters are used together, and it explicitly explains that extra_monthly_payment reduces tenure and that include_schedule returns a full amortization table. This goes beyond the schema's straightforward 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 verb 'calculate' and the resource 'monthly EMI / mortgage payment for a fixed-rate loan'. It lists specific loan types (home, car, personal, mortgage) and provides example queries that illustrate its scope, differentiating it from sibling tools like calculate_compound_interest or calculate_retirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing loan types and examples but does not explicitly state when not to use the tool (e.g., for variable-rate loans or Islamic financing which has a sibling tool). No alternative tools are mentioned, leaving the agent to infer appropriateness from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retirement planning in three modes: (1) corpus_needed — how much lump-sum do I need at retirement? (2) monthly_contribution_for — how much SIP to hit a target corpus? (3) safe_withdrawal — how much can I safely withdraw (4% rule)? Example queries: 'how much corpus to retire with ₹50k/month for 30 years', 'SIP needed to build 2 crore corpus in 20 years', 'safe monthly withdrawal from $1M at 4% rule'.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Which calculation to perform. | |
| annual_expense | No | [corpus_needed] Annual expense in today's money. Required for corpus_needed. | |
| years_in_retirement | No | [corpus_needed] Number of years in retirement. | |
| post_retirement_return | No | [corpus_needed] Decimal nominal annual return during retirement. | |
| inflation | No | [corpus_needed] Decimal annual inflation rate. | |
| target_corpus | No | [monthly_contribution_for] Target retirement corpus. Required. | |
| years_to_retirement | No | [monthly_contribution_for] Years until retirement. Required. | |
| annual_return | No | [monthly_contribution_for] Decimal expected annual return. | |
| current_savings | No | [monthly_contribution_for / corpus_needed] Existing savings that will compound. | |
| corpus | No | [safe_withdrawal] Retirement corpus (lump-sum). Required. | |
| withdrawal_rate | No | [safe_withdrawal] Decimal annual withdrawal rate (default 0.04 = 4% rule). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It explains the three calculation modes and their inputs, but does not disclose output format, currency assumptions, error handling, or edge cases (e.g., negative values).
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 well-structured with numbered modes and example queries. Every sentence adds value, no redundancy. Efficiently communicates complex functionality.
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 11 parameters and no output schema, the description provides good clarity on modes and inputs. Lacks explicit output format (e.g., returns number in currency units) and edge case handling, but covers typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by grouping parameters per mode and providing usage examples. It helps clarify which parameters are required for each mode beyond the schema's individual 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 three specific modes of retirement calculation (corpus_needed, monthly_contribution_for, safe_withdrawal) with example queries. It distinguishes from sibling financial calculators by focusing exclusively on retirement planning.
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 explicit context for when to use each mode and gives example queries. However, it lacks direct guidance on when not to use this tool versus alternatives like calculate_sip_dca or calculate_compound_interest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate ZATCA-collected Zakat for Saudi / GCC nationals (simplified 2.5% estimator). Caller supplies the pre-computed zakat base. Returns zakat due with a disclaimer that actual ZATCA computation requires full financial statements. Example query: 'estimate Saudi corporate zakat on SAR 1M zakat base'.
| Name | Required | Description | Default |
|---|---|---|---|
| zakat_base | Yes | Caller-computed zakat-eligible base amount in SAR (adjusted equity per ZATCA). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently explains that this is a simplified estimator and returns a zakat due with a disclaimer. It does not mention side effects or authorization needs, but as a read-only calculation tool, this is acceptable. Slightly more detail on the calculation's non-authoritative nature would enhance 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 extremely concise: two sentences and an example query. Every sentence adds value—first sets context, second explains input and output behavior, third gives a concrete usage example. No redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculator with one parameter and no output schema, the description adequately covers purpose, input, and output (zakat due with disclaimer). However, it does not specify the exact return format (e.g., number, string with disclaimer). Adding a note on output structure would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter, including a clear description ('adjusted equity per ZATCA'). The tool description adds an example and reiterates 'pre-computed zakat base', but does not provide substantial new semantics beyond the schema. Hence, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool estimates Zakat for Saudi/GCC nationals using a simplified 2.5% rate, distinguishing it from more general zakat calculators (e.g., calculate_zakat sibling). The verb 'estimate' and specific resource 'ZATCA-collected Zakat' make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the caller must supply a pre-computed zakat base and includes a disclaimer that actual ZATCA computation requires full financial statements, setting expectations for when to use the tool (simple estimates) and when not (official filings). It could be improved by explicitly mentioning the sibling calculate_zakat as an alternative for non-Saudi/GCC cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the future value of periodic contributions (SIP in India, DCA globally). Supports annual step-up of monthly contributions. Example queries: 'SIP ₹5000/month for 15 years at 12%', 'how much SIP to reach 1 crore in 10 years', 'DCA $500/month into index fund for 30 years', 'step-up SIP with 10% annual increase'.
| Name | Required | Description | Default |
|---|---|---|---|
| monthly_amount | Yes | Fixed monthly contribution. | |
| annual_return | Yes | Decimal expected annual return, e.g. 0.12 for 12%. | |
| years | Yes | Investment horizon in years. | |
| step_up_percent | No | Annual % increase in monthly contribution. E.g. 10.0 = 10% step-up each year. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the computation and step-up feature, but with no annotations, it could be more explicit about being a read-only calculation. However, it is sufficiently transparent for a calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and example queries, front-loading the purpose and using efficient wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs and usage well, but lacks explanation of the return value format. Given no output schema, it is slightly incomplete but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by explaining SIP/DCA concepts and step-up, going beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes future value of periodic contributions (SIP/DCA) and provides example queries, making the purpose specific and distinguishable from sibling calculator tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via examples but does not explicitly provide when-to-use or when-not-to-use guidelines relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse US retirement account contributions for 2026. account_type='traditional_401k': employee deferral, employer match, §415 cap, tax savings. account_type='roth_ira': eligibility check and MAGI phase-out calculation. Example queries: 'how much do I save in taxes with 401k contribution', 'am I eligible for Roth IRA at $155k income'.
| Name | Required | Description | Default |
|---|---|---|---|
| account_type | Yes | Retirement account type. | |
| contribution | Yes | Desired annual contribution amount in USD. | |
| age | Yes | Employee/contributor age (determines catch-up limits for 50+). | |
| salary | No | [traditional_401k] Annual gross salary in USD. | |
| employer_match_percent | No | [traditional_401k] Employer match fraction, e.g. 0.50 = 50-cent per dollar. | |
| employer_match_cap | No | [traditional_401k] Match applies up to this % of salary, e.g. 0.06 = 6%. | |
| marginal_tax_rate | No | [traditional_401k] Marginal federal rate for tax savings estimate. | |
| magi | No | [roth_ira] Modified Adjusted Gross Income for phase-out check. | |
| filing_status | No | [roth_ira] Filing status for MAGI phase-out range. | single |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions what calculations are performed (e.g., employer match, tax savings) but does not address side effects, authenticity (e.g., data persistence), rate limits, or error handling. The tool is likely read-only, but this is not explicit.
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 (two sentences plus example queries) and well-structured: purpose first, then account-type details, then concrete examples. Every sentence adds value with 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?
Given no output schema, the description sufficiently explains what the tool does for both account types and includes example queries. It covers the key differentials (MAGI phase-out, 401k limits). It could be more complete by mentioning output format or limitations (e.g., 2026 limits only), but it is adequate 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?
The input schema has 100% coverage with descriptions for all 9 parameters. The description adds value by clarifying which parameters apply to which account type (e.g., salary and employer_match for traditional_401k; magi and filing_status for roth_ira) and providing usage examples. This goes beyond the schema's basic 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?
Description clearly states the tool analyzes US retirement account contributions for 2026, specifying two account types (traditional_401k, roth_ira) and associated calculations. Example queries further clarify purpose. However, the verb 'analyse' is slightly less precise than 'calculate', and the tool could be confused with generic retirement calculators if not for the sibling differentiation.
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 example queries that imply when to use the tool (e.g., tax savings, Roth IRA eligibility). However, it does not explicitly state when not to use it or mention alternatives among sibling tools (e.g., calculate_retirement, calculate_income_tax). Usage context is implied but not fully bounded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate VAT for UAE (5%) or Saudi Arabia (15%). Works for both ex-VAT and VAT-inclusive amounts. Example queries: 'UAE VAT on AED 1000 product', 'what is the VAT-exclusive price of SAR 1150 including 15% VAT'.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | 'ae' = UAE 5% VAT, 'sa' = Saudi Arabia 15% VAT. | |
| amount | Yes | Monetary amount in local currency (AED for UAE, SAR for KSA). | |
| is_inclusive | No | True if amount already includes VAT (to extract it). False if amount is ex-VAT. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the two VAT rates and the inclusive/exclusive logic. No contradictory statements. Could mention output format but not required.
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 concise sentences plus two example queries. No redundant information, front-loaded with purpose.
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?
Lacks description of output format (e.g., returns VAT amount or object with breakdown). With no output schema, agent might not know what to expect. Otherwise, sufficient for a simple 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 covers all parameters (100%). Description adds value by stating the exact VAT percentages (5% for ae, 15% for sa) and explaining is_inclusive flag with examples, exceeding schema details.
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 calculates VAT for UAE (5%) or Saudi Arabia (15%), distinguishing it from sibling tools like calculate_income_tax or calculate_zakat. It specifies verb 'Calculate' and resource 'VAT' with country context.
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 it works for ex-VAT and VAT-inclusive amounts, and provides example queries. However, it does not explicitly mention when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute Zakat al-Mal (annual 2.5% Islamic wealth obligation). Sums all zakatable assets, deducts debts, checks nisab threshold (gold or silver basis), and returns the zakat due. Cross-cutting — any Muslim, any country. Example queries: 'how much Zakat do I owe on $25000 savings and $5000 stocks', 'zakat calculation with gold and silver holdings'.
| Name | Required | Description | Default |
|---|---|---|---|
| cash | No | Cash + bank balances. | |
| gold_grams | No | Gold owned in grams. | |
| silver_grams | No | Silver owned in grams. | |
| stocks_value | No | Market value of zakatable equity holdings. | |
| business_assets | No | Business inventory + receivables. | |
| other_zakatable_assets | No | Other qualifying assets. | |
| debts | No | Outstanding debts owed (deducted from wealth). | |
| gold_price_per_gram | No | Current gold price per gram in the chosen currency. | |
| silver_price_per_gram | No | Current silver price per gram. | |
| nisab_basis | No | 'silver' (lower, more inclusive) or 'gold'. | silver |
| currency | No | ISO-4217 currency code for display. | USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It outlines the steps (sums assets, deducts debts, checks nisab threshold) but does not detail exact calculation logic (e.g., how nisab threshold is applied). 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?
Four sentences: purpose, steps, applicability, examples. Front-loaded with clear verb 'Compute'. 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 the complexity (11 parameters, no output schema, no annotations), description provides overview and examples but lacks details on output format (e.g., what fields are returned). It mentions 'returns the zakat due' without further 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 coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond schema—only mentions asset summing and debt deduction. Parameter behavior is already well-documented in 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 the tool computes Zakat al-Mal (2.5% annual obligation) and distinguishes itself from siblings like 'calculate_saudi_zakat_citizen' by specifying cross-cutting applicability for any Muslim, any country.
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 context with 'Cross-cutting — any Muslim, any country' and example queries, but does not explicitly state when not to use this tool versus alternatives like 'calculate_saudi_zakat_citizen'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an amount between any two currencies using a caller-supplied USD-based rate dict. The caller must provide current exchange rates (USD=1.0 base). Example: convert 1000 USD to INR with rates={'USD':1.0, 'INR':83.5}.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to convert. | |
| from_currency | Yes | ISO-4217 source currency code, e.g. 'USD'. | |
| to_currency | Yes | ISO-4217 target currency code, e.g. 'INR'. | |
| rates | Yes | Dict mapping currency codes to units-per-USD, e.g. {'USD':1.0,'INR':83.5,'EUR':0.93}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that rates must be caller-supplied and USD-based, and provides example format. No annotations exist, so description carries full burden; it covers key behavioral traits but omits error handling 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?
Two sentences plus example, front-loaded, 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?
No output schema; description omits return format and error conditions (e.g., missing currency in rates). Adequate for a simple conversion but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds meaning beyond schema: explains rate dict structure (units-per-USD), provides example, and clarifies that amount is in source currency.
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 verb (convert), resource (amount between currencies), and mechanism (caller-supplied USD-based rates). Distinguishes from siblings as no other sibling performs currency conversion.
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 requires caller to provide rates and gives example. No alternative tool for this function among siblings, so context is clear, but 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.
Format a numeric amount as a human-readable currency string. For INR, optionally use Indian lakh/crore notation (₹15.00 L, ₹2.50 Cr). Example queries: 'format 83500 in INR', 'display 25000000 as crores'.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Numeric amount to format. | |
| currency | Yes | ISO-4217 currency code (e.g. USD, INR, GBP, AED). | |
| lakh_crore_format | No | For INR only: use lakh/crore notation (₹15.00 L / ₹2.50 Cr). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states basic functionality and examples but lacks disclosure of rounding behavior, locale handling, or any limitations. This minimal disclosure does not sufficiently inform an agent about edge cases or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and includes illustrative examples. Every sentence is necessary and there is no 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 formatting tool with three parameters and no output schema, the description is largely complete. It covers the special INR formatting option and gives usage examples. However, it could mention the output format (e.g., decimal places, currency symbol) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description adds value by explaining the lakh_crore_format parameter with examples, enhancing understanding beyond the schema's brief definitions.
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 'Format' and the resource 'numeric amount as a human-readable currency string', with specific examples for INR. It is distinct from sibling tools which are calculators or conversion functions.
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 with example queries and mentions optional lakh/crore notation for INR. However, it does not explicitly state when not to use this tool or name alternatives, though the sibling list is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a stock for Sharia compliance using AAOIFI standard financial ratios. Checks: business sector (haram/halal), debt ratio, cash ratio, receivables ratio, haram revenue ratio. Returns compliance verdict, failed checks, and purification ratio. Example queries: 'is this tech stock halal?', 'AAOIFI screen for Apple with these financials'.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes | Business sector/activity description (e.g. 'technology', 'banking', 'alcohol'). | |
| market_cap | Yes | Total market capitalisation. | |
| debt_interest_bearing | Yes | Total interest-bearing debt on the balance sheet. | |
| cash_and_interest_securities | Yes | Cash + conventional bonds/interest-bearing securities held. | |
| receivables | Yes | Total accounts receivable. | |
| total_revenue | Yes | Total annual revenue. | |
| haram_revenue | No | Revenue from non-compliant activities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the checks and outputs (verdict, failed checks, purification ratio) but does not disclose any side effects, permissions, or data persistence. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, includes a list of checks and example queries. Every sentence adds value with 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?
Given no output schema, the description usefully mentions the return format (compliance verdict, failed checks, purification ratio). It covers the key aspects needed for an AI agent to use the tool, though more detail on edge cases or assumptions could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter well-described. The tool description adds context by linking parameters to AAOIFI ratios, but it does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Screen' with a clear resource 'stock for Sharia compliance using AAOIFI standard financial ratios'. It lists specific checks and outputs, distinguishing it from sibling tools like calculate_bmi_bmr_tdee or convert_currency.
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 and example queries, effectively signaling when to use the tool (for halal screening). However, it does not explicitly state when not to use it or mention alternatives, which is acceptable given the lack of similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are generally distinct, but there is potential overlap between 'calculate_retirement' and 'calculate_sip_dca' (both deal with savings targets) and between the two zakat tools. However, descriptions clarify these differences well.
All tools follow a consistent verb_noun pattern using snake_case (e.g., calculate_bmi_bmr_tdee, convert_currency, screen_halal_stock). No mixed conventions or irregular naming.
With 17 tools, the server covers a broad but focused range of financial and Islamic calculations. The count is slightly heavy but still appropriate given the breadth of the domain.
The tool set covers key financial calculations (tax, loans, retirements, zakat, etc.) with minor gaps like missing investment portfolio tools or exchange rate fetching. Overall, it is sufficiently complete for its calculator purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
90+ pure finance calculators: loans, investing, bonds, options, tax. Stateless, stores nothing.
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
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
Deterministic Canadian mortgage calculations for qualification, debt service, LTV, and penalties.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Declan142/calcnook-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
