Skip to main content
Glama
NVKPAVANKUMAR

Calculator MCP Server

by NVKPAVANKUMAR
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Calculator MCP Server

A small, working Model Context Protocol (MCP) server written in TypeScript.

It exposes five MCP tools:

  • add(a, b)

  • subtract(a, b)

  • multiply(a, b)

  • divide(a, b)

  • square(a)

Prerequisites

  • Node.js 20+

  • npm

Related MCP server: Calculator MCP Server

Install

npm install

Build

npm run build

Run

npm start

The server uses stdio, so it waits for an MCP client. Seeing no normal output is expected.

Server diagnostics are written to stderr because stdout is reserved for MCP protocol traffic.

Development mode

npm run dev

Test with MCP Inspector

Run:

npm run inspect

This starts the MCP Inspector and launches this server through stdio.

In the Inspector:

  1. Connect to the server.

  2. Open the Tools section.

  3. You should see:

    • add

    • subtract

    • multiply

    • divide

    • square

  4. Try add with a=10, b=20.

  5. Expected result: 10 + 20 = 30.

  6. Try square with a=5.

  7. Expected result: 5² = 25.

  8. Try divide with a=10, b=0.

  9. Expected result: an MCP tool error saying division by zero is not allowed.

MCP client configuration

After publishing this package to npm, another user can configure a compatible MCP client using:

{
  "mcpServers": {
    "calculator": {
      "command": "npx",
      "args": ["-y", "sample-calculator-mcp"]
    }
  }
}

For local development, point the client to the local project instead:

{
  "mcpServers": {
    "calculator": {
      "command": "npx",
      "args": ["tsx", "C:\\path\\to\\calculator-mcp\\src\\index.ts"]
    }
  }
}

Use the correct path for your machine.

Publishing to npm

First create an npm account and log in:

npm login

Build:

npm run build

Check what will be published:

npm pack --dry-run

Publish:

npm publish

After publishing, users can run:

npx -y sample-calculator-mcp

Project structure

calculator-mcp/
├── src/
│   └── index.ts
├── package.json
├── tsconfig.json
├── .gitignore
├── README.md
└── LICENSE

How MCP works here

LLM / MCP Host
       |
       v
   MCP Client
       |
      stdio
       |
       v
Calculator MCP Server
       |
   +---+---+---+---+
   |   |   |   |   |
  add sub mul div square

The MCP server exposes tools. The MCP client discovers those tools and sends tool calls. The server executes the calculation and returns the result.

Important

Do not use console.log() for application/debug output in a stdio MCP server. stdout is used by the MCP protocol. Use console.error() for diagnostics.

Available Tools

4 tools
addC

Add two numbers

ParametersJSON Schema
NameRequiredDescriptionDefault
aYes
bYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and says nothing about the return value, numeric precision, overflow behavior, or ordering of operands. For a pure arithmetic function most of this is obvious, but the description adds no behavioral context at all.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single four-word sentence with no filler and the operation front-loaded. It is efficient, though arguably so terse that it under-specifies rather than being optimally sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a trivial two-parameter arithmetic tool with no output schema and no annotations, the description is minimally adequate: an agent can infer the intent. It omits the return value (the sum) and any operand semantics, which are the only remaining gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only says 'two numbers', which loosely maps to the two required params a and b. It does not name, order, or disambiguate them beyond their type, leaving the schema to carry the meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and operands ('Add two numbers'), so the operation is unambiguous. It does not explicitly contrast itself with the siblings multiply/divide/subtract, but the verb alone is distinctive enough for an agent to select correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no mention of the sibling arithmetic tools. The operation is self-evident, but the description provides no routing context whatsoever.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

divideB

Divide the first number by the second number

ParametersJSON Schema
NameRequiredDescriptionDefault
aYes
bYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no behavior for b=0, no statement about return type or floating-point precision, no error semantics. For an unannotated tool this is a notable gap, even if the operation is mathematically simple.

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?

A single, front-loaded sentence with zero filler; operand order is stated first. Nothing can be trimmed without losing the order semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter arithmetic tool with no annotations and no output schema, the description is minimally sufficient but omits the one thing an agent would want to know before invoking it: what happens when the divisor is zero.

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 compensate. It does clarify operand order by labeling the inputs 'first number' and 'second number', which maps implicitly to a and b and is genuinely useful for a non-commutative op. However, it adds no type constraints, formats, or notes on the second parameter being a divisor (non-zero).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific operation (divide) and explicitly maps operand order: first number divided by second. This order matters for a non-commutative operation, so it is more than a restatement of the name. It does not, however, explicitly differentiate itself from the arithmetic siblings, though the name makes the distinction obvious.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus add/subtract/multiply, and no mention of edge conditions such as division by zero. Usage is only implied by the obvious purpose of the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

multiplyA

Multiply two numbers

ParametersJSON Schema
NameRequiredDescriptionDefault
aYes
bYes

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It implies a pure, deterministic arithmetic operation with no side effects, but does not state the return value, error behavior, or any other trait beyond the operation itself. For a trivial pure function this is adequate but minimal.

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?

A single front-loaded sentence with zero waste. Every word earns its place and the operation is stated immediately.

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 trivial two-parameter arithmetic tool with a simple schema and no output schema, the description is nearly sufficient; an agent can call it correctly. It stops short of stating the product/return value, which would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate, but 'two numbers' merely restates the schema's type: number for both a and b. It does not name or otherwise clarify the parameters, adding no semantic value beyond the structured 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 (multiply) and resource (two numbers), making the operation immediately identifiable. It is clearly distinguishable from the sibling tools add, subtract, and divide by naming the multiplication operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no when-to-use guidance, no exclusions, and does not reference the sibling alternatives (add, subtract, divide). Usage is inferable from the universal meaning of multiplication, but nothing explicit is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

subtractA

Subtract the second number from the first number

ParametersJSON Schema
NameRequiredDescriptionDefault
aYes
bYes

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. For a pure arithmetic function there is little to disclose, but the description says nothing about result format, return type, or precision, so it adds no behavioral context beyond the operation name.

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?

A single clause, front-loaded with the verb and containing zero filler. Every word earns its place.

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?

Given a two-parameter, no-annotation, no-output-schema arithmetic tool, the description supplies the one non-obvious fact (operand order) and is complete enough to call correctly. Minor gaps remain around return type/precision, but those are low stakes here.

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?

Schema coverage is 0% and the parameters are named only 'a' and 'b'. The description compensates well by defining the operand order: a minus b, i.e., 'subtract the second number from the first number'. That mapping is the key detail an agent needs and would otherwise have to guess.

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?

States a specific verb (Subtract) and the exact operands and their order ('second number from the first number'). The ordering detail distinguishes it from the ambiguous naming of siblings like divide, and an agent can call it correctly from the description alone.

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 operation is self-evident and the sibling set (add, multiply, divide) makes the choice obvious, so usage is implied rather than stated. There are no exclusions, edge-case notes (e.g., negative results), or explicit routing, which keeps this at the minimum viable level.

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.

  1. 4 tool updatesv1.0.0
    • First observedadd
    • First observeddivide
    • First observedmultiply
    • First observedsubtract
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool performs a single, clearly distinct arithmetic operation with no overlap. An agent can easily tell multiply, divide, add, and subtract apart based on the operation name and description.

Naming Consistency5/5

All tool names are simple, lowercase verbs that directly describe the operation. The naming follows a consistent verb pattern without any deviations.

Tool Count5/5

Four tools is a well-scoped set for a basic calculator server, covering the fundamental arithmetic operations without extraneous tools. Each tool earns its place.

Completeness4/5

The four basic operations cover core arithmetic needs, but a calculator domain typically includes additional operations like exponentiation, square root, or modulo. These are minor gaps that limit some use cases.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

  • MathjsA
    io.github.pipeworx-io

    Math.js MCP — wraps the mathjs.org API (free, no auth)

    Developer Tools
    2
  • arithymAOAuth
    xyz.arithym

    Precision math engine for AI agents. 203 exact methods. Zero hallucination.

    Developer ToolsCode ExecutionAutonomous Agents
    12
  • calculatorsB
    com.calcfleet

    Tested financial & practical calculators as free, no-auth MCP tools for AI agents.

    Finance
    1222
  • SmartMoney77A
    com.smartmoney77

    SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp

    Finance
    141

Related MCP Servers

  • Calculator MCP Server

    snedea
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides basic calculator operations (add, subtract, multiply, divide) as MCP tools for use with Claude Desktop and other MCP clients.
    -

  • Calculator MCP Server

    doudou-fly
    A
    license
    A
    quality
    B
    maintenance
    Provides basic arithmetic operations (add, subtract, multiply, divide) through MCP, enabling AI clients to perform calculations via natural language.
    4
    10 npm
    MIT

  • Calculator

    jyotibasm
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to perform arithmetic operations such as addition, subtraction, multiplication, and division through standardized MCP tools.
    1
    -

  • Calculator MCP Server

    yuntaozhang999
    F
    license
    A
    quality
    C
    maintenance
    Enables AI agents to perform arithmetic operations — addition, subtraction, multiplication, and division with divide-by-zero validation — through MCP tool calls. It can be run locally over stdio or as an HTTP microservice via streamable-http transport.
    4
    -