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 を 2 つ受け取り、整数、小数、負数に対応しています。
ツール | 演算 | 呼び出しパラメータ例 | 結果 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
呼び出しが成功すると 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 を返す場合があります。10 進数の正確な計算が必要な用途には適していません。本バージョンは式の評価に対応していません。
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 クライアントと通信し、Web ページは提供しません。直接起動した後、クライアントからのメッセージを待つのは正常な動作です。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