axiom-calculator-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct financial calculation purpose with no overlap: compound interest, debt payoff, FIRE number, inflation-adjusted return, loan comparison, mortgage, rent vs. buy, and credit cost. The descriptions specify unique use cases, making misselection unlikely.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern with descriptive terms (e.g., compound_interest, debt_payoff_plan). However, there is a minor deviation with 'true_credit_cost' using 'true' as a modifier, while others like 'inflation_adjusted_return' use adjectives differently, slightly affecting uniformity.
Tool Count5/5
With 8 tools, the server is well-scoped for a financial calculator domain. Each tool addresses a specific, common financial scenario, and the count is neither too sparse nor bloated, fitting typical user needs effectively.
Completeness5/5
The tool set comprehensively covers key personal finance calculations: investment growth, debt management, retirement planning, inflation, loan analysis, mortgages, housing decisions, and credit costs. There are no obvious gaps, providing full lifecycle coverage for financial decision-making.
Average 4.2/5 across 8 of 8 tools scored.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe calculation tool. The description adds useful context about what the tool shows ('difference between nominal growth and actual purchasing power growth'), but doesn't provide additional behavioral details like computational limits, rounding behavior, or error conditions.
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 perfectly concise with three focused sentences that each earn their place: the core function, what it shows, and when to use it. It's front-loaded with the primary purpose and wastes no words.
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 presence of both annotations (readOnlyHint) and an output schema, the description provides adequate context for this calculation tool. It explains the purpose and value proposition well, though it could benefit from mentioning the formula or mathematical approach used.
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?
With 100% schema description coverage, the input schema already fully documents all parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value.
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 specific action ('calculate the real return') and resource ('investment'), with explicit differentiation from nominal growth. It distinguishes this tool from siblings by focusing on inflation adjustment rather than basic compound interest or other financial calculations.
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 about when to use this tool ('useful for understanding if your investments are truly beating inflation'), which implicitly suggests alternatives like nominal return calculations. However, it doesn't explicitly name when not to use it or mention specific sibling tools as alternatives.
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?
The annotations already declare readOnlyHint=true, so the agent knows this is a calculation-only tool with no side effects. The description adds useful behavioral context about what the tool compares (base vs. extra payments) and what outputs to expect (months and dollars saved), but doesn't provide additional behavioral details like calculation methodology, assumptions, or limitations.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second sentence adds valuable comparative context. No wasted words, and the information is front-loaded effectively.
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?
Given that this tool has complete schema descriptions (100% coverage), readOnlyHint annotation, and an output schema (implied by context signals), the description provides exactly what's needed. It explains the tool's purpose and comparative nature without needing to repeat parameter details or output format information that's already available in structured fields.
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?
With 100% schema description coverage, all parameters are already well-documented in the input schema. The description adds minimal additional semantic context by mentioning 'base payment plan vs adding extra monthly payments' which relates to the extra_monthly parameter, but doesn't provide significant value beyond what's in the structured 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 the tool's purpose with specific verbs ('calculate', 'compares') and resources ('debt', 'payment plan', 'interest'). It distinguishes from siblings by focusing specifically on debt payoff calculations rather than general interest calculations (compound_interest), loan comparisons (loan_comparison), or other financial 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 provides clear context about when to use this tool: for calculating debt payoff timelines and interest costs, comparing base vs. accelerated payment plans. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools (like when to choose loan_comparison instead).
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?
The annotations already declare readOnlyHint=true, indicating this is a calculation tool without side effects. The description adds useful context about what the tool calculates (portfolio size and timeline) and mentions the classic 'Rule of 4%', but doesn't provide additional behavioral details like error conditions, performance characteristics, or data persistence. No contradiction with annotations exists.
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 perfectly concise with just two sentences that efficiently explain both primary functions: calculating the FIRE number and estimating the timeline. Every word earns its place, and the information is front-loaded with no unnecessary elaboration.
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?
Given the tool's purpose as a financial calculator with read-only behavior (annotations), comprehensive parameter documentation (100% schema coverage), and the existence of an output schema, the description provides complete context. It clearly explains what the tool does without needing to detail return values or behavioral nuances that are covered elsewhere.
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?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description mentions the core parameters (expenses, withdrawal rate, savings) but doesn't add significant semantic information beyond what's already in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 the FIRE number (portfolio size needed) and timeline (years to reach FIRE). It specifies the verb 'calculate' and resource 'FIRE number and timeline', distinguishing it from sibling tools like compound_interest or mortgage_calculator which handle different financial calculations.
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 for when to use this tool: for calculating financial independence metrics based on expenses, withdrawal rates, and savings. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, though the different tool names imply different use cases.
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, so the agent knows this is a safe calculation tool. The description adds useful context about what gets returned (monthly payment, total interest, amortization summary, break-even analysis) and optional property tax/insurance inclusion, which goes beyond the annotations. However, it doesn't mention computational limits, precision, or error handling.
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 perfectly structured with two focused paragraphs: first states core purpose and outputs, second adds optional feature. Every sentence adds value with zero wasted words, and key information is front-loaded.
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?
Given this is a read-only calculation tool with excellent annotations, 100% schema coverage, and an output schema exists, the description provides complete context. It clearly explains what the tool does, what it returns, and includes the optional tax/insurance feature - nothing essential is missing for agent understanding.
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?
With 100% schema description coverage, the input schema already fully documents all parameters. The description mentions 'optionally includes property tax and insurance' which aligns with the monthly_extras parameter, but adds minimal additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 mortgage payments and related financial metrics with specific outputs listed. It distinguishes from sibling tools like 'compound_interest' and 'loan_comparison' by focusing specifically on mortgage amortization calculations.
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 for when to use this tool (calculating mortgage payments, interest, amortization) but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The context is sufficient but lacks explicit exclusion guidance.
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 adds valuable behavioral context beyond the readOnlyHint annotation by specifying what the tool outputs ('final value, total contributions, total interest earned, and a year-by-year growth table') and mentioning the 'standard compound interest formula with optional periodic contributions'. This provides useful information about the tool's behavior that isn't captured in the annotation alone.
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 perfectly structured with two concise paragraphs. The first sentence immediately states the core purpose, and subsequent sentences efficiently elaborate on outputs and methodology. Every sentence earns its place with no 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?
Given the tool's moderate complexity, 100% schema description coverage, readOnlyHint annotation, and the existence of an output schema, the description is complete enough. It explains what the tool does, what it outputs, and the methodology used, which is sufficient when combined with the well-documented structured fields.
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?
With 100% schema description coverage, the input schema already provides comprehensive parameter documentation. The description adds minimal semantic value beyond what's in the schema - it mentions 'optional regular contributions' which relates to the monthly_contribution parameter, but doesn't provide additional context about parameter interactions or usage patterns.
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 with specific verbs ('project investment growth', 'shows final value') and resources (compound interest calculations). It distinguishes from sibling tools like 'debt_payoff_plan' and 'mortgage_calculator' by focusing specifically on investment growth projection rather than debt or loan scenarios.
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 for when to use this tool ('project investment growth with compound interest and optional regular contributions'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. The context is sufficient to understand this is for investment growth projection rather than debt or loan 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?
The annotation 'readOnlyHint: true' already indicates this is a safe read operation with no side effects. The description adds useful context about what the tool calculates (total cost, monthly payment, true APR) and the decision-making scenarios, but doesn't disclose additional behavioral traits like computational complexity, error handling, or output format details. With annotations covering the safety profile, a 3 is appropriate as the description adds some value beyond 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 perfectly concise and well-structured. Two sentences total: the first states the core purpose and metrics, the second provides usage scenarios. Every word earns its place with zero redundancy. It's front-loaded with the most important information (what the tool does) followed by context (when to use it).
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?
Given the tool's complexity (7 parameters, financial calculations), the description provides complete context. It explains what the tool compares and when to use it. With annotations covering safety (readOnlyHint: true), 100% schema coverage documenting all parameters, and an output schema existing (though not shown), the description doesn't need to explain return values or parameter details. It focuses appropriately on the tool's purpose and usage scenarios.
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 all 7 parameters well-documented in the schema (e.g., 'Amount to borrow', 'Annual interest rate for option A (%)'). The description doesn't add any parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'Compare two loan options by total cost, monthly payment, and true APR.' It specifies the verb ('compare'), resource ('two loan options'), and key comparison metrics. It also distinguishes from siblings like 'mortgage_calculator' (single loan) and 'debt_payoff_plan' (repayment strategy) by focusing on comparative analysis between two options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Helps decide between a lower rate with higher fees vs higher rate with lower fees, or shorter term (higher payment, less interest) vs longer term (lower payment, more interest).' This gives clear scenarios for when to use the tool, including trade-off decisions. It implicitly distinguishes from siblings like 'compound_interest' (growth) and 'rent_vs_buy' (housing decision).
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 provide readOnlyHint=true, but the description adds valuable behavioral context beyond this: it specifies what financial factors are accounted for (mortgage payments, equity, opportunity cost, rent increases, home appreciation) and describes the return format ('which option is cheaper and by how much'), which isn't covered by annotations alone.
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 efficiently structured in two sentences: the first states the purpose and scope, the second details the analysis factors and return value. Every sentence adds essential information with zero waste.
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?
Given the tool's complexity, 100% schema coverage, annotations indicating read-only operation, and the presence of an output schema, the description provides complete context: it explains the tool's purpose, factors considered, and return format, making it fully adequate for agent understanding.
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?
With 100% schema description coverage, the input schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating for any gaps.
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 with specific verbs ('compare total cost') and resources ('renting vs buying'), and it distinguishes from siblings by focusing on comprehensive financial comparison rather than simple calculations like mortgage_calculator or 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?
The description implies usage context ('over a given number of years', 'analysis period') and mentions specific factors considered, but doesn't explicitly state when to use this tool versus alternatives like mortgage_calculator or loan_comparison, nor does it provide exclusion criteria.
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 indicate readOnlyHint=true, confirming this is a safe read operation. The description adds valuable context beyond annotations by stating the tool 'Cuts through misleading '0% financing' or low-rate marketing to show actual cost,' which clarifies its analytical purpose and behavioral intent. It does not contradict annotations, as 'find' aligns with read-only behavior.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose. Subsequent sentences efficiently elaborate on scope and value without redundancy. Every sentence adds value, such as listing product types and highlighting the tool's ability to reveal hidden costs, making it concise and well-structured.
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?
Given the tool's complexity (financial calculation with 5 parameters), the description is complete enough. It clearly defines the tool's purpose, usage context, and behavioral insight. With annotations covering safety (readOnlyHint=true), 100% schema description coverage, and an output schema present (which handles return values), no additional details are needed in the description for effective 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%, meaning all parameters are well-documented in the schema itself. The description does not add specific meaning or examples for parameters beyond what the schema provides, such as explaining how 'annual_late_fee' impacts calculations. With high schema coverage, the baseline score of 3 is appropriate, as the description relies on the schema for parameter 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 the tool's purpose: 'Find the true total cost and implied APR of any credit product.' It specifies the verb ('find') and resource ('true total cost and implied APR'), and distinguishes itself from siblings by focusing on revealing actual costs through specific examples (car financing, BNPL, etc.), unlike tools like 'compound_interest' or 'loan_comparison'.
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 for when to use this tool: 'Works for car financing, buy-now-pay-later, credit card minimum payments, personal loans, and any fixed payment schedule.' It implies usage by listing applicable scenarios but does not explicitly state when not to use it or name alternatives among siblings, such as 'loan_comparison' for comparing loans directly.
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:

[![axiom-calculator-mcp MCP server](https://glama.ai/mcp/servers/vdalhambra/axiom-calculator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vdalhambra/axiom-calculator-mcp)

Score Badge

Copy to your README.md:

[![axiom-calculator-mcp MCP server](https://glama.ai/mcp/servers/vdalhambra/axiom-calculator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vdalhambra/axiom-calculator-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/vdalhambra/axiom-calculator-mcp'

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