What can you do with this server?

The Math MCP Server performs mathematical operations with 64-bit precision and integrates with development environments like Claude Desktop, VS Code, and Cursor. Core Operations: * Basic Arithmetic: Addition (list of numbers), subtraction, multiplication (list of numbers), and division - all supporting fractions and positive/negative numbers * Matrix Multiplication: Multiplies two matrices (as nested lists) with compatible dimensions, supporting fractions as elements Key Features: * 64-bit floating point precision for all calculations * Fast dependency management using uv * Unit testing with Pytest for reliability * Easy integration across multiple development environments

How do I use Math MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Math MCP Server multiply 15 by 3.5" 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.

Math MCP Server

by avanishd-3

Overview Schema Source Related Servers Discussions Admin

Python

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., "@Math MCP Server multiply 15 by 3.5"

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.

Math MCP Server

Overview

This is an MCP (Model Context Protocol) server that can do basic arithmetic in 64 bit precision, along with matrix multiplication.

Related MCP server: Calculator MCP Server

Features

Addition
Subtraction
Multiplication
Division
Matrix multiplication

Installation

Prerequisities

Ensure you have the following installed:

Python 3.13+
uv

Installing UV

See installation guide for all options.

Unix/MacOS

curl -LsSf https://astral.sh/uv/install.sh | sh

brew install uv

Windows

winget install --id=astral-sh.uv  -e

Clone the Repository

git clone https://github.com/avanishd-3/math-mcp.git
cd math-mcp-server
uv sync

Integration with Clients

Claude Code

fastmcp install claude-code src/math_server.py:math_mcp

Claude Desktop

fastmcp install claude-desktop src/math_server.py:math_mcp

Cursor

fastmcp install cursor src/math_server.py:math_mcp

VS Code

Add the following .vscode/mcp.json and use your actual path.

{
  "servers": {
    "Math MCP Server": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "fastmcp",
        "--with",
        "numpy",
        "fastmcp",
        "run",
        "/absolute/path/Desktop/to/math-mcp-server/src/math_server.py:math_mcp"
      ]
    }
  },
}

Contributing

Fork the repository
Create a new branch:

git checkout -b add-feature

Make changes and commit (remember to add unit tests in test/ directory)

git commit -m "Added a new feature"

Push to your fork

git push origin add-feature

Open a pull request.

Project Structure

/
├── src
│   └── math_server.py
├── tests
│   ├── test_arithmetic.py
│   │   └── astro.svg
│   ├── test_linear_algebra.py
├── pytest.ini
├── pyproject.toml
└── uv.lock

Architecture

This MCP server uses Fast MCP 2.0, which provides many more features than Fast MCP 1.0, which is what the official Python SDK for MCP uses.

Also, the unit tests are written with Pytest, which is what Fast MCP 2.0 recommends.

Lastly, if you don't know, uv is a much faster version of pip that also provides a lockfile for project dependencies (this will be familiar if you've used npm or cargo before). The MCP Python SDK itself uses uv, and I use it for all new Python projects, because it's 10-100x faster than pip, and the lockfile makes dependency version management much simpler.

Available Tools

5 tools

addA

Adds a list of positive and/or negative numbers with 64 bit floating point precision and returns a 64 bit float. You need to provide them in the format of a list. For example, [1, 2, 3] would return 6.0. You can also use fractions if you want to, like [1/2, 1/3, 1/4].

ParametersJSON Schema

Name	Required	Description	Default
`numbers`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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. It does disclose key behavioral traits: the tool accepts both positive and negative numbers, uses 64-bit floating point precision, returns a 64-bit float, and accepts fractions. However, it doesn't mention error handling (e.g., what happens with non-numeric inputs), performance characteristics, or any limitations beyond the precision specification. The description doesn't contradict any annotations since none exist.

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 perfectly sized and front-loaded: the first sentence states the core functionality, and subsequent sentences provide essential examples and clarifications. Every sentence earns its place by adding value—none are redundant or unnecessary. The structure flows logically from general operation to specific examples.

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 the tool's low complexity (single parameter, no nested objects) and the presence of an output schema (which handles return value documentation), the description is mostly complete. It covers the purpose, usage, parameter semantics, and behavioral aspects adequately. However, it could be more complete by mentioning error cases or edge behaviors, which would be helpful despite the output schema's existence.

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?

The schema description coverage is 0%, so the description must compensate. It adds substantial meaning beyond the bare schema: it explains that the 'numbers' parameter should be 'a list of positive and/or negative numbers,' provides format examples ('[1, 2, 3]'), mentions support for fractions, and clarifies the 64-bit floating point precision. While it doesn't explicitly document every aspect of the parameter (like the 'anyOf' schema detail), it provides enough practical guidance for effective use.

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 tool's purpose: 'Adds a list of positive and/or negative numbers with 64 bit floating point precision and returns a 64 bit float.' This specifies the exact verb ('adds'), resource ('list of numbers'), and distinguishes it from sibling tools like 'subtract' or 'multiply' by focusing on addition. The description goes beyond just restating the name by explaining the operation and data types involved.

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 provides clear context for when to use this tool: for adding numbers in a list format with 64-bit floating point precision. It gives examples like '[1, 2, 3]' and '[1/2, 1/3, 1/4]' to illustrate proper usage. However, it doesn't explicitly state when NOT to use it or mention alternatives (like using 'subtract' for subtraction operations), which prevents a perfect score.

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

divideA

Divides two numbers with 64 bit floating point precision and returns a 64 bit float. For example, dividing 10 by 2 would return 5.0. You can also use fractions if you want to, like 1/2 for number_1 and 1/3 for number_2.

ParametersJSON Schema

Name	Required	Description	Default
`number_1`	Yes
`number_2`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the precision (64-bit floating point) and return type, which are useful behavioral traits. However, it does not cover error handling (e.g., division by zero), performance aspects, or other constraints, leaving gaps in 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.

Conciseness4/5

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

The description is appropriately sized with three sentences that are front-loaded: the first states the core functionality, the second gives an example, and the third adds flexibility. There is minimal waste, though the fraction example could be slightly more concise.

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 the tool's low complexity, two parameters with 0% schema coverage, and the presence of an output schema (which handles return values), the description is fairly complete. It covers purpose, parameters, and behavior adequately, though it lacks usage guidelines and some behavioral details like error handling.

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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that parameters are numbers used for division, provides examples (e.g., 10 and 2, fractions like 1/2), and clarifies they can be integers or numbers. This effectively documents the parameters beyond 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 clearly states the specific verb 'divides' and resource 'two numbers', distinguishing it from sibling tools like add, multiply, and subtract by specifying the division operation. It also mentions the precision and return type, making the purpose explicit and distinct.

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 provides no guidance on when to use this tool versus alternatives like multiply or subtract, nor does it mention any prerequisites or exclusions. It includes an example but lacks context for tool selection.

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

matrix_multiplicationA

Multiplies two matrices with 64 bit floating point precision and returns the result as a matrix. You need to provide them in the format of nested lists. For example, [[1, 2], [3, 4]] would represent a 2x2 matrix. Each sub list represents a row in the matrix, and each element in the sub list represents a column. The matrices must be compatible for multiplication, meaning the number of columns in the first matrix must equal the number of rows in the second matrix. You can also use fractions for individual elements if you want to, like [1/2, 1/3, 1/4].

ParametersJSON Schema

Name	Required	Description	Default
`matrix_1`	Yes
`matrix_2`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: precision ('64 bit floating point'), return format ('result as a matrix'), input format requirements ('nested lists'), and compatibility constraints. It doesn't mention error handling, performance limits, or side effects, but covers essential operational behavior adequately.

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?

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: operation definition, format specification, compatibility rule, and data type flexibility. It could be slightly more structured but avoids redundancy and stays focused on essential information.

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 the mathematical complexity, 0% schema coverage, and presence of an output schema (which handles return values), the description is quite complete. It covers purpose, input format, constraints, and data types. It doesn't explain edge cases or error responses, but for a tool with output schema and clear mathematical operation, this is sufficient.

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%, so the description must compensate fully. It explicitly explains both parameters: 'matrix_1' and 'matrix_2' are described as matrices in nested list format with detailed examples and formatting rules. It adds crucial meaning beyond the bare schema, including data types (integers, numbers, fractions), structure (rows/columns), and validation rules (compatibility).

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 specific action ('multiplies two matrices') and resource ('matrices'), distinguishing it from sibling tools like 'add', 'subtract', 'multiply' (scalar), and 'divide' by specifying matrix multiplication. It goes beyond just restating the name by detailing the operation and output format.

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 usage through the compatibility requirement ('matrices must be compatible for multiplication'), but doesn't explicitly state when to use this tool versus alternatives like scalar 'multiply' or other matrix operations. It provides necessary context for correct invocation but lacks explicit guidance on tool selection among siblings.

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

multiplyA

Multiplies a list of positive and/or negative numbers with 64 bit floating point precision and returns a 64 bit float. You need to provide them in the format of a list. For example, [1, 2, 3] would return 6.0. You can also use fractions if you want to, like [1/2, 1/3, 1/4].

ParametersJSON Schema

Name	Required	Description	Default
`numbers`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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 discloses key behavioral traits: it handles positive/negative numbers, uses 64-bit floating point precision, returns a 64-bit float, and accepts fractions. However, it lacks details on error handling (e.g., empty lists, non-numeric inputs) or performance aspects, which could be useful for an agent.

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 appropriately sized and front-loaded: the first sentence states the core functionality, followed by practical usage details. Every sentence earns its place by adding value—no redundant or vague information. It's efficient and well-structured for quick comprehension.

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 the tool's low complexity, one parameter, and an output schema (which handles return values), the description is mostly complete. It covers purpose, usage, and parameter semantics adequately. However, it could benefit from mentioning edge cases or linking to sibling tools for more advanced operations, slightly reducing completeness.

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?

The input schema has 0% description coverage, so the description must compensate. It adds significant meaning beyond the schema: it explains that the parameter 'numbers' should be a list, provides format examples (e.g., [1, 2, 3]), and clarifies that fractions are allowed. This effectively documents the single parameter, though it could specify constraints like minimum list length.

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 tool's purpose: multiplying a list of numbers with 64-bit floating point precision and returning a 64-bit float. It specifies the verb ('multiplies'), resource ('list of positive and/or negative numbers'), and distinguishes from siblings like 'add', 'divide', 'matrix_multiplication', and 'subtract' by focusing exclusively on multiplication.

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 provides clear context for when to use this tool: for multiplying numbers in a list format. It implies usage by specifying the input format and examples, but does not explicitly state when not to use it or name alternatives like 'matrix_multiplication' for matrix operations, leaving some room for improvement in sibling differentiation.

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

subtractB

Subtracts two numbers with 64 bit floating point precision and returns a 64 bit float. For example, subtracting 5 from 10 would return 5.0. You can also use fractions if you want to, like 1/2 for number_1 and 1/3 for number_2.

ParametersJSON Schema

Name	Required	Description	Default
`number_1`	Yes
`number_2`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the precision (64-bit floating point) and return type, which is helpful. However, it doesn't mention error handling (e.g., for invalid inputs), performance characteristics, or side effects. The example adds some clarity but doesn't fully cover behavioral traits.

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?

The description is appropriately sized with three sentences. The first sentence states the core purpose, the second provides an example, and the third adds fraction support. There's minimal redundancy, and information is front-loaded, though the fraction note could be integrated more smoothly.

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 the tool's low complexity (basic arithmetic), two parameters with 0% schema coverage, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the operation, precision, and input types via examples, though it lacks explicit parameter definitions and usage guidelines.

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 implies that parameters are numbers (via the example and fraction mention) but doesn't explicitly define 'number_1' and 'number_2' or their roles (e.g., minuend and subtrahend). The fraction example adds some meaning but doesn't fully document the two parameters beyond what's inferred from the tool name.

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?

The description clearly states the tool's purpose: 'Subtracts two numbers with 64 bit floating point precision and returns a 64 bit float.' This specifies the verb (subtracts), resource (two numbers), and precision details. It distinguishes from siblings like 'add' and 'divide' by focusing on subtraction, though it doesn't explicitly contrast with them.

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 provides no guidance on when to use this tool versus alternatives like 'add' or 'multiply'. It includes an example and mentions fractions, but these are usage examples rather than contextual guidelines for tool selection. There's no mention of prerequisites or exclusions.

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.

5 tool updatesAug 15, 2025
- First observedadd
- First observeddivide
- First observedmatrix_multiplication
- First observedmultiply
- First observedsubtract

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-04-18 09:00 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct mathematical operation: addition, division, matrix multiplication, multiplication, and subtraction. There is no overlap in purpose—add and multiply handle lists for their respective operations, while divide and subtract handle two numbers, and matrix_multiplication is uniquely for matrices. An agent can easily tell them apart based on their specific functions.

Naming Consistency5/5

All tool names follow a consistent verb-based pattern (add, divide, matrix_multiplication, multiply, subtract) without mixing conventions. The naming is straightforward and predictable, using simple action words that directly describe the operation, with matrix_multiplication as a compound term that still fits the verb_noun style.

Tool Count4/5

With 5 tools, the count is reasonable for a math server covering basic arithmetic and matrix operations. It is well-scoped, but slightly under for a comprehensive math toolkit, as it lacks tools for operations like exponentiation, trigonometry, or advanced linear algebra, which might be expected in a broader math domain.

Completeness3/5

The tool set covers basic arithmetic (add, subtract, multiply, divide) and matrix multiplication, but there are notable gaps for a math server. Missing operations include exponentiation, square roots, trigonometric functions, and other matrix operations (e.g., inversion, determinant), which limits the surface for handling common mathematical tasks and could lead to agent workarounds.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

arithym AOAuth
xyz.arithym
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Developer Tools Code Execution Autonomous Agents
12
precisioncalc-mcp B
io.github.inity13
High-precision finance & business calculations for AI agents — exact decimals, never floats.
Finance
111
Inferventis MCP Server A
ai.bankee
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
Finance Cryptocurrency
202
metamodel A
io.github.joegra2003
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Developer Tools AI & Machine Learning
42

Related MCP Servers

Calculator MCP Server
Developer Tools Code Execution
mzdz
F
license
Not graded
quality
D
maintenance
Provides basic arithmetic operations and advanced mathematical functions through the Model Context Protocol (MCP), with features like calculation history tracking and expression evaluation.
Updated a year ago (2025-06-07 02:22 UTC)
1
-
Calculator MCP Server
Code Execution Developer Tools
functicons
A
license
Not graded
quality
D
maintenance
A backend service that provides accurate arithmetic calculation capabilities to AI models via the Model Context Protocol, allowing LLMs to offload mathematical computations for numerical queries.
Updated a year ago (2025-06-12 03:35 UTC)
1
MIT
Calculator MCP
BACH-AI-Tools
A
license
B
quality
D
maintenance
Provides mathematical computation capabilities including basic arithmetic operations (add, subtract, multiply, divide), advanced functions (square root, factorial, logarithm), and trigonometric functions (sin, cos, tan) through the Model Context Protocol.
Updated 9 months ago (2025-12-04 05:35 UTC)
5
MIT
Simple Calculator MCP
SanLangLOVE
F
license
A
quality
D
maintenance
Provides basic mathematical operations including addition, subtraction, multiplication, division, and power calculations through a Model Context Protocol interface.
Updated a year ago (2025-09-03 09:52 UTC)
5
1
-