The Math MCP server exposes 7 mathematical tools for use in Claude integrations, with security, caching, and optional observability built in.
Evaluate (evaluate): Compute arithmetic/algebraic expressions with optional variable bindings (e.g., x^2 + 2*x with {x: 5}).
Simplify (simplify): Symbolically simplify algebraic expressions (e.g., 2*x + x → 3*x), with optional custom rules.
Derivative (derivative): Compute symbolic derivatives with respect to a variable (e.g., x^2 → 2*x).
Solve (solve): Find exact roots for polynomials up to degree 3, or numeric roots for higher-degree/transcendental equations.
Matrix Operations (matrix_operations): Multiply, add, subtract, inverse, determinant, transpose, and eigenvalues on JSON-encoded matrices.
Statistics (statistics): Compute mean, median, mode, std, variance, min, max, sum, and product over a dataset.
Unit Conversion (unit_conversion): Convert between units of length, temperature, speed, and more (e.g., 100 fahrenheit → celsius).
Security: Expression sandboxing, input/size limits (max matrix dimension, array length, nesting depth), and token-bucket rate limiting.
Performance: LRU cache for parsed/evaluated expressions, Prometheus metrics, and Kubernetes-style health probes.
Exports metrics in Prometheus format for monitoring operations, performance, and health of the math MCP server.
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 calculate the derivative of x^2 + 3x - 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.
A secure, production-ready MCP (Model Context Protocol) server exposing seven mathematical tools — expression evaluation, symbolic calculus (derivative, simplify), equation solving, matrix algebra, statistics, and unit conversion.
Computation is powered by MathTS
(@danielsimonjr/mathts-*), a TypeScript computer-algebra engine with a
mathjs-compatible API. The server layers input validation, expression
sandboxing, rate limiting, and Prometheus/health observability on top of it.
Engine note (v4): As of v4.0.0 the compute engine is MathTS, not mathjs. The tool I/O contracts are unchanged; only the internals differ. The earlier multi-tier acceleration stack (WASM / WebWorkers / WebGPU) was removed in the v4 cutover — MathTS handles its own internal dispatch, and large-input safety is enforced by size limits rather than a fallback chain. See CHANGELOG.md.
The plugin also ships a math skill (math-mcp:math, /math) — a playbook
that steers Claude to offload computation to these tools instead of doing
mental math, with composed workflows for solving, calculus, matrices,
statistics, and units. See skills/math/SKILL.md.
Related MCP server: SymPy Sandbox MCP
evaluate — evaluate expressions, with optional variables (scope)
simplify — symbolic simplification of algebraic expressions
derivative — symbolic differentiation
solve — solve equations for a variable
matrix_operations — multiply, inverse, determinant, transpose, eigenvalues, add, subtract
statistics — mean, median, mode, std, variance, min, max, sum, product
unit_conversion — convert a value between units
Expression sandboxing: AST validation blocks code injection, dangerous functions, and assignments (src/validation.ts).
Input & size limits: length, nesting-depth, matrix-dimension, and array-length caps prevent resource exhaustion. Oversized inputs are rejected up front (synchronous JS can't be interrupted, so protection is by size limit, not timeout).
Rate limiting: token-bucket limiter with configurable per-window, concurrency, and queue limits (src/rate-limiter.ts).
Expression cache: LRU cache for parsed/evaluated expressions (src/expression-cache.ts).
Observability (optional): set ENABLE_TELEMETRY=true to start an HTTP endpoint (default port 9090, src/telemetry/) exposing Prometheus metrics and Kubernetes-style health probes: GET /metrics, GET /health, GET /health/live, GET /health/ready.
// Matrix operations — matrices are JSON strings
matrix_operations("determinant", "[[1,2],[3,4]]") // -2
matrix_operations("multiply", "[[1,2],[3,4]]", "[[5,6],[7,8]]") // [[19,22],[43,50]]
// Statistics — data is a JSON string; mode returns an array
statistics("mean", "[1,2,3,4,5]") // 3
statistics("mode", "[1,2,2,3,4]") // [2]
// Symbolic math
derivative("x^2", "x") // "2 * x"
simplify("2 * x + x") // "3 * x"
// Unit conversion (use compound forms like mi/h — not mph)
unit_conversion("5 inches", "cm") // "12.7 cm"Bun ≥ 1.4.0 — install/script toolchain (bun.lock is authoritative)
Node.js ≥ 22.0.0 — shipped MCP runtime (node dist/index.js)
Platform: Windows, macOS, or Linux
git clone https://github.com/danielsimonjr/math-mcp.git
cd math-mcp
bun install
bun run build # tsc — the only build step
bun run test # integration testsbun --version # v1.4.0 or higher
node --version # v22.0.0 or higher
bun run type-check # completes without errors
bun run test # integration tests passAdd to your Claude Desktop config (%APPDATA%\Claude\claude_desktop_config.json
on Windows; ~/Library/Application Support/Claude/claude_desktop_config.json on
macOS; ~/.config/Claude/claude_desktop_config.json on Linux):
{
"mcpServers": {
"math-mcp": {
"command": "node",
"args": ["/path/to/math-mcp/dist/index.js"]
}
}
}claude mcp add --transport stdio math-mcp node /path/to/math-mcp/dist/index.jsEvaluate a mathematical expression, optionally with variables.
expression (string) — the expression
scope (object, optional) — variable values, e.g. {x: 5}
evaluate("2 + 2") // 4
evaluate("sqrt(16)") // 4
evaluate("x^2 + 2*x", {x: 5}) // 35
evaluate("derivative(x^2, x)") // "2 * x"Simplify an expression.
expression (string)
simplify("2 * x + x") // "3 * x"
simplify("(x + 2)^2") // "x^2 + 4*x + 4"Differentiate symbolically.
expression (string), variable (string)
derivative("x^2", "x") // "2 * x"
derivative("sin(x)", "x") // "cos(x)"Solve an equation for a variable. Returns exact roots (including complex) for polynomials of degree ≤ 3; for degree ≥ 4 or transcendental equations it falls back to numeric, real roots only.
equation (string), variable (string)
solve("x^2 - 4 = 0", "x") // roots of x
solve("2*x + 3 = 7", "x") // x = 2Matrix algebra. Matrices are passed as JSON strings.
operation (string) — multiply, inverse, determinant, transpose, eigenvalues, add, subtract
matrix_a (string) — e.g. "[[1,2],[3,4]]"
matrix_b (string, optional) — for binary operations
matrix_operations("determinant", "[[1,2],[3,4]]") // -2
matrix_operations("multiply", "[[1,2],[3,4]]", "[[5,6],[7,8]]") // [[19,22],[43,50]]
matrix_operations("transpose", "[[1,2,3],[4,5,6]]") // [[1,4],[2,5],[3,6]]Dataset statistics. Data is passed as a JSON string. Note: mode returns an
array (single mode [value], multiple modes [v1, v2]).
operation (string) — mean, median, mode, std, variance, min, max, sum, product
data (string) — e.g. "[1,2,3,4,5]"
statistics("mean", "[1,2,3,4,5]") // 3
statistics("std", "[2,4,4,4,5,5,7,9]") // 2
statistics("mode", "[1,2,2,3,4,4,4,5]") // [4]Convert a value between units.
value (string) — value with unit, e.g. "5 inches"
target_unit (string) — e.g. "cm"
Use compound forms for speeds (mi/h, km/h, m/s); the shorthands mph /
kph / knot are not recognized units. Some astronomical/nautical units
(lightyear, parsec, AU, nauticalMile, …) are not in the unit set.
unit_conversion("5 inches", "cm") // "12.7 cm"
unit_conversion("100 fahrenheit", "celsius") // "37.78 celsius"
unit_conversion("50 mi/h", "km/h") // "80.47 km/h"MCP client (stdio)
↓
src/index.ts — MCP server + 7 tool definitions (→ dist/index.js, the bin)
↓
src/tool-handlers.ts — validate → compute → format, per tool
↓
src/math-engine.ts — MathTS instance (create(all), mathjs-compatible)Compute: MathTS (@danielsimonjr/mathts-compat, @danielsimonjr/mathts-matrix). No acceleration router / WASM / worker / GPU tier — those were removed in v4; MathTS does its own internal dispatch.
Safety: input validation and size limits (src/validation.ts), token-bucket rate limiting (src/rate-limiter.ts), expression cache (src/expression-cache.ts).
Observability: Prometheus metrics + health probes on port 9090 (src/telemetry/).
math-mcp/
├── src/
│ ├── index.ts # MCP server + 7 tool definitions (→ dist/index.js, bin)
│ ├── math-engine.ts # Builds the MathTS instance (create(all))
│ ├── tool-handlers.ts # Business logic for the 7 tools
│ ├── handler-utils.ts # Shared handler helpers
│ ├── validation.ts # Input validation, sandboxing, size limits
│ ├── rate-limiter.ts # Token-bucket rate limiting
│ ├── expression-cache.ts # LRU cache for parsed/evaluated expressions
│ ├── health.ts # Health-check system
│ ├── errors.ts / types.ts
│ ├── shared/ # constants.ts, logger.ts
│ └── telemetry/ # metrics.ts (Prometheus), server.ts (HTTP :9090)
├── test/
│ ├── integration-test.js # Integration tests
│ ├── correctness-tests.js
│ ├── unit/ # Vitest unit tests
│ └── security/ # Security tests (injection, DoS, fuzzing, bounds)
├── dist/ # Compiled JavaScript (dist/index.js is the entry)
├── skills/math/ # Companion `math` skill (math-mcp:math, /math)
├── docs/ # Documentation
├── CHANGELOG.md · CONTRIBUTING.md · SECURITY.md · LICENSE · package.jsonBun is the TypeScript-on-Bun toolchain; Node runs the shipped server.
bun run build # tsc
bun start # node dist/index.js
bun run dev # tsc && node dist/index.js
bun run test # integration tests
bun run test:correctness
bun run test:unit # Vitest
bun run test:security # Vitest security suite
bun run test:coverage
bun run type-check # tsc --noEmit
bun run lint # ESLint
bun run lint:fix
bun run format # Prettier
bun run format:checkEnvironment variables read by the server:
# Logging
LOG_LEVEL=debug|info|warn|error # verbosity (default: debug; info when NODE_ENV=production)
ENABLE_PERF_LOGGING=true # per-call performance logging (default: off)
DISABLE_PERF_TRACKING=true # disable internal perf tracking (default: tracking on)
# Rate limiting
MAX_REQUESTS_PER_WINDOW=100 # requests per window (default: 100)
RATE_LIMIT_WINDOW_MS=60000 # window length, ms (default: 60000)
MAX_CONCURRENT_REQUESTS=10 # max in-flight operations (default: 10)
MAX_QUEUE_SIZE=50 # max queued requests (default: 50)
OPERATION_TIMEOUT=30000 # per-operation timeout, ms (default: 30000)
# Cache & telemetry
EXPRESSION_CACHE_SIZE=1000 # LRU expression-cache entries (default: 1000)
ENABLE_TELEMETRY=true # start the metrics/health HTTP server (default: off)
TELEMETRY_PORT=9090 # metrics/health port (default: 9090)Input size limits are fixed constants in src/validation.ts (not
environment-configurable): max matrix dimension 1000×1000, max array length
100000, max expression length 10000, max nesting depth 50.
Unit "X" not found. — the unit isn't in MathTS's set. Use compound speed forms (mi/h, not mph); some astronomical/nautical units aren't available.
Undefined symbol x — an expression left a free variable (e.g. mixing a symbolic term with a numeric one in evaluate). Supply scope, or keep symbolic and numeric parts separate.
Input rejected as too large — inputs above the size limits (matrix 1000×1000, array 100000, expression 10000 chars, nesting depth 50) are refused by design. These limits are fixed constants in src/validation.ts.
Build/test issues — ensure Bun ≥ 1.4 and Node ≥ 22, then bun install && bun run build && bun run test.
CHANGELOG.md — version history
CONTRIBUTING.md — contribution guidelines
SECURITY.md — security policy
skills/math/SKILL.md — the math companion skill playbook
Contributions welcome — see CONTRIBUTING.md. Fork, branch,
make changes, bun run test, commit with a conventional-commit message, and open a
pull request.
ISC License — see LICENSE.
MathTS — the TypeScript compute engine (mathjs-compatible API)
MCP SDK — Model Context Protocol implementation
Made with ❤️ by the math-mcp contributors
Calculate the derivative of an expression with respect to a variable. Example: derivative('x^2', 'x') returns '2*x'
| Name | Required | Description | Default |
|---|---|---|---|
| variable | Yes | Variable to differentiate with respect to | |
| expression | Yes | Mathematical expression |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only covers basic functionality. It lacks disclosure of limitations, error handling, or behavior for complex expressions (e.g., multivariate or implicit differentiation).
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: one sentence and an example. Every part is necessary and front-loaded.
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 tool with no output schema, the description provides a basic understanding and example. However, it does not explain return format or behavior for edge cases, leaving some gaps.
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?
Both parameters have schema descriptions. The description adds value with an example showing correct parameter order and usage, clarifying syntax beyond the schema.
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 computes derivatives of expressions with respect to a variable, and the example reinforces this. It distinguishes from sibling tools like solve or simplify by focusing solely on 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?
The description implies usage through the example but does not explicitly state when to use this tool versus alternatives like evaluate or simplify. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a mathematical expression. Supports arithmetic, algebra, calculus, matrices, and more. Example: '2 + 2', 'sqrt(16)', 'derivative(x^2, x)', 'det([[1,2],[3,4]])'
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional variables to use in the expression (e.g., {x: 5, y: 10}) | |
| expression | Yes | Mathematical expression to evaluate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as side effects, performance considerations, or error handling. The tool is presented as a black box.
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 concise, consisting of one declarative sentence followed by examples. It front-loads the core purpose and is free of unnecessary words, though the examples could be more systematically structured.
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?
There is no output schema, yet the description does not mention return types or format. The nested 'scope' object lacks explanation of structure. Given the complexity and multiple siblings, the description is insufficient for an agent to fully understand the tool's capabilities and boundaries.
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 input schema has 100% coverage, describing both parameters. The description adds a concrete example for 'scope', clarifying its usage. However, no additional semantics are provided for 'expression' beyond what the schema offers.
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 states 'Evaluate a mathematical expression' and lists examples covering arithmetic, calculus, matrices, etc. However, sibling tools like 'derivative' and 'matrix_operations' overlap with the claimed capabilities, creating ambiguity about when to use this tool versus more specific tools.
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 siblings. There are no conditions, limitations, or examples of appropriate use cases, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform matrix operations like multiply, inverse, determinant, transpose, eigenvalues. Matrices should be in array format like [[1,2],[3,4]].
| Name | Required | Description | Default |
|---|---|---|---|
| matrix_a | Yes | First matrix in JSON array format (e.g., '[[1,2],[3,4]]') | |
| matrix_b | No | Second matrix (for operations that require two matrices) | |
| operation | Yes | Matrix operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, yet it only mentions input formatting, not output shapes, constraints (e.g., square matrices for inverse/determinant/eigenvalues), or error behavior. It does not contradict annotations, but it is not transparent about the operation's behavior.
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?
Two sentences, front-loaded with the core purpose and immediately followed by an input format example. No 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?
Despite having no output schema, the description does not describe return values or per-operation output differences (e.g., determinant returns a scalar, eigenvalues return a list). For a multi-operation tool with several operations and a required schema, the description leaves significant gaps for an agent trying to interpret results.
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 descriptions cover all three parameters at 100%, and the description's matrix-format example is already present in the schema ('e.g., [[1,2],[3,4]]'). It adds no new parameter-level meaning beyond what the schema provides, so it meets the baseline.
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 specifies 'Perform matrix operations' and lists concrete operations (multiply, inverse, determinant, transpose, eigenvalues), clearly identifying the action and resource. The sibling tools are non-matrix math utilities, so the matrix focus distinguishes it.
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 an input-format guideline ('Matrices should be in array format like [[1,2],[3,4]]'), which is helpful, but it never explicitly states when to prefer this tool over alternatives or when not to use it. The difference from siblings is implied by the matrix-specific language rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simplify a mathematical expression. Example: '2 * x + x' becomes '3 * x'
| Name | Required | Description | Default |
|---|---|---|---|
| rules | No | Optional simplification rules | |
| expression | Yes | Mathematical expression to simplify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description discloses no behavioral traits beyond the basic operation. It does not mention whether it handles various expression types, side effects, or output format.
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 sentence plus an example, which is concise and front-loaded. Every part is relevant, though it could be slightly more informative.
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 lack of output schema and annotations, the description is incomplete. It does not explain the return value or provide sufficient context for the two parameters.
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 100%, so the baseline is 3. The description does not add meaning beyond the schema's parameter descriptions.
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 simplifies a mathematical expression and provides an example, making its purpose unambiguous. It implicitly distinguishes from sibling tools like derivative or evaluate.
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 on when to use this tool versus alternatives such as evaluate or solve. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve an equation. Example: solve('x^2 - 4 = 0', 'x') returns the solutions
| Name | Required | Description | Default |
|---|---|---|---|
| equation | Yes | Equation to solve | |
| variable | Yes | Variable to solve for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only provides a single example. It does not specify the nature of solutions, error handling, or limitations, leaving behavioral ambiguity.
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 concise with one sentence and an example, no extra words, front-loaded with the core purpose.
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?
Adequately states purpose and provides an example, but lacks details on return value structure, supported equation types, or error scenarios, making it minimally complete.
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 input schema already describes parameters, but the description adds a concrete example demonstrating expected input format and syntax, adding value beyond the schema's generic descriptions.
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 'Solve an equation' and provides a concrete example showing usage and output, effectively distinguishing it from sibling tools like derivative and simplify.
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 explicit guidance on when to use this tool versus alternatives. The example illustrates usage but does not set boundaries or mention when not to use solve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate statistical values like mean, median, mode (returns array), std (standard deviation), variance, min, max, sum, product.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data array in JSON format (e.g., '[1, 2, 3, 4, 5]') | |
| operation | Yes | Statistical operation to perform. Note: mode returns an array (single mode: [value], multiple modes: [value1, value2]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only notes that mode returns an array, which is already stated in the schema's operation description. It does not clarify return types for other operations, error handling, or edge cases like empty data, so transparency is limited.
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 clearly lists the operation names. It is front-loaded with the verb 'Calculate' and leaves no unnecessary words. Every part of the sentence contributes to understanding the tool's purpose.
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 simplicity (2 parameters, enum, no output schema), the description is mostly complete. It lists all supported operations and highlights mode's array return. However, it could mention that other operations return numeric values or that data must be a JSON array string, but the schema covers the latter, so the overall context is adequate.
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 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it lists operation names that are already in the enum and does not elaborate on the data format beyond what the schema states. Thus it provides no extra value.
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 calculates statistical values and enumerates the specific operations (mean, median, mode, etc.), which is a specific verb+resource. It distinguishes itself from sibling tools like evaluate, simplify, and derivative, which handle other types of math operations.
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 implies usage for statistical calculations by listing supported operations, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling alternatives are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between units. Example: convert '5 inches to cm' or '100 fahrenheit to celsius'
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value with unit (e.g., '5 inches', '100 km/h') | |
| target_unit | Yes | Target unit to convert to (e.g., 'cm', 'mi/h'). Use compound forms like 'mi/h' / 'km/h' for speed; 'mph'/'kph'/'knot' are not recognized (same as mathjs). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the conversion operation. It does not mention side effects (likely none), permissions, or error handling, but for a simple conversion tool, this is acceptable. No contradictions with annotations as 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence plus an example, lacking any structural elements like headings or bullet points. However, it efficiently conveys the core purpose, earning a high score for brevity.
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 simplicity and complete schema, the description is mostly adequate. However, it does not explain the return format (e.g., numeric value with unit string) or acknowledge potential limitations (e.g., unit compatibility), leaving some gap for the agent.
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 coverage is 100% with clear descriptions for both parameters (value and target_unit). The description adds an example but no additional semantic detail beyond what the schema provides, so baseline 3 is appropriate.
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 'Convert between units' and provides concrete examples ('5 inches to cm' and '100 fahrenheit to celsius'), making the tool's purpose unambiguous. It distinguishes from sibling tools like derivative or solve which handle 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of how to use the tool but does not explicitly state when to prefer it over alternatives or when not to use it. There is no guidance on unsupported conversions or edge cases, leaving the agent to infer usage from context.
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.
v4.1.3derivativeevaluatematrix_operationssimplifysolvestatisticsunit_conversionScored across 7 tools
The tools are mostly distinct in their specialized purposes (derivative, solve, matrix_operations, statistics, unit_conversion), but the 'evaluate' tool is a catch-all that can also handle calculus and matrices, creating ambiguity with the specialized tools. An agent might struggle to decide whether to use 'evaluate' or a dedicated tool for a given task.
Naming is consistently lowercase and uses underscores for multi-word names, but the pattern mixes verbs (evaluate, simplify, solve) and nouns (derivative, matrix_operations, statistics, unit_conversion). This is readable but not a uniform verb_noun convention.
With 7 tools, the server is well-scoped for a math toolkit, covering algebra, calculus, linear algebra, statistics, and unit conversion. Each tool has a clear domain, and the count is within the ideal range.
The server covers core math operations well (evaluate, simplify, derivative, solve, matrices, statistics, conversions), but integration (antiderivatives) is a notable missing calculus operation. This is a minor gap that agents might work around with 'evaluate' if supported, but it's not explicitly included.
Math.js MCP — wraps the mathjs.org API (free, no auth)
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Safe scientific calculator MCP for numeric expressions
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
