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., "@Math MCP Server What is 15 divided by 3?"
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 clean and simple Model Context Protocol (MCP) server built with FastMCP that provides four fundamental mathematical operations as tools.
This MCP server exposes the following tools:
add - Add two numbers together
subtract - Subtract the second number from the first
multiply - Multiply two numbers together
divide - Divide the first number by the second (with zero-division protection)
Related MCP server: Math Operations MCP Server
# Install dependencies
uv syncThe server can be run directly using:
uv run math-mcp-serverAdd this server to your MCP client configuration (e.g., ~/.kiro/settings/mcp.json):
{
"mcpServers": {
"math": {
"command": "uv",
"args": [
"--directory",
"d:\\MCP\\math-mcp-server",
"run",
"math-mcp-server"
]
}
}
}Once configured, you can use the tools through your MCP client:
Addition:
Input: a=5, b=3
Output: 5 + 3 = 8
Subtraction:
Input: a=10, b=4
Output: 10 - 4 = 6
Multiplication:
Input: a=7, b=6
Output: 7 × 6 = 42
Division:
Input: a=15, b=3
Output: 15 ÷ 3 = 5.0
The implementation is extremely simple and readable using FastMCP:
from fastmcp import FastMCP
mcp = FastMCP("Math Operations Server")
@mcp.tool()
def add(a: float, b: float) -> str:
"""Add two numbers together."""
result = a + b
return f"{a} + {b} = {result}"
# ... and so on for subtract, multiply, divideEach operation is a separate @mcp.tool() decorated function, making the code:
Easy to read and understand
Simple to extend with new operations
Self-documenting with type hints and docstrings
math-mcp-server/
├── src/
│ └── math_mcp_server/
│ └── __init__.py # Main server implementation (4 simple functions!)
├── pyproject.toml # Project configuration
└── README.md # This filePython >= 3.14
fastmcp >= 3.4.6
MIT
Add two numbers together.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second 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 burden of behavioral disclosure. It fully describes the behavior: adds two numbers and returns their sum. There are no side effects, prerequisites, or hidden behaviors. The output schema handles return values.
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, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity and is front-loaded with the 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 tool's simplicity—two numeric parameters, an output schema, and no annotations—the description is fully complete. It clearly states what the tool does, with the schema documenting inputs and outputs.
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 already describes both parameters (a and b) with 100% coverage ('First number' and 'Second number'). The tool description adds no additional meaning beyond the schema, only restating the operation. This matches the baseline for full schema coverage.
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 'Add two numbers together' uses a specific verb and resource, clearly distinguishing it from sibling tools like subtract, multiply, and divide. It leaves no ambiguity about the operation performed.
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 clearly states the operation (adding two numbers) and implicitly indicates when to use it—whenever addition is needed. It lacks explicit mention of alternatives, but for such a fundamental operation, the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Divide first number by second number.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | Numerator | |
| b | Yes | Denominator (cannot be 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 disclose behavioral traits. However, it only states the operation and omits edge cases such as division by zero behavior, return type, or error handling. The schema mentions the denominator constraint, but the description itself adds no behavioral context beyond the basic operation.
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, concise sentence with no unnecessary words. It immediately and clearly conveys the tool's purpose, making it easy to parse and understand.
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?
This is a simple arithmetic tool with a complete input schema and an output schema present. The description is adequate for understanding the tool's function; the only minor gap is lack of explicit edge-case behavior, but the schema already covers the zero-denominator restriction.
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 provides 100% parameter description coverage ('Numerator', 'Denominator (cannot be zero)'). The description merely restates the operation without adding new semantics for 'a' or 'b', so the baseline score of 3 applies.
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 uses the specific verb 'divide' and specifies the operand order ('first number by second number'), clearly distinguishing it from sibling tools 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?
The description gives clear context for when to use the tool (when division of two numbers is needed) and implicitly contrasts with the other arithmetic operations. It does not explicitly name alternatives, but the simplicity of the operation makes the usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiply two numbers together.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number |
| 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 the full burden of behavioral disclosure. It only states the operation itself without mentioning edge cases, type handling, or error behavior. This is minimal and adds little beyond the tool's name.
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, direct sentence that is immediately clear and contains zero unnecessary words. It is appropriately concise and front-loaded.
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 fully described input schema, and the presence of an output schema, the description is adequate. It does not discuss edge cases, but for a basic arithmetic operation, these are not critical.
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 fully documents both parameters (a and b) with descriptions. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 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?
The description uses the specific verb 'multiply' and clearly identifies the resource ('two numbers'), which fully distinguishes it from sibling tools like add, subtract, and divide. The purpose is 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?
The description implies its usage through the verb 'multiply' but does not explicitly state when to use this tool over alternatives or mention any prerequisites. No exclusionary guidance is provided, so it relies on the reader's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subtract second number from first number.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number (minuend) | |
| b | Yes | Second number (subtrahend) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the core behavior and, importantly, specifies operand order ('second number from first'). As a pure arithmetic function with no side effects, this covers the essential behavioral trait.
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 that conveys the entire operation with zero wasted words. It is appropriately concise for a tool of this simplicity.
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 low complexity, 100% schema coverage, and presence of an output schema, the description is fully sufficient. There are no hidden behaviors, side effects, or prerequisites that need to be documented.
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% with clear parameter descriptions ('First number (minuend)' and 'Second number (subtrahend)'). The description restates the order but adds no meaning beyond the schema, so the baseline 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?
The description uses a specific verb ('Subtract') with a clear resource ('second number from first number'), precisely defining the operation. This unambiguously distinguishes it from siblings like add, multiply, and divide.
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 clearly implies when to use it: any time a difference between two numbers is needed. It doesn't explicitly contrast with siblings, but the operation is self-evident and no exclusion is needed for this simple arithmetic tool.
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.0adddividemultiplysubtractEach tool performs a distinct arithmetic operation (add, subtract, multiply, divide) with no overlap or ambiguity. An agent can clearly tell them apart based on their names and descriptions.
All tool names are single, lowercase verbs that directly describe their operation (add, subtract, multiply, divide). The naming pattern is perfectly consistent and predictable.
With exactly four tools, this server is well-scoped for basic arithmetic operations. It neither feels thin nor bloated, fitting comfortably within the ideal range for a focused utility server.
The four fundamental arithmetic operations cover the core domain of a basic math server. There are no obvious gaps for the stated purpose, as these are the essential operations one would expect.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Math.js MCP — wraps the mathjs.org API (free, no auth)
Free calculators as MCP tools: finance, taxes, health, units, dates. Search, fetch & compute.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DevCraftYaseen/MathMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server