F
licenseD
qualityD
maintenanceProvides basic mathematical operations (addition, subtraction, multiplication, division) through a calculate tool. Supports both stdio and HTTP/SSE transport modes.
1
9
-
calc_mcp
by nocodig
calc_mcp
通过 stdio 提供加、减、乘、除四种运算的计算器 MCP 服务。
使用 官方 MCP Python SDK 的 FastMCP API，依赖限定在 1.x，避免跨主要版本升级导致接口变化。
可用工具
所有工具都接收两个必填数值参数 a、b，支持整数、小数和负数。
工具 | 运算 | 调用参数示例 | 结果 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
成功调用的 structuredContent 为 {"result": 数值}，并提供兼容的文本内容。工具不读写文件、不访问网络。
错误以 MCP 工具结果的 isError: true 返回，不会中断服务：
除数为
0或-0.0：Cannot divide by zero.参数为 NaN 或无穷大：
Operands must be finite numbers.结果溢出为无穷大：
Result exceeds the supported finite number range.缺少参数或传入无法解析的数值：由 SDK 返回参数校验错误。
运算使用 Python 双精度浮点数，存在通常的浮点舍入误差，例如 0.1 + 0.2 可能返回 0.30000000000000004。不用于需要十进制精确计算的场景；本版本不支持表达式求值。
Related MCP server: MCP Math Tools
目录结构
calc_mcp/
├── pyproject.toml # 项目、依赖和命令行入口
├── uv.lock # 依赖版本锁定
├── README.md
├── .gitignore
├── src/calc_mcp/
│ ├── __init__.py
│ ├── __main__.py # python -m calc_mcp 入口
│ ├── server.py # MCP 实例和 stdio 启动
│ └── tools.py # 四则运算、边界检查和工具注册
└── tests/
└── test_server.py # 算术单元测试和 stdio 集成测试安装与启动
需要 Python 3.10+ 和 uv。在本项目目录执行：
uv sync
uv run calc-mcp也可以通过模块入口启动：
uv run python -m calc_mcp服务通过标准输入/输出与 MCP 客户端通信，不提供网页。直接启动后等待客户端消息属于正常现象。不要向 stdout 打印调试信息；日志应写入 stderr。
MCP 客户端配置示例
以下适用于使用 mcpServers JSON 配置格式的客户端，请根据实际客户端调整：
{
"mcpServers": {
"calc-mcp": {
"command": "uv",
"args": [
"--directory",
"/Users/lifang/product/0826/calc_mcp",
"run",
"calc-mcp"
]
}
}
}如果客户端找不到 uv，将 command 改为 uv 可执行文件的绝对路径。移动项目后需更新目录路径。
验证
uv run python -m unittest discover -s tests -v测试覆盖四则运算、负数、小数、零、非法参数、非有限数和溢出，并启动真实 stdio 子进程，检查 MCP 初始化、工具发现、工具调用以及错误后的正常调用。
后续扩展位置
在 src/calc_mcp/tools.py 中添加工具定义，并将函数加入 register_tools() 的注册列表。server.py 的 create_server() 会统一注册工具。
Available Tools
4 toolsaddARead-onlyIdempotent
Add two finite numbers: a + b.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry the readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds the finite-number constraint, but it does not disclose edge-case behavior such as overflow, precision limits, or handling of invalid non-finite inputs.
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 a single sentence that front-loads the operation and immediately clarifies the operands with the formula. Every word earns its place, with no filler or redundancy.
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 two-parameter arithmetic tool, the description is nearly complete: the operation, operand roles, and safety profile are all clear, and the output schema covers the return value. A small remaining gap is explicit guidance on non-finite or invalid inputs, though the word 'finite' partially addresses that.
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?
With zero schema description coverage, the schema's titles 'A' and 'B' carry no meaning on their own. The description gives both parameters semantic context through 'a + b' and the finite-number interpretation, but it provides no per-parameter constraints beyond that.
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 states a specific operation (add) and a specific resource (two finite numbers), and reinforces it with the formula 'a + b'. This clearly distinguishes it from the sibling tools subtract, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the applicable context clear: use this tool when two finite numbers need to be summed. It does not explicitly name alternatives or exclusions, but the operation name and formula make the choice obvious against the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
divideARead-onlyIdempotent
Divide a by b: a / b. Operands must be finite and b must not be zero.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds valuable precondition context: operands must be finite and the divisor must be non-zero. This goes beyond the annotations and alerts the agent to important input constraints, though it does not describe the exact error handling for violated preconditions.
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 a single efficient sentence that front-loads the core operation (a / b) and immediately states the critical constraints. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-number arithmetic tool with an output schema and annotations covering safety and side effects, this description is complete. It includes the operation, operand roles, and the non-zero/finiteness preconditions. Nothing essential is missing.
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%, but the description fully compensates by defining the relationship exactly: a is the dividend and b is the divisor via a / b. It also attaches the necessary constraints to both operands, making parameter usage unambiguous despite the bare schema.
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 states a specific verb and resource: divide a by b with the explicit formula a / b. This clearly distinguishes it from the sibling tools add, subtract, and multiply, and the finite/non-zero constraints further pin down its intended operation.
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?
The description clearly implies use when a quotient of two finite numbers is needed, and the sibling list makes the alternative arithmetic tools obvious. It does not explicitly say 'use this instead of multiply/subtract/add', but the task context and formula provide sufficient guidance. The constraint that b must not be zero is a useful usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
multiplyARead-onlyIdempotent
Multiply two finite numbers: a * b.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the 'finite numbers' constraint, which is useful domain context, but it does not add much beyond that.
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 a single front-loaded sentence with no wasted words. It states the verb, operand constraints, and formula immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an extremely simple pure arithmetic tool with an output schema and comprehensive annotations, the description is complete. An agent knows exactly what inputs are valid and what operation will be performed.
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?
Schema description coverage is 0%, so the description must carry meaning for the parameters. The phrase 'a * b' and 'two finite numbers' clarifies that both parameters are numeric operands and their relationship, but it does not describe each parameter individually. This is adequate for such a simple operation.
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 uses a specific verb ('multiply'), identifies the resource ('two finite numbers'), and states the exact operation ('a * b'). This clearly differentiates it from sibling tools add, subtract, and divide.
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?
The description makes the use case explicit: call this tool when you need to multiply exactly two finite numbers. It does not explicitly name alternatives or exclusions, but the sibling set is small and the operation is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subtractARead-onlyIdempotent
Subtract b from a: a - b. Both operands must be finite numbers.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations by clarifying operand order (non-commutative behavior) and the constraint that both operands must be finite numbers.
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 a single efficient sentence that front-loads the formula and then adds the key constraint. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-operand arithmetic tool with comprehensive annotations and an output schema, the description covers the essential semantic and constraint information. Nothing critical is missing for an agent to invoke it correctly.
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?
Since the schema provides no parameter descriptions, the description carries the burden of explaining 'a' and 'b'. It does so via the formula, making clear that 'a' is the minuend and 'b' is the subtrahend, and adds the finite-number requirement. This is strong compensation for 0% schema coverage.
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 operation with a specific formula, 'Subtract b from a: a - b', which precisely defines the tool's behavior. It distinguishes itself from siblings like add, multiply, and divide by naming the exact arithmetic operation and operand order.
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 the tool is for subtraction but does not explicitly state when to use it versus the sibling tools add, multiply, or divide. For a simple arithmetic operation this is minimally sufficient, yet there is no explicit usage context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
add - First observed
divide - First observed
multiply - First observed
subtract
TDQS
A4.4/5.0
Scored across 4 tools
Disambiguation5/5
Each tool maps to a single, distinct arithmetic operation: addition, subtraction, multiplication, or division. There is no overlap or ambiguity between tool purposes.
Naming Consistency5/5
All tool names follow the same simple verb-only pattern: add, subtract, multiply, divide. The naming is perfectly consistent and instantly predictable.
Tool Count5/5
Four tools is the ideal size for a basic arithmetic calculator server. Each tool covers a fundamental operation without unnecessary bloat.
Completeness5/5
The tool set fully covers the core arithmetic operations needed for a calculator: addition, subtraction, multiplication, and division, with appropriate edge-case handling for division by zero. It is a complete minimal surface for its stated purpose.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Evaluates Reverse Polish Notation (postfix) expressions: arithmetic, trig, logs, bitwise ops.
High-precision finance & business calculations for AI agents — exact decimals, never floats.
Create friendly greetings and add two numbers instantly. Speed up simple tasks and streamline ligh…
Add two numbers instantly and generate friendly greetings on demand. Speed up quick math and perso…
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides basic mathematical operations like addition, subtraction, multiplication, and division via the Model Context Protocol using stdio transport. This project serves as a complete reference implementation for a functional MCP server and client setup.-
- AlicenseNot gradedqualityCmaintenanceEnables basic calculator operations such as add, subtract, multiply, and divide through an MCP interface.4ISC
- AlicenseAqualityBmaintenanceProvides basic arithmetic operations (add, subtract, multiply, divide) through MCP, enabling AI clients to perform calculations via natural language.423MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/nocodig/calc_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server