How do I use Math MCP Server?

1. Click on "Install 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 Solve x^2 - 4 = 0 for x" 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 YasogaN

Overview Schema Related Servers Score Discussions

TypeScript

Local

Click on "Install 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 Solve x^2 - 4 = 0 for x"

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.

@yasogan/math-mcp

$npm version$ $License: MIT$ $Node.js >=18$

A comprehensive Model Context Protocol server that exposes 8 mathematical tools to any MCP-compatible AI agent. Provides arithmetic, symbolic algebra, calculus, matrix operations, statistics, probability distributions, and unit conversions — no code required from the agent side.

Related MCP server: Calculator MCP Server

Installation

Using npx (recommended)

No installation required — run directly:

{
  "mcpServers": {
    "math": {
      "command": "npx",
      "args": ["-y", "@yasogan/math-mcp"]
    }
  }
}

Local installation

npm install -g @yasogan/math-mcp
# or
pnpm add -g @yasogan/math-mcp

Then use directly:

{
  "mcpServers": {
    "math": {
      "command": "@yasogan/math-mcp"
    }
  }
}

Client configuration

Client	Config Location
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json`
OpenCode	`~/.opencode/settings.json`
Zed	`~/.config/zed/settings.json`
Cursor	`~/.cursor/settings.json`

Quick Start

Example prompt to an AI agent:

"What's the determinant of a 3x3 matrix [[1,2,3],[4,5,6],[7,8,9]]?"

The agent will call:

matrix({ op: "determinant", a: [[1,2,3],[4,5,6],[7,8,9]] })

→ Returns 0

Tool Reference

evaluate

Purpose: Evaluate mathematical expressions using either numeric (mathjs) or symbolic (Algebrite) computation.

Parameter	Type	Required	Description
`expression`	string	Yes	The mathematical expression to evaluate
`mode`	`'numeric'` \| `'symbolic'`	No	Default: `'numeric'` — numeric uses mathjs for floating-point, symbolic uses Algebrite for exact results

Numeric mode examples:

// Arithmetic
evaluate({ expression: "2^10 + sqrt(144)" }); // → 1036
evaluate({ expression: "factorial(10)" }); // → 3628800
evaluate({ expression: "gcd(48, 18)" }); // → 6

// Trigonometry
evaluate({ expression: "sin(pi/6)" }); // → 0.5
evaluate({ expression: "cos(45 deg)" }); // → 0.70710678
evaluate({ expression: "atan2(1, 1)" }); // → 0.78539816

// Complex numbers
evaluate({ expression: "(2+3i)*(1-i)" }); // → 5+i
evaluate({ expression: "abs(3+4i)" }); // → 5

// Matrices
evaluate({ expression: "det([[1,2],[3,4]])" }); // → -2
evaluate({ expression: "inv([[2,0],[0,4]])" }); // → [[0.5,0],[0,0.25]]

// BigNumber precision
evaluate({ expression: "bignumber(2)^100" }); // → 1.2676506002282294e30 (exact)

// Units
evaluate({ expression: "180 km/h to m/s" }); // → 50 m/s

Symbolic mode examples:

// Derivatives (symbolic)
evaluate({ expression: "diff(x^3 + 2*x, x)", mode: "symbolic" }); // → 3*x^2+2

// Integrals (symbolic)
evaluate({ expression: "integrate(x^2, x)", mode: "symbolic" }); // → 1/3*x^3

// Simplification
evaluate({ expression: "expand((x+1)*(x-1))", mode: "symbolic" }); // → x^2-1

solve

Purpose: Solve algebraic equations for a specified variable. Returns all roots including complex ones.

Parameter	Type	Required	Description
`equation`	string	Yes	Equation containing exactly one `=` (e.g., `"x^2 - 5x + 6 = 0"`)
`variable`	string	Yes	Variable to solve for (e.g., `"x"`)

Examples:

// Quadratic equation — returns both roots
solve({ equation: "x^2 - 5x + 6 = 0", variable: "x" });
// → { result: "2, 3", numeric: 2, latex: "x = 2, x = 3" }

// Cubic with complex roots
solve({ equation: "x^3 - 1 = 0", variable: "x" });
// → { result: "1, (-0.5)+(-0.8660254037844386*i), (-0.5)+(0.8660254037844386*i)", ... }

// Find specific root
solve({ equation: "x^2 - 4 = 0", variable: "x" });
// → { result: "2, -2", numeric: 2, latex: "x = 2, x = -2" }

Constraints:

Only polynomial equations supported
Exactly one = required
No inequalities (<, >, <=, >=)

simplify

Purpose: Simplify algebraic expressions using mathematical rules (combine like terms, evaluate constants, apply trig identities).

Parameter	Type	Required	Description
`expression`	string	Yes	Expression to simplify

Examples:

simplify({ expression: "sin(x)^2 + cos(x)^2" }); // → 1
simplify({ expression: "2*x + 3*x" }); // → 5*x
simplify({ expression: "3 + 4 * 2" }); // → 11
simplify({ expression: "(x+1)^2 - (x^2 + 2*x + 1)" }); // → 0
simplify({ expression: "exp(ln(x))" }); // → x

factor

Purpose: Factor polynomial expressions into irreducible components.

Parameter	Type	Required	Description
`expression`	string	Yes	Expression to factor

Examples:

factor({ expression: "x^2 - 4" }); // → (x+2)*(x-2)
factor({ expression: "x^3 - 6*x^2 + 11*x - 6" }); // → (x-1)*(x-2)*(x-3)
factor({ expression: "12" }); // → 2^2*3
factor({ expression: "x^2 + 5*x + 6" }); // → (x+2)*(x+3)
factor({ expression: "a^2 - b^2" }); // → (a+b)*(a-b)

expand

Purpose: Expand factored or compound expressions into polynomial form.

Parameter	Type	Required	Description
`expression`	string	Yes	Expression to expand

Examples:

expand({ expression: "(x+1)^3" }); // → x^3+3*x^2+3*x+1
expand({ expression: "(a+b)*(a-b)" }); // → a^2-b^2
expand({ expression: "(x+2)*(x-2)" }); // → x^2-4
expand({ expression: "2*(x+y)" }); // → 2*x+2*y

matrix

Purpose: Perform matrix and vector operations.

Parameter	Type	Required	Description
`op`	string	Yes	Operation name
`a`	number[][]	Yes	First matrix/vector
`b`	number[][]	No	Second matrix/vector (required for binary ops)

Supported operations:

Operation	Description	Requires `b`?
`multiply`	Matrix multiplication A × B	Yes
`add`	Matrix addition A + B	Yes
`subtract`	Matrix subtraction A - B	Yes
`inverse`	Matrix inverse A⁻¹	No
`transpose`	Matrix transpose Aᵀ	No
`determinant`	Determinant \|A\|	No
`eigenvalues`	Eigenvalues of A	No
`eigenvectors`	Eigenvectors of A	No
`rank`	Matrix rank	No
`norm`	Frobenius norm ‖A‖	No
`trace`	Matrix trace	No
`dot`	Dot product of vectors	Yes
`cross`	Cross product of 3D vectors	Yes

Examples:

// Determinant
matrix({
  op: "determinant",
  a: [
    [1, 2],
    [3, 4],
  ],
});
// → -2

// Inverse
matrix({
  op: "inverse",
  a: [
    [4, 7],
    [2, 6],
  ],
});
// → [[0.6,-0.7],[-0.2,0.4]]

// Eigenvalues
matrix({
  op: "eigenvalues",
  a: [
    [2, 1],
    [1, 2],
  ],
});
// → [3, 1]

// Matrix multiplication
matrix({
  op: "multiply",
  a: [
    [1, 2],
    [3, 4],
  ],
  b: [
    [5, 6],
    [7, 8],
  ],
});
// → [[19,22],[43,50]]

// Dot product
matrix({ op: "dot", a: [[1, 2, 3]], b: [[4, 5, 6]] });
// → 32

// Cross product (3D vectors)
matrix({ op: "cross", a: [[1, 0, 0]], b: [[0, 1, 0]] });
// → [0, 0, 1]

Note: SVD is not supported. Use eigenvalues for similar decomposition.

statistics

Purpose: Descriptive statistics, probability distributions, and linear regression.

Parameter	Type	Required	Description
`op`	string	Yes	Operation name
`data`	number[]	Conditional*	Array of numbers (required for descriptive stats & regression)
`args`	object	Conditional*	Distribution parameters (required for distributions)

Descriptive operations (use data):

Operation	Description	Notes
`mean`	Arithmetic mean
`median`	Median value
`mode`	Most frequent value	Returns first if multiple
`std`	Sample standard deviation	Uses n-1 denominator
`variance`	Sample variance	Uses n-1 denominator
`min`	Minimum value
`max`	Maximum value
`sum`	Sum of all values
`quantile`	Quantile value	Requires `args.prob` (default 0.5)
`mad`	Median absolute deviation
`skewness`	Sample skewness	Requires n ≥ 3
`kurtosis`	Sample kurtosis	Requires n ≥ 4

Distribution operations (use args):

Operation	Parameters	Description
`normal_pdf`	`x`, `mean`, `std`	Probability density
`normal_cdf`	`x`, `mean`, `std`	Cumulative distribution
`normal_inv`	`p`, `mean`, `std`	Inverse CDF (quantile)
`binomial_pmf`	`k`, `n`, `p`	Probability mass
`binomial_cdf`	`k`, `n`, `p`	Cumulative distribution
`poisson_pmf`	`k`, `lambda`	Probability mass
`poisson_cdf`	`k`, `lambda`	Cumulative distribution
`t_pdf`	`x`, `df`	Student's t PDF
`t_cdf`	`x`, `df`	Student's t CDF
`chi2_pdf`	`x`, `df`	Chi-squared PDF
`chi2_cdf`	`x`, `df`	Chi-squared CDF

Regression operations (use data):

Operation	Description
`linear_regression`	Simple linear regression (y = mx + b), x auto-indexed as [0,1,2,...]

Examples:

// Descriptive statistics
statistics({ op: "mean", data: [4, 8, 15, 16, 23, 42] }); // → 18

// Standard deviation
statistics({ op: "std", data: [2, 4, 4, 4, 5, 5, 7, 9] });
// → 2.138

// Quantile (75th percentile)
statistics({ op: "quantile", data: [1, 2, 3, 4, 5], args: { prob: 0.75 } });
// → 4

// Normal PDF
statistics({
  op: "normal_pdf",
  args: { x: 0, mean: 0, std: 1 },
});
// → 0.398942

// Normal CDF (probability below z-score)
statistics({
  op: "normal_cdf",
  args: { x: 1.96, mean: 0, std: 1 },
});
// → 0.975

// Inverse normal (find z-score for 97.5th percentile)
statistics({
  op: "normal_inv",
  args: { p: 0.975, mean: 0, std: 1 },
});
// → 1.959964

// Binomial probability (exactly 3 heads in 10 flips)
statistics({
  op: "binomial_pmf",
  args: { k: 3, n: 10, p: 0.5 },
});
// → 0.117188

// Poisson (events in time interval)
statistics({
  op: "poisson_pmf",
  args: { k: 3, lambda: 2 },
});
// → 0.180447

// Linear regression
statistics({
  op: "linear_regression",
  data: [2, 4, 6, 8, 10],
});
// → { slope: 2, intercept: 0 }

units

Purpose: Convert between physical units of the same dimension.

Parameter	Type	Required	Description
`expression`	string	Yes	Format: `'<value> <unit> to <unit>'`

Supported unit categories:

Category	Units
Length	`km`, `m`, `cm`, `mm`, `mi`, `yards`, `ft`, `in`, `nmi`
Mass	`kg`, `g`, `mg`, `lb`, `oz`, `ton`
Temperature	`degC`, `degF`, `K`, `rank`
Pressure	`Pa`, `kPa`, `MPa`, `bar`, `atm`, `psi`
Energy	`J`, `kJ`, `cal`, `kcal`, `Wh`, `kWh`
Speed	`m/s`, `km/h`, `mph`, `knots`, `ft/s`
Area	`m2`, `km2`, `ha`, `acre`, `ft2`, `mi2`
Volume	`L`, `mL`, `gal`, `qt`, `pt`, `cup`, `fl oz`
Time	`s`, `min`, `h`, `day`, `week`, `year`

Examples:

units({ expression: "5 km to miles" }); // → 3.10686 miles
units({ expression: "100 degF to degC" }); // → 37.7778 degC
units({ expression: "1 atm to Pa" }); // → 101325 Pa
units({ expression: "60 mph to km/h" }); // → 96.5606 km/h
units({ expression: "1000 kg to lb" }); // → 2204.62 lb
units({ expression: "1 year to days" }); // → 365.242 days

Expression Syntax Guide

Arithmetic Operators

Symbol	Operation	Example
`+`	Addition	`2 + 3` → 5
`-`	Subtraction	`7 - 4` → 3
`*`	Multiplication	`6 * 8` → 48
`/`	Division	`15 / 3` → 5
`^`	Exponentiation	`2^10` → 1024
`%`	Modulo	`17 % 5` → 2

Functions

sqrt(x); // Square root
abs(x); // Absolute value
log(x); // Natural logarithm
log10(x); // Base-10 logarithm
exp(x); // e^x
factorial(n); // n!
gcd(a, b); // Greatest common divisor
lcm(a, b); // Least common multiple
floor(x); // Round down
ceil(x); // Round up
round(x); // Round to nearest

Trigonometry

(sin(x), cos(x), tan(x)); // Standard functions
(asin(x), acos(x), atan(x)); // Inverses
atan2(y, x); // Two-argument atan
(sinh(x), cosh(x), tanh(x)); // Hyperbolic
(deg, rad); // Unit conversion

Constants

pi; // 3.14159...
e; // 2.71828...
i; // Imaginary unit

Special Values

(Infinity, -Infinity);
NaN;

Development

# Install dependencies
pnpm install

# Build TypeScript
pnpm build

# Run tests
pnpm test

# Run in development (no build required)
pnpm dev

# Run in development with watch
pnpm test:watch

Tech stack: TypeScript, MCP SDK, mathjs, Algebrite, Vitest

License

MIT

Available Tools

8 tools

evaluateA

Evaluates any mathematical expression using mathjs. Supports arithmetic, trigonometry (sin, cos, tan, pi, e), algebra, calculus (derivative, integrate), complex numbers (2+3i), fractions, BigNumber precision (bignumber()), matrices (det, inv, transpose), logic, and units. Use mode='symbolic' for exact symbolic results via Algebrite. Examples: '2^10', 'sin(pi/4)', 'det([[1,2],[3,4]])', 'derivative("x^3", "x")', 'integrate(x^2, x, 0, 1)'

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	The mathematical expression to evaluate
`mode`	No	Evaluation mode: numeric (default, uses mathjs) or symbolic (uses Algebrite)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the underlying libraries (mathjs, Algebrite) and mode behavior (numeric vs symbolic). However, it omits error handling, output format, side effects, or permission requirements. For a computation tool, the description is adequate but not fully transparent.

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, well-structured paragraph that front-loads the core function ('Evaluates any mathematical expression using mathjs'), then lists supported operations, introduces the symbolic mode, and provides illustrative examples. Every sentence adds value without redundancy.

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?

Given the tool's complexity and absence of output schema, the description is moderately complete. It covers capabilities and modes but fails to specify the return format (e.g., numeric value, string, object) or error behavior. For a tool with extensive functionality like calculus and matrices, this is a notable gap.

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 100%, so baseline is 3. The description adds significant value by providing concrete examples and listing supported expression types (e.g., 'det([[1,2],[3,4]])'), which goes beyond the schema's basic description of 'expression' as a string. The mode parameter is further clarified with defaults and library names.

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 evaluates mathematical expressions using mathjs, with specific verb 'Evaluates' and resource 'mathematical expression'. The comprehensive list of supported operations (arithmetic, trigonometry, calculus, etc.) effectively distinguishes it from sibling tools like expand or factor, which handle specific transformations.

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 does not explicitly state when to use this tool versus alternatives. It implies general applicability with 'any mathematical expression' but lacks explicit when-not-to-use guidance or comparison with sibling tools. The mode parameter is explained, but no exclusions are provided.

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

expandB

Expands a factored or compound expression using Algebrite. Examples: '(x+1)^3', '(a+b)(a-b)', '(x+2)(x-2)'

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations, and description only mentions using Algebrite and gives examples. Omits behavioral details like error handling, unsupported expressions, or performance 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?

Single sentence with examples; concise and front-loaded. No wasted words.

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?

Adequate for a simple 1-param tool with no output schema, but lacks error conditions, input validation hints, or output description.

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 coverage is 0%, and description provides only examples, not explicit semantics for the 'expression' parameter beyond being a string. Doesn't specify valid formats or constraints.

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?

Clearly states it expands factored or compound expressions using Algebrite, with examples that distinguish it from siblings like factor and simplify.

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?

No explicit when-to-use or when-not-to-use guidance. Examples imply usage for algebraic expansion, but doesn't contrast with sibling tools like factor or simplify.

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

factorA

Factors a polynomial expression using Algebrite. Returns the factored form. Examples: 'x^2 - 4' → '(x+2)(x-2)', 'x^3 - 6x^2 + 11*x - 6', '12' → prime factorization

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description discloses the use of Algebrite, returns factored form, and gives behavioral insight via examples (including prime factorization for constants). It doesn't mention error handling for invalid inputs, but overall is transparent.

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 concise: two sentences plus a list of examples. The purpose is front-loaded, though examples could be integrated more seamlessly.

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 single-parameter tool with no output schema or annotations, the description explains functionality and provides examples. It is fairly complete but missing error cases or constraints on input format.

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 coverage is 0% and the description only provides examples as parameter hints. It does not formally describe what the expression parameter should contain (e.g., 'a valid polynomial string') beyond examples.

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 factors polynomial expressions and provides concrete examples distinguishing it from siblings like simplify and expand. The verb 'factors' and resource 'polynomial expression' are specific.

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?

Usage is implied through examples and sibling names, but no explicit when-to-use or when-not-to-use guidance is given. For instance, it doesn't differentiate from simplify for factoring tasks.

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

matrixC

Performs matrix operations. Ops: multiply, add, subtract, inverse, transpose, determinant, eigenvalues, eigenvectors, rank, norm, trace, cross (3D vectors), dot (vectors). SVD is not currently supported. Binary ops (multiply/add/subtract) require both 'a' and 'b'. Inputs are 2D number arrays. Examples: op='determinant', a=[[1,2],[3,4]]

ParametersJSON Schema

Name	Required	Description	Default
`op`	Yes
`a`	Yes
`b`	No

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It states inputs are 2D number arrays and lists ops, but does not describe output format, error handling, shape constraints, or side effects. For example, it doesn't clarify that some ops may return complex numbers. Minimal disclosure beyond schema.

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 concise with two sentences and an example. It front-loads the purpose, then lists ops, mentions unsupported SVD, and gives input requirements. Well-structured and no wasted words.

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?

Given the complexity of multiple ops and no output schema, the description provides a reasonable overview but lacks details on return values, constraints (e.g., square matrices for determinant), and error conditions. It is adequate but incomplete.

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 description must explain parameters. It clarifies that inputs are 2D number arrays and that binary ops require both 'a' and 'b'. It also lists op values and gives an example. However, it does not explain what each operation does in detail, leaving some ambiguity.

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 'Performs matrix operations' and lists many specific operations (multiply, add, etc.). It distinguishes itself from sibling math tools (evaluate, simplify, solve) by focusing on matrix operations. However, it could be more explicit that this tool is exclusively for matrix operations.

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 tool vs. alternatives like 'solve' or 'statistics'. It mentions that SVD is not supported and binary ops require both 'a' and 'b', but does not compare with siblings or provide context for choosing this tool.

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

simplifyA

Simplifies a mathematical expression using mathjs rules. Combines like terms, applies trig identities (sin²+cos²=1), and reduces constants. Examples: 'sin(x)^2 + cos(x)^2', '2x + 3x', '3 + 4 * 2'

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; description does not disclose error handling, input restrictions, or domain boundaries beyond stating 'mathjs rules' and giving examples.

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?

Concise three sentences with front-loaded main action and helpful examples, but could be slightly more structured.

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?

Adequate for a simple tool with one parameter and no output schema; covers purpose and examples, but lacks edge cases or error info.

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?

Only one parameter 'expression' with 0% schema coverage; examples add context but no formal description of expected format or constraints.

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?

Clearly states it simplifies mathematical expressions using mathjs rules, with specific actions (combine like terms, trig identities, reduce constants) and examples that distinguish it from siblings like expand and factor.

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?

Implies when to use (when simplification is needed) via examples, but does not explicitly state when not to use or compare to sibling tools like expand or factor.

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

solveA

Solves an equation for a variable. Format equation as 'lhs = rhs' (e.g. 'x^2 - 4 = 0'). Returns all solutions including complex ones. Examples: 'x^2 - 4 = 0' with variable 'x', 'x^3 - 6x^2 + 11x - 6 = 0' with variable 'x'

ParametersJSON Schema

Name	Required	Description	Default
`equation`	Yes	Equation string containing '=', e.g. 'x^2 - 4 = 0'
`variable`	Yes	The variable to solve for, e.g. 'x'

TDQS

A4.2/5.0

Behavior3/5

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

Despite no annotations, the description discloses that it returns 'all solutions including complex ones', which is useful. However, it lacks details on error handling (e.g., unsolvable equations) or performance traits.

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 concise with only two sentences plus examples. It front-loads the main purpose and uses minimal words to convey necessary 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 no output schema and no annotations, the description adequately explains the parameters and output behavior. It could be slightly more complete by mentioning what happens for equations with no solutions, but overall sufficient.

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 already describes both parameters with 100% coverage. The description adds value by providing examples and specifying the expected format for the equation string.

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 'Solves an equation for a variable' which is a specific verb+resource. It distinguishes from sibling tools like simplify, factor, etc., which perform different algebraic operations.

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 explicit format requirements ('lhs = rhs') and two examples, making it clear how to use the tool. It does not explicitly state when not to use it, but the context is clear given the sibling tools.

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

statisticsA

Computes descriptive statistics and probability distributions. Descriptive ops use 'data' array: mean, median, mode, std, variance, min, max, sum, quantile (needs args.prob), mad, skewness (n≥3), kurtosis (n≥4). Distribution ops use 'args': normal_pdf/cdf/inv, binomial_pmf/cdf, poisson_pmf/cdf, t_pdf/cdf, chi2_pdf/cdf. Also: linear_regression (uses 'data' as y-values and auto-indexes x as [0,1,2,...,n-1]). Args vary by op — e.g. normal_pdf needs {x, mean, std}, binomial_pmf needs {k, n, p}

ParametersJSON Schema

Name	Required	Description	Default
`op`	Yes
`data`	No
`args`	No

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, and the description does not mention side effects, error handling, or return behavior. For a computational tool, this is acceptable but minimal; basic transparency about potential errors or output format is missing.

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 dense but efficient, front-loading the overall purpose. Every sentence adds value, though it could be broken into sections for readability. It is not excessively long.

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?

The description lacks specification of return values or output format. For 'linear_regression', it mentions input but not output. Given the complexity of operations and no output schema, more completeness is needed, though many ops have implied returns.

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?

The input schema has 0% parameter descriptions, but the description adds significant meaning: it explains each op, what 'data' and 'args' are used for, and specific constraints for many operations (e.g., 'normal_pdf needs {x, mean, std}'). This fully compensates for the missing schema descriptions.

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 that the tool computes descriptive statistics and probability distributions, listing all operations with their required parameters. It distinguishes between two categories (descriptive ops using 'data' and distribution ops using 'args'), and the op enum is exhaustive.

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 per operation, including constraints like 'quantile needs args.prob' and 'skewness needs n≥3'. However, it does not explicitly state when to avoid this tool or name alternatives, though sibling tools are different domains.

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

unitsA

Converts between units. Format: ' to '. Supported: length (km, miles, m, ft, in), mass (kg, lb, g, oz), temperature (degC, degF, K), pressure (Pa, atm, bar, psi), energy (J, kWh, cal), speed (km/h, mph, m/s), area (m^2, acre, ft^2). Examples: '5 km to miles', '100 degF to degC', '1 atm to Pa'

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	Format: '<value> <unit> to <unit>', e.g. '5 km to miles'

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description fully carries the burden. It explains the supported unit categories and format but does not mention error handling, return format, or behavior for invalid 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 one well-structured paragraph with no extraneous information. It includes the purpose, format, supported categories, and examples concisely.

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 tool with one parameter and no output schema, the description is complete. It covers what the tool does, how to use it, and what units are supported.

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 single parameter 'expression' is described in the schema. The tool description adds value by providing the format, examples, and supported units, which go beyond the schema's brief description.

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 'Converts between units' and specifies the exact format and supported unit categories. This distinguishes it from sibling tools like 'solve' or 'simplify' which perform different mathematical operations.

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 the required format and examples, making it clear when to use this tool. However, it does not explicitly state when not to use it or compare to alternatives beyond listing siblings.

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.

8 tool updatesv0.1.1Jun 18, 2026
- First observedevaluate
- First observedexpand
- First observedfactor
- First observedmatrix
- First observedsimplify
- First observedsolve
- First observedstatistics
- First observedunits

Install Server

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

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have distinct purposes: evaluate for general evaluation, expand for expansion, factor for factoring, etc. However, evaluate is quite broad and could be confused with simplify or expand for certain expressions, though descriptions mitigate this.

Naming Consistency3/5

Tool names are all single words but lack a consistent pattern: some are verbs (evaluate, expand, factor, simplify, solve), while others are nouns (matrix, statistics, units). The naming is readable but not uniform.

Tool Count5/5

With 8 tools covering arithmetic, algebra, matrices, statistics, and unit conversion, the count feels well-scoped for a math server. Each tool serves a clear purpose without redundancy.

Completeness4/5

The tool set covers core mathematical operations including symbolic manipulation, matrix operations, statistics, and units. Minor gaps exist, such as no dedicated tool for solving systems of equations or advanced calculus like limits, but agents can often work around these using existing tools.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Aman-Amith-Shastry-scientific_computation_mcpOAuth
ai.smithery
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Research & Data
22
Math MCP Learning A
io.github.clouatre-labs
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Education & Learning Tools Research & Data Developer Tools
1725
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
arithym AOAuth
xyz.arithym
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Developer Tools Code Execution Autonomous Agents
2

Related MCP Servers

Math-MCP
Code Execution Developer Tools
EthanHenrickson
A
license
A
quality
C
maintenance
A Model Context Protocol server that provides basic mathematical and statistical functions to LLMs, enabling them to perform accurate numerical calculations through a simple API.
Updated 3 months ago (2026-05-30 16:32 UTC)
13
37
174
MIT
Calculator MCP Server
Developer Tools
Sathiya-Moorthi
A
license
Not graded
quality
D
maintenance
A Python-based MCP server that provides a suite of basic arithmetic tools, including addition, square roots, and percentage calculations, for AI assistants. It enables models to perform precise mathematical operations through the Model Context Protocol.
Updated 8 months ago (2026-01-18 18:44 UTC)
MIT
MCP Mathematics
Developer Tools Data Platforms
SHSharkar
A
license
C
quality
C
maintenance
A comprehensive MCP server that turns any AI assistant into a powerful mathematical computation engine, providing 52 advanced functions, 158 unit conversions, financial calculations, and secure AST-based evaluation.
Updated a year ago (2025-10-18 12:42 UTC)
18
13
MIT
SharkMath MCP
Developer Tools AI & Machine Learning
tonygod
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server providing 150+ mathematical functions across arithmetic, trigonometry, statistics, unit conversions, and more, consolidated into 15 powerful tools for seamless integration with VS Code Copilot and other MCP-compatible clients.
Updated a year ago (2025-07-22 00:11 UTC)
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/YasogaN/math-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@yasogan/math-mcp

Contents

Installation

Using npx (recommended)

Local installation

Client configuration

Quick Start

Tool Reference

evaluate

solve

simplify

factor

expand

matrix

statistics

units

Expression Syntax Guide

Arithmetic Operators

Functions

Trigonometry

Constants

Special Values

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API