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., "@Calculator MCP Server what's 47 times 89?"
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 simple calculator MCP (Model Context Protocol) server built with FastMCP. Exposes basic arithmetic tools that you can plug into any MCP client such as Claude Desktop.
Tool | Description |
| Add two numbers |
| Subtract |
| Multiply two numbers |
| Divide |
| Raise |
| Square root of a non-negative number |
Related MCP server: Calculator MCP Server
# 1. Create a virtual environment
uv venv .venv
# 2. Install dependencies (reads pyproject.toml)
uv sync
# 3. (Optional) Activate the venv
source .venv/bin/activate# Runs over stdio (default)
uv run python main.pyOr use the FastMCP CLI:
uv run fastmcp dev main.py # runs with auto-reload
uv run fastmcp list main.py # list exposed tools
uv run fastmcp call --server-spec main.py --target add --input-json '{"a": 3, "b": 4}'Quit Claude Desktop completely.
Open claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add (or merge) the following mcpServers entry, replacing the project path with your local path:
{
"mcpServers": {
"calculator": {
"command": "uv",
"args": [
"run",
"--project",
"/absolute/path/to/calculator",
"--directory",
"/absolute/path/to/calculator",
"python",
"/absolute/path/to/calculator/main.py"
]
}
}
}Note: If
uvis not on Claude Desktop'sPATH(common for GUI apps), use the absolute path instead, e.g."/Users/<you>/.local/bin/uv". Find yours withwhich uv.
Relaunch Claude Desktop. You should see a calculator icon, and the 6 tools will be available to use in chat.
calculator/
├── main.py # FastMCP server with all tools
├── pyproject.toml # Project metadata + dependencies
├── uv.lock # Lock file
└── README.mdAdd two numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The first addend (any real number). | |
| b | Yes | The second addend (any real number). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It doesn't mention that the operation is pure and safe, returns a sum, handles large numbers, or any error conditions. It only states the basic action.
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?
A single clear sentence with no waste, front-loaded with the essential information.
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 the tool's simplicity, the description is adequate but minimal. It could specify the return type or that it performs arithmetic, but with an output schema present, return values need not be explained. No annotations exist, so it relies entirely on the description for behavior, which is sparse.
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 coverage is 100%, so the schema fully documents the parameters 'a' and 'b' as addends. The description adds no additional meaning beyond what the 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?
States a specific verb (add) and resource (two numbers), which is clear. However, it doesn't differentiate from siblings like subtract or multiply beyond the operation name, which is self-evident but not made explicit.
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 guidance on when to use this tool versus alternatives such as power or sqrt. The description provides no context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Divide the first number by the second.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The dividend (the number to be divided). | |
| b | Yes | The divisor (the number to divide by). Must be non-zero. |
| 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 must carry behavioral disclosure. It states the core computation but does not mention division-by-zero handling or return behavior; however, the schema documents the non-zero constraint on b, and the operation is a simple deterministic calculation. The description is minimally adequate.
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 a single, front-loaded sentence with no wasted words. It communicates the operation immediately and is appropriately sized for a simple arithmetic tool.
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 two-parameter, deterministic arithmetic tool with full schema coverage and an output schema, the description is complete enough. It does not need to explain return values or permissions, and the non-zero divisor constraint is captured in the schema.
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 100%, so the parameter meanings are already fully documented in the schema (a = dividend, b = divisor, non-zero). The description reinforces the order (first/second) but adds little beyond what the schema provides, matching the baseline of 3 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific arithmetic verb (divide) and the operands (first number by second), which is exactly what the tool does. It is unambiguous and inherently distinguishes itself from siblings such as add, subtract, and multiply.
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?
There is no guidance on when to use division versus the sibling arithmetic tools, nor any conditions or prerequisites. The operation is simple enough that an agent can infer usage, but the description itself provides no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiply two numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The first factor. | |
| b | Yes | The second factor. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is pure, whether it handles edge cases like NaN or infinity, or what the return type is, though the presence of an output schema mitigates this somewhat. Still, for a mathematical operation, basic behavioral traits like purity and numeric handling are absent.
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 a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple arithmetic operation.
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 the simplicity of the tool, the description is adequate but minimal. It does not explain how it differs from related tools like 'power' or provide any behavioral context, though the output schema and full parameter descriptions reduce the need for additional detail.
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 100%, so the schema already documents both parameters as 'The first factor' and 'The second factor'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Multiply two numbers'), which is clear and unambiguous. However, it does not differentiate itself from sibling tools like add, subtract, or power, leaving the agent to infer that multiplication is distinct from exponentiation.
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 guidance is provided on when to use this tool versus alternatives such as 'power' for repeated multiplication or 'add' for addition. The description offers no context or exclusions, requiring the agent to rely on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raise a base to a given exponent.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | The number to be raised to a power. | |
| exponent | Yes | The power to raise ``base`` to. Can be fractional (e.g. ``0.5`` for square root) or negative (for reciprocal powers). |
| 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 burden, but a pure arithmetic function has almost no behavioral traits to disclose. It is silent on determinism, domain restrictions (e.g. negative base with fractional exponent), and error behavior, which is a modest gap for a tool with zero annotation coverage.
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?
A single front-loaded sentence with zero waste. Nothing extraneous, nothing missing syntactically.
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 exists and both parameters are fully documented, so return values and argument meaning are covered. The only shortfall is the missing pointer on when to prefer sqrt or multiply, a minor gap for a two-parameter math function.
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 100%, including the note that the exponent can be fractional or negative, so the schema does the heavy lifting. The description adds no meaning beyond the schema, making the baseline 3 appropriate.
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?
States a specific verb and resource (raise a base to an exponent), which unambiguously identifies exponentiation. It does not differentiate from siblings such as sqrt, which overlaps for exponent 0.5, but the operation is otherwise self-evident.
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 guidance on when to use this instead of multiply, sqrt, or repeated add. The overlap with sqrt (0.5 exponent) is a real routing decision that the description ignores.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the (principal) square root of a non-negative number.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The number whose square root is required. Must be >= 0. |
| 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 burden, and it does disclose the domain constraint ('non-negative') and the 'principal' root convention. However, it does not state what happens on negative input (error vs. NaN), which is the main behavioral question for this 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?
A single sentence with zero waste, front-loading the operation and the key domain constraint. Perfectly sized for a primitive math function.
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 exists, so return values need not be explained, and the domain constraint is present. The only minor gap is undefined error behavior for negative inputs, which for a math primitive is a small omission.
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 100% and the schema already states the value 'Must be >= 0', so the description adds nothing about parameter syntax or format beyond the schema. Baseline 3 is correct 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Return the (principal) square root of a non-negative number.' This clearly distinguishes it from the sibling operations add, subtract, multiply, divide, and power without needing to open any schema.
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 only implied by the operation itself; there is no explicit statement of when to prefer this over power (x^0.5) or what to do for edge cases. For a trivial math primitive the intent is obvious, but no routing guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subtract the second number from the first.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The minuend (the number to subtract from). | |
| b | Yes | The subtrahend (the number to subtract). |
| 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 behavioral burden, but for a pure numerical function there is little to disclose. It does not state that the operation is side-effect free or how non-numeric input is handled, yet the schema constrains inputs to numbers and an output schema documents the return, so nothing is misleading.
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?
A single sentence with zero filler, and the critical detail (operand order) is front-loaded. Nothing could be removed without losing meaning.
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?
With an output schema present and both parameters fully documented in the schema, the description supplies everything needed to invoke the tool correctly. It is minimal but complete for a two-argument arithmetic primitive.
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 100%, with `a` documented as the minuend and `b` as the subtrahend, so the schema does the heavy lifting. The description's phrasing ('second from the first') only restates the operand ordering already given by the schema, adding no new semantics.
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 states a specific verb (subtract) and precisely identifies the operand order ('the second number from the first'), removing any ambiguity about which argument is subtracted from which. It is fully unambiguous on its own, though it does nothing to differentiate itself from the arithmetic siblings beyond naming the operation.
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?
There is no explicit when-to-use statement, no mention of alternatives such as `add` or `divide`, and no conditions or exclusions. For a pure arithmetic primitive the purpose does imply its usage, which lands it at the 'implied usage' level rather than explicit guidance.
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.0adddividemultiplypowersqrtsubtractScored across 6 tools
Each tool performs a single, clearly distinct arithmetic operation with no overlap or ambiguity. An agent can easily select the correct tool for a given mathematical need.
Names are lowercase and concise, following a consistent operation-based convention. Minor deviation: add/subtract/multiply/divide are verbs while power/sqrt are noun-like, but still predictable.
Six tools are well-scoped for a basic calculator, covering core arithmetic operations without bloat or obvious redundancy.
Core arithmetic operations (add, subtract, multiply, divide) and common extras (power, sqrt) are present. Minor gaps include modulo, absolute value, rounding, or logarithm, but agents can work around them for basic calculation tasks.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp
