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
Ein Taschenrechner-MCP-Dienst, der über stdio die vier Grundrechenarten Addition, Subtraktion, Multiplikation und Division bereitstellt.
Es nutzt die FastMCP-API des offiziellen MCP Python SDK; die Abhängigkeit ist auf 1.x beschränkt, um Schnittstellenänderungen durch Hauptversions-Upgrades zu vermeiden.
Verfügbare Tools
Alle Tools akzeptieren zwei erforderliche numerische Parameter a, b und unterstützen ganze Zahlen, Dezimalzahlen und negative Zahlen.
Tool | Operation | Beispiel für Aufrufparameter | Ergebnis |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bei erfolgreichen Aufrufen ist structuredContent {"result": 数值}; zusätzlich wird kompatibler Textinhalt bereitgestellt. Die Tools lesen und schreiben keine Dateien und greifen nicht auf das Netzwerk zu.
Fehler werden über isError: true im MCP-Toolergebnis zurückgegeben und unterbrechen den Dienst nicht:
Divisor ist
0oder-0.0:Cannot divide by zero.Bei NaN- oder unendlichen Operanden:
Operands must be finite numbers.Wenn das Ergebnis in unendlich überläuft:
Result exceeds the supported finite number range.Fehlende Parameter oder nicht parsebare Zahlenwerte werden vom SDK als Parametervalidierungsfehler zurückgegeben.
Die Berechnungen verwenden Pythons Doppelpräzisions-Gleitkommazahlen; es gelten die üblichen Gleitkomma-Rundungsfehler, z. B. kann 0.1 + 0.2 den Wert 0.30000000000000004 liefern. Das Tool ist nicht für Szenarien gedacht, die dezimal exakte Berechnung erfordern; diese Version unterstützt keine Ausdrucksauswertung.
Related MCP server: MCP Math Tools
Verzeichnisstruktur
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 集成测试Installation und Start
Erforderlich sind Python 3.10+ und uv. Führen Sie in diesem Projektverzeichnis Folgendes aus:
uv sync
uv run calc-mcpAlternativ kann der Dienst über den Modul-Einstiegspunkt gestartet werden:
uv run python -m calc_mcpDer Dienst kommuniziert über Standardeingabe/-ausgabe mit MCP-Clients und bietet keine Weboberfläche. Es ist normal, dass er nach dem direkten Start auf Client-Nachrichten wartet. Geben Sie keine Debug-Informationen auf stdout aus; Logs sollten auf stderr geschrieben werden.
Beispielkonfiguration für MCP-Clients
Das Folgende gilt für Clients, die das JSON-Konfigurationsformat mcpServers verwenden; passen Sie es an Ihren tatsächlichen Client an:
{
"mcpServers": {
"calc-mcp": {
"command": "uv",
"args": [
"--directory",
"/Users/lifang/product/0826/calc_mcp",
"run",
"calc-mcp"
]
}
}
}Wenn der Client uv nicht findet, ändern Sie command auf den absoluten Pfad der ausführbaren Datei uv. Nach dem Verschieben des Projekts muss der Verzeichnispfad aktualisiert werden.
Verifizierung
uv run python -m unittest discover -s tests -vDie Tests decken die vier Grundrechenarten, negative Zahlen, Dezimalzahlen, Null, ungültige Parameter, nicht endliche Zahlen und Überlauf ab. Sie starten einen echten stdio-Unterprozess und prüfen die MCP-Initialisierung, Tool-Erkennung, Tool-Aufrufe sowie normale Aufrufe nach Fehlern.
Zukünftige Erweiterungspunkte
Fügen Sie Tool-Definitionen in src/calc_mcp/tools.py hinzu und nehmen Sie die Funktionen in die Registrierungsliste von register_tools() auf. create_server() in server.py registriert die Tools einheitlich.
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