Calculator MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
There is significant overlap between evaluate_math_expression, perform_arithmetic, and scientific_calculation. An agent could compute the same result via multiple tools (e.g., sqrt via expression or scientific_calculation), making tool selection ambiguous. The boundaries between expression evaluation, basic arithmetic, and scientific operations are not clearly defined.
Naming Consistency2/5
Naming is inconsistent: some tools follow verb_noun (evaluate_math_expression, perform_arithmetic, convert_unit, calculate_statistics) while others are adjective_noun (scientific_calculation, financial_calculator). This mixed convention breaks predictability and could cause confusion about the tool's primary action.
Tool Count5/5
With 6 tools covering math expressions, arithmetic, scientific operations, unit conversion, finance, and statistics, the count is well-scoped for a comprehensive calculator server. Each tool addresses a distinct domain, and the number is neither too thin nor bloated.
Completeness4/5
The tool set covers a broad range of calculation needs, from basic arithmetic to scientific, financial, and statistical operations. Minor gaps exist (e.g., no modulus, percentile, or matrix support), but for a general-purpose calculator the surface is largely complete and usable.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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, idempotentHint, and destructiveHint false, establishing the operation is safe and non-mutating. The description adds that numbers are processed 'in sequence', but it doesn't specify how operations like subtraction or division apply across the sequence (e.g., left-to-right accumulation). The description adds modest behavioral context beyond the annotations but is not exhaustive.
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 the core action in the first sentence. The Args block repeats some information from the schema but is compact and does not add unnecessary clutter. It is well-structured and efficient.
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?
An output schema is present, so return format is likely covered. However, the description is incomplete regarding the semantics of sequence-dependent operations (subtraction, division). It doesn't clarify the order of operations or whether the first number serves as the initial value, which is critical for correct usage. This ambiguity reduces 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?
The schema has zero description coverage, so the description must carry parameter meaning. It lists the four operation values and states numbers is a list, but it doesn't define how operations are applied (e.g., whether the first number is the base for subtract/divide). The phrase 'in sequence' gives a hint but remains vague, leaving room for misinterpretation.
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 performs basic arithmetic operations (add, subtract, multiply, divide) on a list of numbers. The name and description align, and the phrase 'basic arithmetic' differentiates it from scientific or statistical siblings. However, it doesn't explicitly contrast with evaluate_math_expression, which may also handle basic operations, so it's not fully distinguishing.
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 provides no guidance on when to use this tool versus siblings like evaluate_math_expression or scientific_calculation. It only describes what it does, without any exclusions or alternative suggestions, leaving the agent to infer suitability.
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, so the safety profile is covered. The description adds context about parameter formats (e.g., rate in percent, compounding_frequency options) but does not disclose behavior like validation, edge cases, or what happens with invalid calc_type. It does not contradict annotations, so a 3 is appropriate.
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 structured as a docstring with a clear list of parameters, each with concise definitions. It is moderately sized and front-loaded with the tool's purpose before diving into args. No wasted sentences, though the parameter list could be tightened by clarifying 'amount' without adding length.
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 an output schema (not shown) but the description does not explain the return format or how results vary by calc_type. It also does not specify which parameters are required for each calculation mode, leaving an agent to infer that principal/rate/time are needed for interest and EMI, while percentage may need amount. This is a meaningful gap for a multi-mode calculator, making the description adequate but not 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?
With 0% schema description coverage, the description carries the full burden for parameters, and it largely succeeds. It explains calc_type values, rate as annual percent, time in years, compounding_frequency options, and principal. However, 'amount' is only described as 'Optional secondary parameter,' which is vague and does not clarify its role across different calc_type modes (e.g., percentage vs. EMI). Despite this gap, it adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates financial metrics and enumerates specific types (simple interest, compound interest, loan EMI, percentages), which distinguishes it from sibling math/stats tools. It is specific about the resource and verbs, though it doesn't explicitly contrast with siblings like evaluate_math_expression or calculate_statistics.
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 the calc_type options and parameter meanings, but it does not state when to prefer this tool over alternatives, nor does it mention exclusions (e.g., 'for general math use evaluate_math_expression'). The guidance is implicit rather than 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 readOnly, idempotent, and non-destructive behavior. The description adds no additional behavioral context (e.g., side effects, rate limits, or special conditions), so it meets the baseline without 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?
The description is concise, with the core purpose front-loaded and the parameter clarification following naturally. No unnecessary words or redundant details beyond what aids understanding.
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 that an output schema is indicated as present, the description need not explain return values. The operation list and data type clarification provide sufficient context for a straightforward statistical tool, though edge cases (e.g., empty data) are not covered.
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 schema lacks descriptions (0% coverage), but the description compensates by listing the allowed operation values ('mean', 'median', 'mode', 'variance', 'stdev', 'summary') and clarifying 'data' as a list of numerical observations. This meaningfully helps the agent understand valid inputs.
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 action ('Calculate') and the resource ('statistical summaries') for a dataset of numbers. It is distinct from sibling tools like arithmetic or unit conversion, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies statistical use but does not mention when not to use it or reference sibling tools like evaluation or arithmetic, leaving the selection decision to the agent.
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 cover read-only, idempotent, and non-destructive behavior. The description adds value by noting the expression is evaluated 'safely' and that precision refers to 'symbolic evaluation,' which signals how results are computed. It does not overclaim any 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 compact and front-loaded: purpose first, then supported capabilities, then a short Args section. Every sentence adds useful information without unnecessary padding.
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 is complete for a read-only, idempotent computation tool with an output schema. It covers the supported grammar, examples, and parameter semantics. The main missing piece is guidance on choosing among the overlapping arithmetic/scientific sibling tools.
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 0%, so the description must explain the parameters itself. It does this well, describing the expression string with concrete examples and clarifying precision as the number of decimal digits for symbolic evaluation with a default of 10.
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 evaluates complex mathematical expressions and enumerates supported operations and constants. It uses a specific verb ('evaluate') and resource ('complex mathematical expressions'), though it does not explicitly distinguish itself from siblings like perform_arithmetic or scientific_calculation.
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 gives no guidance on when to choose this tool relative to the sibling tools, such as perform_arithmetic or scientific_calculation. There are no conditions, exclusions, or alternative recommendations, leaving selection to inference.
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, so the safety profile is covered. The description adds illustrative input→output examples, but does not disclose behavior such as supported unit edge cases, error handling, or whether conversions are exact/approximate, which a complete behavioral disclosure would include.
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 starts with a one-sentence purpose, follows with three compact examples, and then a brief Args list. No wasted words, though the repetitive '-> Fahrenheit/Miles/Seconds' could be slightly consolidated. Overall it is efficient and well-structured.
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 three-parameter tool with an output schema and read-only/idempotent annotations, the description covers purpose, unit categories, usage examples, and parameter meaning. It does not exhaustively list all supported units, but the illustrative 'e.g.' list is sufficient for an agent to invoke the tool correctly in most 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?
Input schema has 0% description coverage, so the description must compensate. The Args section adds meaning: value is a 'numerical value', from_unit is a 'source unit string' with realistic examples, and to_unit is a 'target unit string'. The examples map arguments to concrete conversions, giving the agent more than the bare 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 explicitly states a specific verb ('Convert') and resource ('quantities between physical units'), naming four unit families. The three concrete examples make the purpose unmistakable and naturally differentiate it from sibling tools like evaluate_math_expression or financial_calculator.
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?
Clear context is provided through the primary sentence and examples, making it obvious the tool is for unit conversion. However, there is no explicit mention of when not to use it or how it relates to sibling tools like perform_arithmetic, so it falls one step short of fully explicit 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?
Annotations already indicate read-only and idempotent behavior. The description adds useful behavioral context by explaining how secondary_value changes the meaning of value for trig functions and how it serves as exponent or log base.
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 and well-structured, using a clear Args format with no redundant or extraneous content. Every sentence contributes parameter semantics or operational 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 provides enough detail to invoke the tool correctly for common cases, including parameter roles and trig unit handling. It does not mention error cases or return details, but an output schema is present and the core behavior is sufficiently covered.
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?
Despite the schema lacking property descriptions, the description thoroughly explains all three parameters: operation lists the allowed values, value identifies the primary input and trig unit behavior, and secondary_value clarifies its role as exponent, log base, or degree-mode flag.
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 function as performing scientific mathematical calculations and enumerates the supported operations. It is distinct from sibling tools by covering scientific functions like power, sqrt, trig, and logs.
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 does not provide guidance on when to prefer this tool over siblings such as evaluate_math_expression or perform_arithmetic. It lists operations but lacks explicit usage conditions or selection criteria.
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

Calculator MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Calculator MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Michaelndegwa1/mcp-tutorials/badges/card.svg)](https://glama.ai/mcp/servers/Michaelndegwa1/mcp-tutorials)

Score Badge

Copy to your README.md:

[![Calculator MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Michaelndegwa1/mcp-tutorials/badges/score.svg)](https://glama.ai/mcp/servers/Michaelndegwa1/mcp-tutorials)

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/Michaelndegwa1/mcp-tutorials'

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