Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Calculator MCP Server Convert 100 degrees Fahrenheit to Celsius"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A feature-rich Model Context Protocol (MCP) server for mathematical calculations, scientific functions, unit conversions, financial metrics, and statistical analysis.
Built with Python 3.10+, the official mcp SDK (FastMCP), and sympy. Supports both stdio (Claude Desktop) and sse (Claude Web / Remote HTTP Connectors) transport modes.
evaluate_math_expression: Evaluates custom mathematical expressions safely using SymPy (e.g. 2 * (3 + 4), sqrt(144) + sin(pi / 2), log(100, 10), 5^3).
perform_arithmetic: Basic arithmetic (add, subtract, multiply, divide) on arrays of numbers.
scientific_calculation: Powers, roots (sqrt, cbrt), factorials, logarithms (log, ln), and trigonometric functions (sin, cos, tan).
convert_unit: Physical unit conversions (Length, Mass/Weight, Temperature, Volume, Time).
financial_calculator: Simple interest, Compound interest, Loan EMI calculations, and Percentages.
calculate_statistics: Summary statistics (mean, median, mode, variance, stdev, summary).
Related MCP server: MCP Mathematics
Install Dependencies:
pip install -r requirements.txt
pip install -e .Run Automated Unit Tests:
pytestYour claude_desktop_config.json has been automatically created at:
C:\Users\ADMIN\AppData\Roaming\Claude\claude_desktop_config.json
{
"mcpServers": {
"calculator": {
"command": "C:\\Users\\ADMIN\\AppData\\Local\\Programs\\Python\\Python312\\python.exe",
"args": [
"-m",
"calculator_mcp.server"
],
"env": {
"PYTHONPATH": "E:/mcp tutorials"
}
}
}
}Fully exit and restart Claude Desktop.
Open a chat and look for the 🔨 (hammer/tools icon) at the bottom right of the message bar.
Ask Claude: "What is sqrt(144) + sin(pi / 2)?" or "Convert 100 degC to degF".
To run the Calculator MCP as a web HTTP service (for web-based platforms, web connectors, or remote AI agents):
Start the SSE Web Server:
python -m calculator_mcp.server --transport sse --port 8000Web Client Configuration:
{
"mcpServers": {
"calculator-web": {
"serverUrl": "http://localhost:8000/sse"
}
}
}Public Tunneling for Remote Web Apps (Optional):
If your web client (like remote Claude Web) is hosted outside your local network, expose port 8000 using ngrok or localtunnel:
npx localtunnel --port 8000
# Or using ngrok:
ngrok http 8000Then use the generated public HTTPS URL: https://<your-subdomain>.loca.lt/sse in your Web MCP connector configuration.
You can launch the official Model Context Protocol interactive Web Inspector UI to visually test all tools in your browser:
mcp dev calculator_mcp/server.pyOr via Node:
npx @modelcontextprotocol/inspector@0.4.1 python -m calculator_mcp.serverCalculate statistical summaries for a dataset of numbers.
Args: operation: 'mean', 'median', 'mode', 'variance', 'stdev', or 'summary' data: List of numerical observations
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| operation | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Convert quantities between physical units (length, weight/mass, temperature, volume, time).
Examples:
convert_unit(100, "degC", "degF") -> Fahrenheit
convert_unit(5, "km", "miles") -> Miles
convert_unit(2, "hours", "sec") -> Seconds
Args: value: Numerical value to convert from_unit: Source unit string (e.g., 'km', 'miles', 'kg', 'lbs', 'degC', 'degF', 'hr', 'sec') to_unit: Target unit string
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| to_unit | Yes | ||
| from_unit | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Evaluate complex mathematical expressions safely.
Supports addition, subtraction, multiplication, division, exponents (^ or **), roots (sqrt, cbrt), trigonometric functions (sin, cos, tan), logarithms (log, log10, ln), and constants (pi, e).
Args: expression: The mathematical expression string (e.g., '2 * (3 + 4)', 'sqrt(144) + sin(pi / 2)', '5^3') precision: Number of decimal digits of precision for symbolic evaluation (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| precision | No | ||
| expression | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Calculate financial metrics like Simple Interest, Compound Interest, Loan EMI, and Percentages.
Args: calc_type: 'simple_interest', 'compound_interest', 'loan_emi', or 'percentage' principal: Principal loan/investment amount (or base value for percentage) rate: Annual interest rate in percent (e.g., 7.5 for 7.5%) time: Duration in years compounding_frequency: Times per year compounding occurs (1=annual, 4=quarterly, 12=monthly) amount: Optional secondary parameter
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | ||
| time | No | ||
| amount | No | ||
| calc_type | Yes | ||
| principal | No | ||
| compounding_frequency | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Perform basic arithmetic on a list of numbers.
Args: operation: 'add', 'subtract', 'multiply', or 'divide' numbers: List of numbers to operate on in sequence
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | ||
| operation | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Perform scientific mathematical calculations.
Args: operation: 'power', 'sqrt', 'cbrt', 'factorial', 'sin', 'cos', 'tan', 'log', 'ln' value: Primary number input (for trig functions, value is in degrees if secondary_value is 1, else radians) secondary_value: Exponent for power, base for log, or 1 to indicate degree mode for trig functions
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| operation | Yes | ||
| secondary_value | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0calculate_statisticsconvert_unitevaluate_math_expressionfinancial_calculatorperform_arithmeticscientific_calculationThere 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 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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
MCPCalc gives agents access to a comprehensive library of calculators spanning finance, math, health, construction, engineering, food, automotive, and more. It includes a full Computer Algebra System (CAS) and a grid-based Spreadsheet calculator.
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
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
