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 what's 15 factorial?"
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.
基于 Model Context Protocol (MCP) 的数值计算器，提供了简单的加减乘除、幂运算、平方根运算和整数阶乘运算。
{
"tools": [
{
"name": "add",
"description": "执行浮点数加法运算",
"inputSchema": {
"type": "object",
"properties": {
"a": {
"title": "A",
"type": "number"
},
"b": {
"title": "B",
"type": "number"
}
},
"required": [
"a",
"b"
],
"title": "addArguments"
}
},
{
"name": "subtract",
"description": "执行浮点数减法运算",
"inputSchema": {
"type": "object",
"properties": {
"a": {
"title": "A",
"type": "number"
},
"b": {
"title": "B",
"type": "number"
}
},
"required": [
"a",
"b"
],
"title": "subtractArguments"
}
},
{
"name": "multiply",
"description": "执行浮点数乘法运算",
"inputSchema": {
"type": "object",
"properties": {
"a": {
"title": "A",
"type": "number"
},
"b": {
"title": "B",
"type": "number"
}
},
"required": [
"a",
"b"
],
"title": "multiplyArguments"
}
},
{
"name": "divide",
"description": "执行浮点数除法运算\n Args:\n b: 除数（必须非零）\n ",
"inputSchema": {
"type": "object",
"properties": {
"a": {
"title": "A",
"type": "number"
},
"b": {
"title": "B",
"type": "number"
}
},
"required": [
"a",
"b"
],
"title": "divideArguments"
}
},
{
"name": "power",
"description": "计算幂运算",
"inputSchema": {
"type": "object",
"properties": {
"base": {
"title": "Base",
"type": "number"
},
"exponent": {
"title": "Exponent",
"type": "number"
}
},
"required": [
"base",
"exponent"
],
"title": "powerArguments"
}
},
{
"name": "sqrt",
"description": "计算平方根",
"inputSchema": {
"type": "object",
"properties": {
"number": {
"title": "Number",
"type": "number"
}
},
"required": [
"number"
],
"title": "sqrtArguments"
}
},
{
"name": "factorial",
"description": "计算整数阶乘",
"inputSchema": {
"type": "object",
"properties": {
"n": {
"title": "N",
"type": "integer"
}
},
"required": [
"n"
],
"title": "factorialArguments"
}
}
]
}Related MCP server: Calculator MCP Server
[
{
"mcpServers": {
"calculator": {
"command": "uvx",
"args": [
"mcp-calculator-kel@latest"
]
}
}
}
]执行浮点数加法运算
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| 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 full burden for behavioral disclosure. It only states the operation type (floating-point addition) without mentioning error handling (e.g., overflow), precision limits, performance characteristics, or return format. For a computational tool with zero annotation coverage, this is insufficient behavioral context.
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, efficient sentence in Chinese that directly states the tool's function with zero wasted words. It's appropriately sized for a simple arithmetic tool and front-loads the essential information without unnecessary elaboration.
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 low complexity (basic arithmetic), 2 parameters, no annotations, but with an output schema present, the description is minimally complete. It states the operation type but lacks behavioral details and parameter context. The output schema reduces the need to explain return values, but more guidance would be helpful for a tool in a set of mathematical operations.
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 0%, so the schema provides no parameter descriptions. The tool description doesn't mention parameters at all, failing to compensate for the coverage gap. However, with only 2 simple parameters (a, b) and an output schema present, the baseline is 3 as the schema defines the structure adequately for this basic operation.
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 '执行浮点数加法运算' (perform floating-point addition operation) clearly states the verb 'addition' and resource 'floating-point numbers'. It distinguishes from siblings like subtract, multiply, and divide by specifying addition, though it doesn't explicitly contrast with them. The purpose is specific and 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 provides no guidance on when to use this tool versus alternatives like subtract or multiply. It states what the tool does but offers no context about appropriate use cases, prerequisites, or comparisons to sibling tools. This leaves the agent without usage direction beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行浮点数除法运算 Args: b: 除数（必须非零）
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| 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 full burden of behavioral disclosure. It mentions that 'b' must be non-zero, which is a critical constraint for division, but doesn't cover other behavioral aspects like error handling (e.g., what happens if b=0), performance characteristics, or return format. For a mathematical tool with zero annotation coverage, this is insufficient.
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 brief with two sentences, but the structure is somewhat awkward with 'Args:' inline. It's front-loaded with the main purpose, but the parameter explanation could be better integrated. It avoids unnecessary verbosity but lacks polish in organization.
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 low complexity (simple division), two parameters, no annotations, and an output schema present (which likely handles return values), the description is mostly complete. It covers the core operation and a key constraint (non-zero divisor), but could improve by explaining 'a' and error scenarios. The output schema reduces the need for return value details.
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 0%, so the description must compensate. It adds semantic meaning by explaining that 'b' is the divisor and must be non-zero, which clarifies beyond the schema's generic 'B' title. However, it doesn't describe 'a' (the dividend), leaving one parameter undocumented. The description partially compensates but not fully for the coverage gap.
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 clearly states the tool's purpose as '执行浮点数除法运算' (perform floating-point division operation), which is a specific verb+resource combination. It distinguishes from siblings like add, multiply, and subtract by specifying division, though it doesn't explicitly contrast with them. The purpose is unambiguous but could be more differentiated.
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 provides no guidance on when to use this tool versus alternatives like multiply or other mathematical operations. It mentions that 'b' must be non-zero, which is a constraint but not usage context. There are no explicit when/when-not instructions or references to sibling tools, leaving the agent to infer usage based on the operation name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算整数阶乘
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes |
| 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. '计算整数阶乘' only states what the tool does, not how it behaves - no information about input constraints (negative numbers, large values), performance characteristics, error handling, or output format. The description is minimal and lacks behavioral context.
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 extremely concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it efficiently 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?
For a simple mathematical function with one parameter and an output schema, the description is minimally adequate. However, it lacks important context about input constraints and behavioral characteristics that would be helpful for an AI agent, especially given the complete absence of annotations.
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?
With 0% schema description coverage for the single parameter 'n', the description doesn't add any parameter-specific information beyond what's implied by the tool name. The schema shows 'n' is a required integer, but the description doesn't clarify valid ranges, constraints, or what happens with edge cases like n=0 or negative n.
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 '计算整数阶乘' (calculates integer factorial) clearly states the verb (calculates) and resource (integer factorial), making the purpose immediately understandable. However, it doesn't distinguish this tool from its mathematical siblings like 'power' or 'multiply' beyond stating it's specifically for factorial calculations.
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 provides no guidance on when to use this tool versus alternatives. While the mathematical operation is clear, there's no mention of when factorial calculation is appropriate compared to other mathematical operations available in the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行浮点数乘法运算
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| 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 full burden of behavioral disclosure. The description only states the operation ('perform floating-point multiplication') without any information about precision, error handling, performance characteristics, or side effects. For a mathematical tool with zero annotation coverage, this is inadequate.
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, efficient sentence ('执行浮点数乘法运算') that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loaded with 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 low complexity (basic arithmetic), the presence of an output schema (which likely defines the return value), and the simple input schema, the description is minimally complete. However, it lacks behavioral context and parameter semantics, which are important even for simple tools, especially with no annotations provided.
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 description coverage is 0%, meaning parameters 'a' and 'b' have no descriptions in the schema. The tool description adds no information about what these parameters represent (e.g., multiplicands, factors) or their expected behavior (e.g., order of operations, handling of special values like NaN or infinity). This fails to compensate for the schema gap.
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 '执行浮点数乘法运算' (perform floating-point multiplication) clearly states the verb ('perform') and resource ('floating-point multiplication'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling tools (add, divide, etc.) beyond the obvious mathematical operation difference, which keeps it from a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'add' or 'divide'. It simply states what the tool does without context about use cases, prerequisites, or comparisons to sibling tools. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算幂运算
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| exponent | Yes |
| 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 full burden of behavioral disclosure. '计算幂运算' only states the operation without any information on error handling, performance, mathematical constraints (e.g., large exponents), or output format. This is inadequate for a tool with no 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?
The description is extremely concise with a single phrase ('计算幂运算'), which is appropriately sized for a simple mathematical tool. It is front-loaded with the core purpose and has zero wasted words.
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 mathematical nature and the presence of an output schema (which handles return values), the description is incomplete. It lacks context on usage, parameters, and behavioral traits, making it insufficient for an agent to fully understand when and how to invoke it correctly.
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 0%, so the schema provides no parameter descriptions. The tool description adds no information about parameters beyond what the schema titles ('Base', 'Exponent') imply. For a tool with 2 parameters and 0% coverage, this is a significant gap.
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 '计算幂运算' (calculates power/exponentiation) states what the tool does with a clear verb+resource, but it doesn't distinguish from siblings like 'factorial' or 'sqrt' which are also mathematical operations. The purpose is understandable but lacks sibling differentiation.
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 like 'multiply' for repeated multiplication or 'sqrt' for square roots. The description offers no context, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算平方根
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes |
| 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. '计算平方根' only states what the tool does, not how it behaves. It doesn't mention error handling (e.g., for negative inputs), performance characteristics, side effects, or output format. This leaves critical behavioral traits undocumented.
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 extremely concise - a single phrase that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's perfectly 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 mathematical simplicity and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema description coverage, it should provide more context about input constraints and behavioral characteristics. The output schema helps, but the description doesn't prepare the agent for potential errors or edge cases.
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 has 0% description coverage, so the description must compensate. '计算平方根' implies a number parameter but adds no semantic meaning beyond what's obvious from the tool name. It doesn't specify constraints (e.g., must be non-negative), units, or typical ranges. The single parameter remains largely undocumented.
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 '计算平方根' (calculate square root) clearly states the tool's function with a specific verb and resource. It distinguishes from siblings like 'add' or 'multiply' by specifying the mathematical operation. However, it doesn't explicitly mention that it operates on a single number parameter, which would make it fully distinct from all siblings.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose sqrt over power (which could also calculate roots) or other mathematical operations. There's no context about input constraints (e.g., non-negative numbers) or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行浮点数减法运算
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| 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 full burden. It states the tool performs floating-point subtraction, which implies a mathematical operation, but doesn't disclose behavioral traits like error handling (e.g., for non-numeric inputs), precision limits, or whether it's read-only or has side effects. The description is minimal and lacks context on how the tool behaves 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, efficient sentence '执行浮点数减法运算' that directly states the tool's purpose. It's appropriately sized for a simple arithmetic tool and front-loaded with the core functionality. There's no wasted text, though it could be slightly more informative without losing conciseness.
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 low complexity (simple subtraction), two parameters with clear schema, and an output schema (implied by 'Has output schema: true'), the description is minimally adequate. However, it lacks details on usage context, error handling, or how it fits with siblings, which would improve completeness. For a basic tool, it meets the minimum but doesn't provide rich contextual information.
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 description adds minimal meaning beyond the input schema. It specifies 'floating-point' subtraction, which implies parameters 'a' and 'b' should be numbers, but the schema already defines them as type 'number'. With 0% schema description coverage, the description doesn't compensate by explaining parameter roles (e.g., minuend and subtrahend) or constraints. Baseline 3 is appropriate as the schema does the heavy lifting with clear property definitions.
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 '执行浮点数减法运算' clearly states the tool performs floating-point subtraction, which is a specific verb+resource combination. It distinguishes from siblings like 'add' and 'multiply' by specifying subtraction rather than other arithmetic operations. However, it doesn't explicitly mention the tool name 'subtract' in the description, keeping it at 4 rather than 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'add' or 'divide', nor does it specify scenarios where subtraction is preferred over other operations. There's no context about input types or constraints beyond 'floating-point', which is implied but not explicitly contrasted with other tools.
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.
adddividefactorialmultiplypowersqrtsubtractScored across 7 tools
Each tool has a clearly distinct mathematical operation: addition, subtraction, multiplication, division, exponentiation, square root, and factorial. There is no overlap in purpose, and an agent can easily select the correct tool based on the desired operation.
All tool names are single, lowercase verbs (e.g., add, subtract, multiply) that directly describe the operation. The naming is perfectly consistent throughout the set, with no deviations in style or pattern.
With 7 tools, this server is well-scoped for a calculator, covering core arithmetic operations (add, subtract, multiply, divide) and common advanced functions (power, sqrt, factorial). Each tool earns its place without being excessive or insufficient for the domain.
The tool set covers essential arithmetic and basic mathematical functions well, but there are minor gaps such as missing trigonometric functions (e.g., sin, cos) or logarithmic operations. However, agents can still perform most common calculator tasks effectively with the provided tools.
Safe scientific calculator MCP for numeric expressions
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
MCPCalc gives agents access to a comprehensive library of calculators spanning finance, math, health, construction, engineering, food, automotive, and more. It includes a full Computer Algebra System (CAS) and a grid-based Spreadsheet calculator.
Calculators accessible via MCP with real-time collaborative sessions and shareable URLs.