calcnook

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness4/5
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.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![calcnook-mcp-server MCP server](https://glama.ai/mcp/servers/Declan142/calcnook-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Declan142/calcnook-mcp-server)

Score Badge

Copy to your README.md:

[![calcnook-mcp-server MCP server](https://glama.ai/mcp/servers/Declan142/calcnook-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Declan142/calcnook-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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