finance-calc-mcp

by FellowTraveler

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
Most tools target distinct financial calculations, but gross_margin and percent_change both compute margin/markup, creating ambiguity. The general calculate tool also overlaps with simple computations, though it's clearly a catch-all.
Naming Consistency2/5
Tool names follow no consistent verb_noun pattern; some are nouns (depreciation, loan_amortization), some are verb phrases (calculate), and some are compound terms (us_income_tax_estimate). While all use snake_case, the structural inconsistency makes it harder to predict tool names.
Tool Count5/5
10 tools is well-scoped for a finance calculator, covering a broad range of common financial calculations without excessive redundancy. Each tool has a clear domain purpose.
Completeness4/5
The toolset covers profitability, tax, depreciation, payroll, loans, break-even, percentage changes, and formatting. Minor gaps like NPV/IRR or compound interest exist, but core financial analysis needs are well covered.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent behavior, so the description does not need to restate those. However, it introduces ambiguity by listing three possible calculations (percent change, markup, margin) without explaining how the tool decides which to compute or what output format to expect. This is a significant behavioral gap not covered by annotations.
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 a single, well-structured sentence that immediately states the tool's purpose without any filler. It is front-loaded and concise, earning a perfect score for this dimension.
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?
While the tool is simple and parameters are well-documented, the lack of output schema and the ambiguous listing of three separate metrics make the description incomplete. It would be more helpful to specify what the function returns (e.g., the percentage value) and any conventions like sign handling. Given the annotations and schema, a score of 3 reflects a minimally viable but not enriched description.
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 'old_value' and 'new_value' clearly described as starting/original and ending/new values. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
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 specifies a calculation verb ('calculate') and the resource ('percent change, markup, or margin') between two values. It conveys a distinct purpose, though it could more strongly distinguish itself from sibling tools like 'gross_margin' by noting that all three metrics are returned or selectable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'gross_margin' or 'calculate'. It does not state any exclusions, prerequisites, or typical use cases, leaving the agent without context for tool selection.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not expected to re-state safety. It adds useful context by specifying the tax year (2024) and that it applies to individuals, but it does not describe the output format or calculation assumptions.
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 short sentences, front-loaded with the core action. Every word contributes to understanding the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should mention what the tool returns, but it does not. It also lacks details on whether the estimate includes standard deductions or credits. However, the tool is simple and the purpose is clear, so it's not completely inadequate.
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?
Both parameters are fully described in the input schema (taxable_income and filing_status with allowed values). The description adds no additional parameter semantics; it merely lists filing statuses in the prose, which duplicates the 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?
The description clearly states 'Estimate 2024 US federal income tax (individuals)' with a specific verb ('estimate') and resource ('2024 US federal income tax'), and lists filing statuses. It distinguishes from sibling self_employment_tax by specifying 'individuals' and the type of tax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like self_employment_tax or other financial calculations. The description only mentions filing statuses, which are parameters, not usage scenarios.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it produces a summary with specific outputs, but does not disclose additional behavioral traits beyond what annotations cover. No contradictions with annotations.
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 a single efficient sentence that front-loads the purpose and the outputs. Every word earns its place, and there is no unnecessary detail.
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 lists the key return values (monthly payment, total interest, full schedule), which is sufficient given the absence of an output schema. It is reasonably complete for a simple calculator, though it does not explicitly mention the optional schedule toggle, but the schema covers that.
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%, so the schema fully documents all four parameters. The description adds no additional parameter semantics beyond the schema, such as units or formatting; it only lists the outputs that the tool will generate.
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 that the tool generates a loan amortization summary, listing specific outputs (monthly payment, total interest, full schedule). This is a specific verb+resource and distinguishes it from sibling financial calculation tools, though it does not explicitly contrast with alternatives.
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 the tool is used for loan amortization calculations by listing the expected outputs, but it gives no explicit guidance on when to choose this over sibling tools or mention prerequisites. Usage is implied rather than explicitly stated.
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?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds that it supports straight-line or MACRS-style methods, but does not disclose return format, schedule granularity, or edge cases like partial-year handling. This is acceptable given the annotations, but no extra behavioral context is provided beyond method selection.
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 a single, front-loaded sentence that states exactly what the tool does. Every word contributes to understanding the tool's purpose, with no redundant phrases or filler.
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?
The tool has no output schema, so the description should at least hint at the return format. It says 'schedule' which implies a series of values, but does not clarify whether it returns annual amounts, cumulative amounts, or a table. Given the small parameter set and annotations, the description is adequate but leaves some ambiguity about the output shape.
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%, so all parameters are already documented. The description adds no new parameter semantics, though it does echo the method choices ('straight-line or MACRS-style') which align with the schema's method values. The term 'MACRS-style' is not an exact match for 'double_declining', but it does hint at the intended method semantics.
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 a depreciation schedule, naming two methods (straight-line and MACRS-style). This distinguishes it from sibling financial tools like tax estimators and loan amortization, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for depreciation calculations but does not explicitly state when to choose this tool over alternatives such as loan_amortization or break_even. There is no mention of exclusions or conditions, leaving usage guidance to inference from the tool name.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the 'or other locale' claim but provides no mechanism to select a locale, which is slightly ambiguous. No contradiction with annotations, but the behavioral disclosure beyond annotations is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any extraneous words. It is appropriately concise.
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?
The tool is simple, but the description lacks detail on output format specifics (e.g., rounding, grouping) and does not clarify how the 'other locale' is specified, especially since there is no locale parameter. Without an output schema, more behavioral detail would be beneficial, though the basic function is clear.
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%: both 'amount' and 'decimals' have descriptions. The description does not add any information beyond the schema, so the baseline of 3 applies.
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 'Format a number as USD currency string (or other locale)' clearly states a specific verb (format) and resource (number to currency string). It differentiates from sibling financial calculation tools like gross_margin and loan_amortization, making its 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 implies the tool is used when a number needs to be formatted as currency, which is clear context. However, it does not explicitly state when not to use it or name alternatives, though the sibling tools are all calculations, so the distinction is implicit.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful information that the tool calculates both the SE tax and the deductible half, which clarifies output semantics. No contradictions found.
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 a single, front-loaded sentence with no redundant words. It fully defines the tool's purpose in under 10 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?
The tool is simple with one input and no output schema, but the description only partially reveals the return structure (tax and deductible half). It does not specify exact field names or any limitations, such as tax year or wage base assumptions, which could be important for an agent.
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 has 100% coverage with one parameter 'net_self_employment_income' described as 'Net profit from self-employment'. The description does not add additional detail beyond the schema, so the 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 a specific verb ('Calculate') and resource ('self-employment tax and deductible half for Schedule SE'). It distinguishes itself from sibling tools like us_income_tax_estimate by explicitly targeting SE tax and Schedule SE.
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?
Usage context is implied: use when you need SE tax calculation. However, there is no explicit mention of when not to use it or alternative tools, such as us_income_tax_estimate, so guidance is not fully explicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond stating it calculates, which is consistent with the annotations. It does not mention edge cases or output details, but the safety profile is already covered by annotations.
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 a single clear sentence that front-loads the primary action and lists inputs efficiently. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculation tool with no output schema, the description sufficiently explains what the tool computes and the required inputs. The output (break-even units and revenue) is implied by the description, making it complete for typical use.
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%, so each parameter is already documented. The description restates the parameters without adding new semantics like units or constraints. It meets the baseline for high schema coverage.
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 function: calculate break-even units and revenue, with specific inputs (fixed costs, price per unit, variable cost per unit). This distinguishes it from sibling tools like gross_margin or percent_change.
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 clearly indicates the context for use: break-even analysis given cost and price inputs. It does not explicitly exclude alternatives, but the input requirements make the usage scenario unambiguous.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the output set (gross margin, profit, markup), but this overlaps with purpose and provides no additional behavioral details like edge-case handling or return format.
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?
A single sentence that is front-loaded with the action and lists the key outputs and inputs. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter calculation with full schema coverage and safety annotations, the description is complete. It names all three outputs upfront and requires no additional detail to understand what the tool does.
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% (both revenue and cogs have descriptions). The description only restates the source parameters without adding clarity on units, valid ranges, or relationships, so it adds no meaningful value beyond the 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?
The description uses the specific verb 'Calculate' and names the exact resources (gross margin, gross profit, markup) and inputs (revenue, COGS). It clearly distinguishes from sibling financial calculators like percent_change or break_even by stating its unique outputs.
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: use this tool when you need gross margin, gross profit, or markup from revenue and COGS. It does not explicitly mention alternatives or exclusions, but the specificity makes the intended use obvious without ambiguity.
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?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context about which tax components are included, which is beyond the annotations. It also states it provides estimates, setting expectations about precision. No contradiction.
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, front-loaded with the core purpose, followed by a scoped list of covered taxes. Every word earns its place with no redundancy or filler.
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 adequately conveys what the tool computes for a simple calculator. It lists the covered tax components and implies the output (employer costs and net pay). Since there is no output schema, a bit more detail about the exact return fields could help, but it is sufficient given the simplicity.
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%: both parameters have descriptions. The description adds minimal meaning beyond the schema, just identifying gross salary as the basis. It does not elaborate on state_suta_rate beyond what's in the schema, so 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 clearly states the tool estimates employer payroll costs and employee net pay from gross salary, and enumerates the specific taxes covered (FICA, FUTA, SUTA). This distinguishes it from sibling tools like us_income_tax_estimate and self_employment_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?
The scope is clear: it's for employer-side payroll cost estimation and employee net pay. It implies usage for payroll-related calculations, and by listing covered taxes it suggests when it applies. However, it does not explicitly mention alternatives or exclusions (e.g., 'not for income tax').
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, non-mutating profile. The description adds valuable behavioral context by specifying the supported operators, functions, and example expressions, which goes beyond what annotations convey.
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, front-loaded with the primary purpose. The first sentence states the action and scope; the second compactly lists supported syntax and gives three illustrative examples. No unnecessary words or repetition.
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 single-parameter tool with no output schema, the description covers the input format thoroughly. It implicitly communicates that the result is numeric through examples. It does not explicitly state the return type or error behavior, but given the tool's simplicity and annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description significantly enriches the single parameter by detailing the expression grammar, listing functions and operators, and providing concrete examples. This turns the vague 'Math expression to evaluate' into a well-specified input format.
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 opens with a specific verb+resource: 'Evaluate a financial/business math expression.' It clearly states the tool's function and distinguishes it from sibling specialized calculators by positioning it as the generic math evaluator. Supported operators and functions further clarify intended use.
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 use for general financial/business math but does not explicitly state when to use this tool versus alternatives like gross_margin or us_income_tax_estimate. No exclusions or alternative references are provided, leaving the decision to the agent's inference.
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:

[![finance-calc-mcp MCP server](https://glama.ai/mcp/servers/FellowTraveler/finance-calc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/FellowTraveler/finance-calc-mcp)

Score Badge

Copy to your README.md:

[![finance-calc-mcp MCP server](https://glama.ai/mcp/servers/FellowTraveler/finance-calc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/FellowTraveler/finance-calc-mcp)

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/FellowTraveler/finance-calc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server