Axiom Advanced Math MCP
Axiom is an advanced mathematics MCP server (and CLI) that provides exact symbolic and numerical computation for LLMs.
compute: Solve a wide range of math problems via a CAS-style string: arithmetic, equation solving, calculus, algebra, linear algebra, combinatorics, probability/statistics, geometry (2D/3D), number theory, numerical methods, transforms, and more; falls back to raw Giac/Xcas.
verify: Independently check identities, solutions, and computation claims using numeric, symbolic, or both methods; returns verdict, confidence, and checks performed.
plot: Render 2D function graphs as SVG images with configurable ranges, dimensions, title, and asymptote detection.
Prompts: Guided multi-step workflows (solve-step-by-step, analyze-function, verify-identity, convert-units, analyze-dataset, solve-ode-system, regression-workflow).
Transports: Run as stdio MCP server, HTTP server, or one-shot CLI (including quiet/json/latex output modes).
Exactness: Combines math.js for numerics and Giac/Xcas WASM for symbolic computation, with fraction/exact-value support.
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., "@Axiom Advanced Math MCPCan you compute the integral of sin(x)^3?"
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.
Axiom — Advanced Math MCP Server
Exact symbolic and numerical mathematics for LLMs — a real computer algebra
system (Giac/Xcas) behind the Model Context Protocol, and behind a shell
command. Published as axiom-math.

Quick start
As a CLI, straight away:
npx -y axiom-math compute 'integrate(sin(x)^3,x)' # -cos(x)+cos(x)^3/3
npx -y axiom-math verify 'diff(x^3,x) = 3*x^2' # exit 0 — it holdsAs an MCP server, in any client's config:
{ "command": "npx", "args": ["-y", "axiom-math"] }As an agent skill — drop in skills/axiom-math/SKILL.md, which teaches an agent the three commands and their exit codes.
Related MCP server: math-logic-mcp
Why Axiom?
LLMs often make calculation errors, especially with symbolic math, exact fractions, and multi-step problems. Axiom provides verified, exact results through two layers:
math.js — Fast numerical evaluation (arithmetic, trigonometry, matrices)
Giac/Xcas WASM — Symbolic computation (calculus, algebra, equation solving)
Benchmark Results (GLM-5.1, May 2026)
Dataset | Baseline | +MCP | Delta |
GSM8K (100) | 96.0% | 98.0% | +2.0% |
MATH L3 (50) | 70.0% | 80.0% | +10.0% |
MATH L4 (50) | 50.0% | 62.0% | +12.0% |
MATH L5 (50) | 38.0% | 52.0% | +14.0% |
CAS-quick (60) | 55.0% | 70.0% | +15.0% |
Omni-MATH ≥7 (50) | 0.0% | 0–4% | (ceiling) |
Key insights:
Phase 0 grader (LaTeX/Unicode normalization + symbolic equivalence) is the dominant value driver across all datasets
CAS-quick lifted from 26.7% (April pre-grader) to 70% (post-grader) — the biggest single jump
Omni-MATH ≥7 is at ceiling for current LLM+CAS setups; needs fundamentally different approaches (Lean/Coq, fine-tuning, RAG)
Full results: benchmark/results/ and docs/superpowers/specs/ (per-phase analysis)
Features
Axiom exposes 3 MCP tools. Almost everything flows through compute, a single gateway that parses a CAS-style problem string and routes it to the right internal engine — so callers learn one tool, not dozens.
Tool | Purpose |
| Solve any math problem. Pass a CAS-style string ( |
| Independently check a mathematical claim (identity, solution, or computation) via symbolic and/or numeric methods. |
| Render a 2D function graph as an SVG image. |
What compute covers
compute recognizes CAS-style verbs and dispatches across these domains. Anything it doesn't recognize falls through to raw Giac/Xcas evaluation.
Domain | Verbs / examples |
Arithmetic & units |
|
Equation solving |
|
Calculus |
|
Multivariable calculus |
|
Algebra |
|
Linear algebra |
|
Number theory |
|
Combinatorics |
|
Probability |
|
Hypothesis testing |
|
Numerical methods |
|
2D geometry |
|
3D geometry |
|
Transforms & series |
|
Exact values |
|
Regression & sequences |
|
Installation
The package is axiom-math on npm.
Nothing to install for normal use — npx fetches and caches it:
npx -y axiom-math compute '2+2'Or install it so the axiom-math command is on your PATH:
npm install -g axiom-mathNode.js >= 20 required. The first run downloads about 3.8 MB (the CAS engine compiled to WebAssembly) and takes a few seconds; later runs come from the npx cache.
From source
For contributors, or to run a modified build:
git clone https://github.com/tufantunc/axiom-advanced-math-mcp.git
cd axiom-advanced-math-mcp
npm install
npm run buildDocker
# Build and run
docker-compose -f docker/docker-compose.yml up -d
# Check logs
docker-compose -f docker/docker-compose.yml logs -f
# Stop
docker-compose -f docker/docker-compose.yml downUsage
CLI (STDIO Transport)
# Run with stdio transport (default)
npm start
# Development mode
npm run devClaude Desktop integration:
// ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": [
{
"name": "axiom-math",
"command": "npx",
"args": ["-y", "axiom-math"]
}
]
}Running from a local checkout instead of npm — point args at the built entry
point:
"args": ["/path/to/axiom-advanced-math-mcp/dist/cli.js"]Command line
The same binary works as a one-shot CLI, so agents can use it as a skill with no MCP configuration. With no arguments it is the MCP server; with a subcommand it runs one computation and exits.
npx -y axiom-math compute 'integrate(sin(x)^3,x)'
npx -y axiom-math compute -q 'solve(x^2-4=0,x)' # {-2, 2}
npx -y axiom-math verify 'sin(x)^2+cos(x)^2 = 1' # exit 0 if true
npx -y axiom-math plot 'sin(x)' -o wave.svg
echo 'diff(x^3,x)' | npx -y axiom-math compute -q # 3*x^2Flag | Meaning |
| print one value only, for scripting |
| structured output |
| LaTeX-focused text ( |
| usage, or usage for a subcommand |
Exit codes: 0 success · 1 tool or usage error · 2 verify checked the
claim and it is false.
2 is a mathematical verdict, so a claim that never got checked does not use
it: one that fails to parse, or that the CAS cannot evaluate, exits 1 with
nothing on stdout. axiom-math verify '...' && ... therefore never reads a
syntax error as a disproof.
A ready-to-use agent skill is in skills/axiom-math/SKILL.md.
HTTP Transport
# Start HTTP server (default: http://127.0.0.1:3000)
npm run start:http
# Development HTTP
npm run dev:httpThe HTTP transport is stateless: every POST /mcp is handled independently,
no Mcp-Session-Id is issued, and no session state is kept between requests.
This server sends no server-initiated notifications, so nothing is lost — and it
scales horizontally with no shared state.
Method | Path | Behaviour |
POST |
| Handles a JSON-RPC message |
GET |
|
|
DELETE |
|
|
GET |
|
|
Security: there is no authentication and no rate limiting. The default bind address is
127.0.0.1, butdocker/docker-compose.ymlsetsMCP_HOST=0.0.0.0. If you expose the port, put it behind a reverse proxy that authenticates and rate-limits —docker/reverse-proxy/is a working, tested one (nginx + basic auth + per-client concurrency cap, with the app publishing no port of its own). SECURITY.md documents the full posture — what is protected, what is not, and how to report a vulnerability.
POST /mcpalso validates theHostheader against an allowlist (localhost,127.0.0.1,[::1]by default) to block DNS rebinding — a malicious page can make a victim's browser resolve an attacker domain to127.0.0.1and reach this server through it. If you reach the server by a LAN address, hostname, or reverse-proxy domain other than loopback, setMCP_ALLOWED_HOSTSor everyPOST /mcprequest will get a403. This check is not authentication — it only constrains which host names may reach the endpoint, nothing about who is asking.
Environment variables:
Variable | Default | Description |
|
| HTTP server port |
|
| HTTP server host |
| loopback only ( | Comma-separated |
|
| Per-evaluation timeout, in milliseconds. Bounds one CAS call and one js-compute call (arbitrary-precision integer work, arithmetic, plot sampling), so lowering it tightens both. Accepts a plain number or a |
|
| Wall-clock budget for one multi-call numerical routine (integration, root finding). Bounds the SUM of CAS calls, where |
|
| Heap ceiling for the child process that runs arbitrary-precision integer work and mathjs evaluation. Exceeding it fails the computation that caused it — calls queued behind it are re-sent to the replacement worker — and leaves the server up. Accepts whole MB, optionally suffixed ( |
| unset | Set to |
One bound is not configurable: a result over 100,000 characters is refused
rather than returned, so an expression like 1:2000000 reports its element count
instead of shipping 24 million characters into the caller's context.
Some inputs are refused rather than answered, because any answer would be
meaningless. Arithmetic that evaluates to NaN (such as 0/0) is an error; an
infinite result is returned with a warning, because a true infinity and a value
that overflowed the range of a double are indistinguishable once computed. A
t-test needs variation in whatever it actually tests — paired_t compares the
differences, so it is those that must vary, while Welch's two_sample_t needs
only one of the two samples to vary. A contingency table needs non-negative
counts, no all-zero row or column, rows of equal length, and more than one row
and column. A one-way ANOVA needs some within-group variation and more
observations than groups. And any of these is refused when the values are large
enough that the statistic itself overflows to infinity, because an overflowed
statistic is no longer the statistic. A numerical method is refused when its
expression does not depend on the variable it is solved or integrated over, or
when the CAS answers symbolically rather than with a number — previously the
leading term of that symbolic answer was reported as the result.
A system of differential equations written as a list — desolve([y'=z, z'=-y], x) — is rewritten into the matrix form the CAS solves and returns a solution for
every function. The components come back in the order the equations were written,
and the JSON envelope names them in a components field, because
[[cos(x),-sin(x)]] is not interpretable without it.
Initial conditions must be given for every function, at the same point, or not at
all — a partial set is refused rather than ignored. Also refused, each with its
own reason: a system that is not linear in the unknown functions; coefficients
that depend on the independent variable; a derivative of order above one (rewrite
y''=z as y'=w, w'=z); more than nine equations; and a system the CAS cannot
finish.
The infinite-result rule covers arithmetic evaluation. A symbolic +infinity
from the CAS routes — a limit, a divergent integral — is a normal answer and
carries no warning.
MCP Inspector
npm run inspectTool Reference
compute
The single gateway for all math. Pass a CAS-style problem string; the router parses it and dispatches to the right engine.
Parameter | Type | Description |
| string (required) | CAS-style problem, e.g. |
|
| Domain hint (default |
| integer 1–50 | Decimal places (default 10). |
|
| Output format (default |
Examples:
{ "problem": "solve(x^2 - 5*x + 6 = 0, x)" }
{ "problem": "int(x^2*sin(x), x)", "format": "latex" }
{ "problem": "lagrange(x*y, x+y, 1, [x, y])" }
{ "problem": "volume_tetrahedron([0,0,0],[1,0,0],[0,1,0],[0,0,1])" }
{ "problem": "binomial cdf n=10 k=3 p=0.5", "format": "json" }verify
Independently check a mathematical claim. Useful as a second, tool-grounded opinion on a result the model produced.
Parameter | Type | Description |
| string (required) | The claim, e.g. |
|
| Verification method (default |
Returns four fields: verified, evaluated, confidence, and checks_performed.
evaluated is the one to read first. It is false when no check produced a
usable answer — the claim did not parse, or the CAS could not evaluate it — in
which case verified: false means "unknown", not "refuted". Treating the two as
the same turns a syntax error into a disproof.
plot
Render a 2D function as an SVG image.
Parameter | Type | Description |
| string (required) | Function to plot, e.g. |
| string | Variable name (default |
| number | X range (default −10 … 10). |
| number | Y range (auto-detected if omitted). |
| number | Image size in px (default 600 × 400). |
| string | Optional chart title. |
Returns a base64-encoded SVG image (axes, grid, labels, asymptote detection) plus a text caption.
Prompts
The server also registers guided MCP prompts that chain compute/verify for multi-step workflows: solve-step-by-step, analyze-function, verify-identity, convert-units, analyze-dataset, solve-ode-system, and regression-workflow.
Run Benchmarks
Default production recipe (grader-v2 included automatically):
cd benchmark
npm install
# Set provider API key (one of):
export ZAI_API_KEY=...
export ANTHROPIC_API_KEY=...
export OPENROUTER_API_KEY=...
# Run benchmarks (provider defaults from --zai/--anthropic/--openrouter flags)
npm run cas:quick:zai # CAS-quick (60 problems, ~30 min)
npm run gsm8k:quick:zai # GSM8K-quick (100 problems, ~30 min)
npm run math:quick:zai # MATH L3-L5 quick (150 problems, ~75 min)Optional ablation features (off by default)
--features=output-hygiene— tool output post-processing (Unicode normalize, optional simplify, silent-failure warning). Marginal +1pp on CAS in live measurement.--features=grader-v3— equation-RHS extraction + bare-comma-list set match. Marginal +1pp on CAS.--features=self-consistency— N=3 majority voting (variance reduction; 3× cost; no accuracy gain on CAS).
Example:
npm run cas:quick:zai -- --features=output-hygiene,grader-v3See docs/superpowers/specs/2026-05-*-results.md for live ablation analysis of every flag.
What we tried that didn't work
This project went through extensive ablation across five phases (Phase 0–4). The following experimental approaches were tested live and rejected:
Phase 1: Structured JSON output with
\boxed{}trailers — model paraphrased boxed content into LaTeX style, breaking answer extraction. Net regression on CAS.Phase 2: 8K token budget (
tokens-8k) — gave the model more room to wander rather than recovering from truncation. Net regression −6.7pp on CAS.Phase 3: Self-consistency for accuracy — N=3 voting did not lift accuracy (Wang et al. literature gain not reproducible on CAS); kept as a methodology tool for variance reduction only.
Phase 4: Olympiad-specific scaffolding prompt — engagement improved (no-tool-call rate 84% → 74%) but accuracy stayed at 0%. Olympiad-tier problems are out of scope for prompt-engineering interventions.
Each phase's per-problem analysis is in docs/superpowers/specs/2026-05-*-results.md. The honest documentation of failures is preserved as a project archive.
Architecture
Compute gateway → router → domain handlers
┌─────────────────────────────────────────────────────────────┐
│ MCP Protocol Layer (stdio / HTTP) │
└─────────────────────────────────────────────────────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌─────────┐
│ compute │ │ verify │ │ plot │
└────┬────┘ └──────────┘ └─────────┘
│ route() → extract args → dispatch
▼
┌─────────────────────────────────────────────────────────────┐
│ Domain handlers: calculus, algebra, matrix, multivariable, │
│ geometry / geometry3d, combinatorics, probability, │
│ hypothesis testing, number theory, numerical methods, … │
└─────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ math.js │ │ Giac/Xcas │ │ Exact engine │
│ (numerical) │ │ (symbolic) │ │ (fractions) │
└──────────────┘ └──────────────┘ └──────────────┘compute never asks the caller to pick a handler. The router matches the problem string against ordered rules, the matching extractor parses arguments, and the dispatcher calls the corresponding domain handler. Unmatched input falls through to raw Giac/Xcas.
Response Format
Text-format responses are line-structured so LLMs (and the benchmark grader) can extract answers reliably:
{
"content": [
{ "type": "text", "text": "Result: 400/11" },
{ "type": "text", "text": "Decimal: 36.3636363636" },
{ "type": "text", "text": "LaTeX: \\frac{400}{11}" },
{ "type": "text", "text": "" },
{ "type": "text", "text": "The answer is 400/11 (≈ 36.36)" }
],
"isError": false
}Benchmark Results
Datasets
Dataset | Problems | Difficulty |
GSM8K | 100 | Grade school math (arithmetic) |
MATH L3 | 50 | High school math |
MATH L4 | 50 | Advanced high school math |
MATH L5 | 50 | Olympiad-level math |
Omni-MATH ≥7 | 50 | Expert-level math |
How to Run
See Run Benchmarks above for the commands. In short, from the repository root:
npm run benchmark:zai # quick sample, GLM-5.1
npm run benchmark:full:zai # all datasets
npm run benchmark:l5:zai # one difficulty tierSwap :zai for :openrouter to change provider. The benchmark/ directory is
a separate npm project with finer-grained scripts (cas:quick:zai,
gsm8k:quick:zai, …); npm run benchmark:* from the root delegates to them.
Environment variables:
Variable | Required for | Description |
| zai provider | Your z.ai API key |
| openrouter provider | Your OpenRouter API key |
Development
Scripts
Command | Description |
| Compile TypeScript to |
| Run STDIO server |
| Run in development mode (tsx) |
| Run HTTP server |
| Run HTTP server in dev mode |
| Unit tests — no build required |
| Integration tests — builds first, exercises |
| Unit tests in watch mode |
| Unit tests with coverage report |
| Type-check without emitting |
| Lint with oxlint |
| Auto-fix linting issues |
| Format with Prettier |
| Check formatting without writing |
| Open the MCP Inspector against the stdio server |
Testing
The suites are split. npm test runs the unit tests and needs no build;
npm run test:integration builds first and exercises the packaged dist/
output, so it catches things the unit suite cannot — the shipped binary's
argument dispatch, the MCP handshake, exit codes.
npm test # unit
npm run test:integration # integration (runs npm run build first)
npm run test:watch # unit, watch mode
npm run test:coverage # unit, with coverageTest coverage: unit + integration suite, 100% pass rate. Run npm test for the current count — it changes too often to keep a number here in sync.
WASM Build (Giac)
npm run build:giac:wasm
# Build a specific upstream ref instead of master
GIAC_REF=v1.9.x npm run build:giac:wasmThis runs scripts/build-giac-wasm.sh, which builds
docker/build-giac-wasm/Dockerfile with docker build (no Compose file
involved) and writes giac.wasm.js straight into src/server/giac/ — no
manual copy step needed. Requires Docker Desktop (or another Docker daemon)
running locally. Per-task build logs land under logs/giac-build/.
Contributing
Bug reports and pull requests are welcome — see CONTRIBUTING.md for the setup, the checks CI runs, and the few things about this codebase that are not obvious from reading it.
License
GNU General Public License v3.0 or later — see LICENSE.
Axiom embeds Giac/Xcas, which is GPL-3.0-or-later, so the combined work carries the same license. Details and attribution: THIRD-PARTY-NOTICES.md.
Does the GPL affect my agent?
No. Your agent talks to Axiom over the Model Context Protocol — a separate process, over stdio or HTTP. Separate programs communicating at arm's length are not a combined work, so running Axiom alongside your own agent puts no license obligation on your code, whatever license it uses. Running the software is unrestricted under the GPL, including running it as a service.
The copyleft terms apply when you redistribute Axiom itself — shipping it (modified or not) inside a product you hand to someone else. In that case, pass along the source under GPL-3.0 and keep the notices intact.
Available Tools
3 toolscomputeA
Solve any math problem: equations, calculus, algebra, matrices, combinatorics, probability, statistics, geometry, number theory, and more. Pass a CAS-style problem string (e.g., "solve(x^2-4=0, x)", "diff(x^3, x)", "det([[1,2],[3,4]])", "C(10,3)", "2+3*sin(pi/4)") or any Giac/Xcas expression.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain hint: real (default) — real solutions complex — complex solutions (csolve, cfactor) numeric — force numerical methods exact — exact symbolic form | |
| format | No | Output format: text (default) — human-readable result latex — LaTeX-focused output json — structured ComputeEnvelope | |
| problem | Yes | Mathematical problem to solve. Use CAS-style function calls for clarity: solve(x^2-4=0, x) — solve equation diff(x^3, x) — differentiate int(x^2, x, 0, 1) — definite integral limit(sin(x)/x, x, 0) — limit taylor(exp(x), x=0, 5) — Taylor series factor(x^2-4) — factorize simplify((x^2-1)/(x-1)) — simplify expand((x+1)^3) — expand det([[1,2],[3,4]]) — matrix determinant C(10,3) — combinations ifactor(2310) — prime factorization 2+3*sin(pi/4) — arithmetic Or any valid Giac/Xcas expression as fallback. | |
| precision | No | Decimal precision (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It accurately indicates a computational tool via examples, but does not describe potential limitations, output formatting behaviors, or error handling. It does not contradict any annotations, but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph that front-loads the core purpose and then provides illustrative examples. While somewhat long due to the many examples, each example adds practical value for understanding supported syntax, so it earns its place.
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?
With no output schema and no annotations, the description covers the purpose and input syntax well but omits details about return values, output structure (unless using 'format' parameter), and situational guidance relative to siblings. It is adequate for invoking the tool but leaves some gaps in full context.
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 enriches the 'problem' parameter with detailed CAS-style examples (e.g., 'solve(x^2-4=0, x)', 'det([[1,2],[3,4]])'), which adds meaningful guidance beyond the schema. Other parameters are well-documented in the schema itself.
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 solves math problems across many domains and provides explicit CAS-style examples. It distinguishes itself from siblings primarily through its focus on computation, but does not explicitly contrast with 'plot' or 'verify'.
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 math problem-solving through examples, but it does not provide explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or contexts where 'verify' or 'plot' might be more appropriate, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plotA
Plot a mathematical function as an SVG graph. Returns an image showing the function curve with axes, grid, and labels.
Examples:
plot sin(x) from -2pi to 2pi
plot x^2 - 3*x + 1 from -5 to 5
plot exp(-x^2) (Gaussian curve)
plot 1/x with asymptote detection
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Chart title (optional) | |
| width | No | Image width in pixels (default: 600) | |
| x_max | No | Maximum x value (default: 10) | |
| x_min | No | Minimum x value (default: -10) | |
| y_max | No | Maximum y value (auto-detected if omitted) | |
| y_min | No | Minimum y value (auto-detected if omitted) | |
| height | No | Image height in pixels (default: 400) | |
| variable | No | Variable name (default: "x") | |
| expression | Yes | Mathematical expression to plot (e.g., "sin(x)", "x^2 - 3*x + 1") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the output type (SVG image), the presence of axes/grid/labels, and asymptote detection in an example. It does not mention error handling or limitations, but covers the key behavior of returning an image.
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 front-loaded with the core statement, then a brief output description, followed by concise, well-chosen examples. Every sentence earns its place with no redundancy.
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 has 9 parameters and no output schema, the description is relatively complete: it states the return type, mentions asymptote detection, and shows usage patterns. It lacks explicit details on expression syntax limitations, but the examples plus full schema coverage make it sufficient.
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%, so baseline is 3. The description adds value with examples that illustrate usage of x_min/x_max and expression syntax, going beyond the schema's individual 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 plots a mathematical function as an SVG graph, with a specific verb and resource. It distinguishes itself from sibling tools (verify, compute) by focusing on graphical output.
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 clear context through examples, showing typical usage like 'plot sin(x) from -2*pi to 2*pi'. It does not explicitly exclude alternatives or name when not to use, but the examples and focus on graphing imply its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyA
Verify a mathematical claim using symbolic and/or numeric checks. Supports identity verification (e.g., "sin(x)^2+cos(x)^2 = 1"), solution checking (e.g., "x=2 satisfies x^2-4=0"), and computation assertions.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Mathematical claim to verify. Examples: "sin(x)^2 + cos(x)^2 = 1" — identity check "x=2 satisfies x^2-4=0" — solution check "diff(x^3, x) = 3*x^2" — computation check | |
| format | No | Output format: text (default) — human-readable verdict json — structured VerifyResult | |
| method | No | Verification method (default: "both") |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions that verification uses symbolic and/or numeric checks, adding some context, but does not describe limitations, error behavior, or what happens when a claim cannot be verified.
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 and front-loaded with the purpose statement, followed by clear, relevant examples. Every sentence adds value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with strong schema coverage, the description adequately covers purpose and examples. However, without an output schema or annotations, a brief note about the verdict structure (beyond the format parameter) would improve completeness, though it is largely sufficient.
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 provides 100% parameter coverage with detailed descriptions for claim, format, and method, including enums and examples. The description adds no significant parameter semantics beyond what the schema already conveys.
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 verifies mathematical claims using symbolic and/or numeric checks. It specifies three distinct use cases (identity verification, solution checking, computation assertions) and distinguishes it from sibling tools compute and plot.
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 its examples but does not explicitly state when to use verify over alternatives like compute or plot. No exclusions or alternative recommendations are provided.
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.
3 tool updates
v1.0.2- First observed
compute - First observed
plot - First observed
verify
TDQS
Scored across 3 tools
Verify and compute have some overlap in that compute can evaluate assertions, but their primary purposes are distinct (checking claims vs. solving problems). Plot is clearly separate. Descriptions help differentiate them, though an agent might occasionally misselect.
All three tool names are single lowercase verbs (verify, compute, plot), forming a simple and consistent pattern. No naming ambiguities or mixed conventions.
Three tools is slightly on the lower end but reasonable for a focused math MCP. Each tool covers a broad category (verification, computation, plotting), so the count feels appropriate rather than sparse.
The tool surface covers the core mathematical workflows: solving/computing, verifying claims, and visualizing functions. 'Compute' is comprehensive enough to handle simplification, integration, and other operations, leaving no obvious dead ends.
Maintenance
Related MCP Connectors
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
MCP server for progressive tool usage at any scale (see https://klavis.ai)
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseBqualityAmaintenanceA universal mathematics MCP server that gives LLM clients full access to SageMath for symbolic calculus, number theory, linear algebra, and more, with persistent state across tool calls.40388 PyPI16MIT
- AlicenseAqualityDmaintenanceMCP server that gives small LLMs verified symbolic-math & logic tools.61Apache 2.0
- AlicenseAqualityCmaintenanceA Model Context Protocol server that exposes 8 mathematical tools (arithmetic, algebra, calculus, matrix operations, statistics, probability, unit conversions) to any MCP-compatible AI agent, enabling mathematical computations without code.89 npm1MIT
- AlicenseNot gradedqualityAmaintenanceProvides a token-efficient exact math engine for AI agents, enabling computation of derivatives, integrals, equations, and optimized Python/NumPy code via a single MCP tool.4MIT