Click on "Deploy 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., "@calc-mcp-server what is 2 + 3 * (4 - 1) / 2 squared?"
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.
An MCP server that does arithmetic, exactly — so an LLM does not have to do it mentally.
One tool, calculate, evaluating expressions against a hand-rolled AST allowlist. No eval(), no
sympy, no unbounded dependencies.
2 + 3 * (4 - 1) / 2 ** 2 -> 4.25
sqrt(16) + sin(pi/2) -> 5.0
123456789 * 987654321 -> 121932631112635269The widely-used mcp-server-calculator package is abandoned (last commit May 2025) and declares
mcp>=1.4.1 with no upper bound. When the MCP Python SDK released v2 and removed
mcp.server.fastmcp, every uvx …@latest install of it started crashing on import — which took down
the entire MCP proxy hosting it, and every other server alongside it.
No maintained Python replacement exists. The one actively-maintained npm calculator computes in
float64, so 123456789 * 987654321 comes back as 121932631112635260 — off by 9. That is a poor
trait in a tool whose whole purpose is that the model should not be doing the arithmetic itself.
So this server:
bounds its one dependency (mcp[cli]>=2,<3) — the failure above cannot recur here;
keeps integers exact at any size, never coercing to float;
bounds resource use, not just code execution — see below.
Related MCP server: Symath-MCP
Two problems, and most calculator servers only solve the first.
Code execution. Expressions are parsed with ast.parse and walked against an explicit allowlist of
node types. Attribute is not on it, so (1).__class__.__bases__ is rejected. A Call is only
evaluated when its target is a bare name in the function allowlist, so __import__('os').system(…) is
rejected before any argument is even evaluated.
Resource exhaustion. An allowlist alone still lets 9**9**9 occupy the process for minutes on
unbounded bignum exponentiation — the incumbent hangs for over five seconds on it. Four caps close
that: expression length (500 chars), nesting depth (32), result size (4300 digits, checked on the
operands before exponentiating), and factorial argument (1000).
Full detail in docs/tech/SAFE-EVALUATION.md.
uvx calc-mcp-serverPin it. Do not add @latest — that is how the package this replaces broke.
As a stdio MCP server:
{
"mcpServers": {
"calculator": {
"command": "uvx",
"args": ["calc-mcp-server"]
}
}
}calculate toolArgument | Type | Description |
|
| The expression to evaluate |
Returns the result as a string, or a line starting with Error: explaining why the expression was
rejected. The tool never raises, so a bad expression is an answer the agent can read back rather than a
tool-call failure.
Operators — + - * / // % **, parentheses, unary +/-. ^ is accepted as a power
operator, and × · ÷ − are accepted as their ASCII equivalents (speech-to-text produces them).
Constants — pi, e, tau.
Functions — abs round min max sqrt exp log log2 log10 sin cos tan asin
acos atan atan2 degrees radians hypot floor ceil factorial gcd lcm.
Results — integer arithmetic returns an exact integer of any size. Floats are rendered at 12
significant digits, which removes IEEE-754 representation noise (0.1 + 0.2 reads 0.3, not
0.30000000000000004) while keeping far more precision than a calculator result is used at. A whole
float keeps its .0, so 8 / 2 reads 4.0 and stays distinct from the exact integer 4.
uv sync
uv run pytest tests/ -v
uv run ruff check .
uv run ruff format .See AGENTS.md for the project guide and docs/ for the full documentation set.
MIT — see LICENSE.
Evaluate an arithmetic expression and return the result.
Args:
expression: The expression to evaluate, for example "2 + 3 * (4 - 1)",
"sqrt(16) + sin(pi/2)" or "123456789 * 987654321". `^` is accepted
as a power operator; `×` and `·` as multiply, `÷` as divide, and
`−` (U+2212) as minus.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses accepted operator symbols (`^`, `×`, `÷`, `−`) and shows function examples (sqrt, sin), adding meaningful behavioral detail. It does not explicitly state that the operation is non-destructive, but that is strongly implied for a calculation tool.
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 efficiently structured: a clear one-sentence summary followed by a brief parameter explanation. The examples and operator notes are valuable, though slightly verbose.
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 calculator with one parameter, the description is complete: it explains the parameter, accepted syntax, and examples. Since an output schema exists, return-value details are not needed. No annotations are required for such a safe operation.
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 input schema only defines 'expression' as a string with no description, so schema coverage is 0%. The description compensates fully by explaining what the expression should look like, providing multiple examples, and documenting accepted operator aliases.
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 an arithmetic expression and returns the result. This is a specific verb+resource ('Evaluate expression') that fully conveys the tool's purpose.
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?
Usage is implied: the description gives examples of valid expressions, indicating when to use the tool (when arithmetic evaluation is needed). However, there is no explicit when/when-not guidance or mention of alternatives, though no siblings exist.
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.
v0.1.0calculateScored across 1 tool
With only one tool, there is no potential for confusion between tools. The tool's purpose is clearly defined by its name and description.
The single tool uses a clear verb-based name ('calculate') that accurately describes its action. There is no inconsistency to evaluate.
A single calculator tool is appropriate for the server's stated purpose, though it sits at the lower boundary of expected scope. The tool is non-trivial and fully serves its intended function.
The tool covers arithmetic expression evaluation comprehensively, including operators, functions, and constants. There are no obvious gaps in functionality for a basic calculator server.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Safe scientific calculator MCP for numeric expressions
Math.js MCP — wraps the mathjs.org API (free, no auth)