What can you do with this server?

The Ultimath server evaluates mathematical expressions across multiple independent numeric engines simultaneously to detect floating-point errors and verify numeric reliability. * evaluate: Run any math expression through 4 independent engines (multiprecision, exact decimal, IEEE-754 double, interval arithmetic) in parallel and compare results side by side. When engines disagree, it flags numerically unreliable values (e.g., floating-point sensitivity, catastrophic cancellation, singularities, branch cuts). * list_functions: List all supported mathematical functions with name, arity, category, and description — optionally filtered by category (algebraic, trigonometric, hyperbolic, exponential, special, rounding, introspection). Supported operations: * Arithmetic (+, -, *, /, %), powers (x^y), roots (sqrt), factorial (!) * Trigonometry (sin, cos, tan), exponentials/logarithms (exp, ln, log) * Complex numbers (e.g. 3+2i), alternate base literals (e.g. 0xFF, 0b1010) * Built-in constants: pi, e, PHI Output control: Specify precision (1–50 decimal digits) and format (fixed, scientific, auto). Each engine returns structured diagnostics and warnings (e.g. precision loss, overflow, ULP errors). Notes: Multiplication must be explicit (e.g. 2*pi). No type casts or constructors — complex numbers use 1+2i notation. Expressions are not stored; only anonymized usage metrics are retained.

de en es ja ko ru zh

Ultimath

by Flupke68

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Ultimath MCP

Stop hallucinating numbers. An MCP server that runs every math expression through eight independent engines in parallel — exact symbolic, ball, interval, three different arbitrary-precision floats, deferred symbolic and IEEE 754, each with its own failure modes — and returns all eight readings side by side, so when they disagree you know the answer is numerically unreliable.

Engine	What it does
Exact symbolic	Exact arithmetic: decides a value instead of approximating it
Multiprecision	Ball arithmetic, rigorous radius carried through
Interval	Rigorous lower/upper bounds (guaranteed enclosure)
Binary float	Arbitrary-precision binary floats, no GMP below
PARI/GP	Built without GMP: its own integer and transcendental kernels
NTL RR	Exact integer mantissa × 2^e; only operations round
Deferred symbolic	Rewrites before evaluating: a cancellation never rounds
IEEE-754 double	Standard hardware floating point

What each engine stands behind

Reading eight numbers is only half the answer. Each engine also says how far it underwrites its own — and the three answers are not degrees of one another:

Field	What the engine is saying
`"exact": true`	It holds the value. The reading is a truncation of it: every further digit you ask for is a digit of the number, not a closer approximation.
`"digits": N`	Its own error bound covers the first `N` significant digits. `0` is a real answer — that is what catastrophic cancellation does to a value.
neither	It carries no error bound. It printed as many digits as you asked for and can say nothing about any of them.

That last row is not 0, and it is the reason the other engines exist. Five of the eight are there by construction.

On exp(pi*sqrt(163)) - 262537412640768744, one engine prints 63 digits of which 34 are right — and says nothing about it. Two others prove 33 and stop. One holds the value exactly. Reading the eight numbers alone would not tell you which was which.

No engine is ever asked about another: each statement is about itself.

Related MCP server: mcp-abacus

The exact engine

calcium settles an equality rather than comparing digits, reaches poles the others can only approach (tan(pi/2) is uinf), and when the printed digits are just a truncation it also returns the closed form — sqrt(2)+1 comes back with Add(Sqrt(2), 1), in plain form and in LaTeX, and acosh(0.5) with Div(Mul(NumberI, Pi), 3) — the named value, not the field element it is stored in.

The closed form is opt-in on the HTTP API ("closed_form": true) because proving one costs more than reading the digits. This client always asks for it: quoting an exact value is what its output schema promises.

Tools

evaluate — evaluate an expression on all eight engines and compare. Supports arithmetic, trig (sin, cos, tan), exp/log (exp, ln, log), roots and powers (sqrt, x^y), factorial, complex numbers (3+2i), alternate bases (0xFF, 0b1010), and constants (pi, e, golden ratio PHI).
list_functions — list every function the engines expose (name, arity, category, description). Optionally filter by category.

Comparisons do not mean the same thing on every engine. On the enclosure engines, !=, < and > are true only once proven; ==, <= and >= are true as soon as they are not disproven. A true == there is not a proof of equality — calcium decides that one exactly — but a true != is a proof of difference.

Multiplication must be explicit: write 2*pi, 2*sin(x), (a+b)*(c+d). Adjacency is not a product (2pi is an error). Expressions are purely mathematical — no type casts or constructors; write a complex number as 1+2i.

Setup

Get a free API key at https://ultimath.ai.
Add the server to your MCP client config (example for Claude Desktop):

{
  "mcpServers": {
    "ultimath": {
      "command": "npx",
      "args": ["-y", "ultimath-mcp"],
      "env": {
        "ULTIMATH_API_KEY": "your_api_key_here"
      }
    }
  }
}

That's it — npx fetches and runs the server on demand.

Requirements

Node.js ≥ 18
An Ultimath API key (ULTIMATH_API_KEY)

Under the hood

Ultimath's engines build on FLINT/Arb, Calcium, GMP/MPFR and MPFI — full credits at https://ultimath.ai/credits.

Privacy

Ultimath stores only a hash of your API key and basic usage metrics to run and secure the service; expressions are evaluated, not retained for training. Full policy: https://ultimath.ai/privacy/

License

MIT

Available Tools

2 tools

evaluateEvaluate & cross-check a math expressionA

Read-only

Verify any numeric result that has to be trusted, via the Ultimath API (https://ultimath.ai). Use this whenever the correctness of a number matters — floating-point-sensitive expressions, catastrophic cancellation, values near singularities or branch cuts, ties, or any computation where a single method could be silently wrong. Prefer it over computing by hand or running code: it evaluates the expression on 8 independent engines (exact symbolic, multiprecision ball, interval arithmetic, three different arbitrary-precision floats, deferred symbolic rewriting, IEEE 754 double) in parallel and returns every result plus per-engine precision diagnostics, so disagreement exposes an unreliable value that a single calculation would hide.

The 8 engines are independent and each computes with its own native primitive — so divergence between them (at poles, singularities, branch cuts, or ties like round(2.5)) is the backends' real behavior, NOT a bug. Agreement across engines is a confidence signal; divergence flags a value that is convention-dependent or near a domain edge — verify it rather than trust a single column.

One engine (calcium) is exact rather than numeric: it decides a value instead of approximating it, so it reaches poles the others can only approach (tan(pi/2) is uinf), and when the printed digits are only a truncation it also returns the closed form in symbolic / symbolic_latex (sqrt(2)+1 carries Add(Sqrt(2), 1)). Prefer that closed form when quoting an exact value.

A comparison does not mean the same thing on every engine. On the enclosure engines (flint, mpfi) !=, < and > return true only once the property is PROVEN, while ==, <= and >= return true as soon as it is not disproven. So a true == there is not a proof of equality — calcium decides that one exactly — but a true != IS a proof of difference. Each pair is complementary: a == b and a != b are never both false.

A value that is real comes back as a plain real number: an engine drops a zero imaginary part only when it PROVES the value real. So a trailing +0i is NOT decoration — it means that engine did not establish realness, and a visible residue (e.g. 4.3e-17i on the double engine) is genuine numerical error. Do not strip either one when reporting a result.

Supports: arithmetic, trigonometry (sin, cos, tan), exponentials and logs (exp, ln, log), roots and powers (sqrt, x^y), factorial, complex numbers (3+2i), arbitrary bases (0xFF, 0b1010), constants (pi, e, the golden ratio PHI). Multiplication must be EXPLICIT: write 2pi, 2(3+4), (a+b)(c+d), 2sin(x) — adjacency is NOT a product (2pi is an error). Precedence, tightest first: postfix factorial ! (2^3! = 2^(3!) = 64), then powers ^, then * / %, then + -. Note: expressions are mathematical only — there are no type casts ((int)x) or constructors (complex(1,2)); write a complex number as 1+2i or (re, im). Call list_functions for the authoritative list of available functions.

ParametersJSON Schema

Name	Required	Description
`format`	No	Output format (default 'fixed')
`precision`	No	Decimal digits of precision (default 50). The ceiling is the PLAN behind the key — the free beta caps at 50 and refuses more — and 999 above every plan, the length of the built-in constants.
`expression`	Yes	Math expression, e.g. '0.1 + 0.2', 'sin(pi/4)', 'sqrt(2)^2 - 2', '2pi', '2(3+4)', 'factorial(10)'

Output Schema

ParametersJSON Schema

Name	Required	Description
`ms`	No
`trace`	No
`result`	No	The retained reading — read `accuracy` before quoting any of its digits
`engines`	Yes	Per-engine results, compare to detect floating-point error
`inexact`	Yes	True if any engine emitted a warning (precision loss or domain issue somewhere)
`accuracy`	No	What the reading is worth once the other engines have been read against it. `exact` and `proved` are different KINDS of fact and stand together here
`angle_unit`	No
`expression`	Yes

TDQS

A5/5.0

Behavior5/5

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

The description explains nontrivial behavior far beyond the readOnlyHint annotation: engine divergence is real behavior, not a bug; comparison semantics differ per engine (e.g., `!=` can be a proof of difference while `==` is not a proof of equality); and trailing `+0i` indicates unproven realness rather than decoration. This is precisely the kind of behavioral nuance an agent needs.

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 long but every section earns its place: purpose, when-to-use, engine behavior, comparison semantics, realness, syntax, and precedence are all distinct and clearly organized. It is front-loaded with the core purpose and usage guidance before diving into technical details.

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?

Given the tool's complexity, the description is unusually complete. It covers return content (per-engine results and precision diagnostics), engine semantics, exact closed-form output, precision limits, supported operations, syntax constraints, and points to list_functions for the authoritative list. Nothing essential is missing for an agent to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: explicit-multiplication rules, precedence order, complex-number syntax, unsupported constructs like type casts, the precision ceiling tied to the plan, and examples. This makes the expression parameter far more usable than the schema alone.

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 opens with a specific verb and resource: 'Verify any numeric result that has to be trusted, via the Ultimath API.' It clearly states what the tool does, names its multi-engine evaluation behavior, and differentiates it from computing by hand, running code, and the sibling list_functions tool.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: 'Use this whenever the correctness of a number matters,' and enumerates concrete scenarios such as floating-point-sensitive expressions, cancellation, singularities, branch cuts, and ties. It also says 'Prefer it over computing by hand or running code,' directly routing the agent away from alternatives.

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

list_functionsList available functionsA

Read-only

List all mathematical functions available via the Ultimath API (https://ultimath.ai). Returns name, arity, category, and description for each function. Use this to discover what functions you can pass to the evaluate tool. Optionally filter by category (algebraic, trigonometric, hyperbolic, exponential, special, rounding, introspection). Every function is available on all 8 engines, but each computes it with its own native primitive — so results may diverge at poles, branch cuts, or ties, and that divergence is honest backend behavior, not a bug.

ParametersJSON Schema

Name	Required	Description	Default
`category`	No	Filter by category, e.g. 'special', 'trigonometric'. Omit to list all.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals important behavioral nuances: every function exists on all 8 engines but is computed via native primitives, so results may diverge at poles, branch cuts, or ties, and that divergence is intended backend behavior. This is rich, honest context that an agent needs before trusting listed functions.

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 front-loaded with purpose and return fields, then usage guidance, then filter options, then behavioral caveats. Every sentence earns its place; there is no filler or repetition of schema/annotation content.

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 read-only list tool with one optional parameter and no output schema, the description provides everything an agent needs: what it lists, what each entry contains, how to filter, how it relates to evaluate, and a warning about cross-engine divergence. No material gap remains.

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

Parameters4/5

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

The schema already covers the single optional 'category' parameter at 100% coverage, so the baseline is 3. The description adds value by enumerating all valid category values (algebraic, trigonometric, hyperbolic, exponential, special, rounding, introspection), which is especially useful since the schema provides no enum constraint.

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

Purpose5/5

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

The description states a specific verb and resource: 'List all mathematical functions available via the Ultimath API,' and explicitly lists the returned fields (name, arity, category, description). It clearly distinguishes itself from the sibling 'evaluate' tool by framing itself as the discovery step for functions to pass to evaluate.

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?

It explicitly tells the agent when to use this tool: 'Use this to discover what functions you can pass to the evaluate tool.' It names the sibling evaluate as the downstream consumer, but it does not explicitly state a when-not condition or directly contrast with evaluate in an 'instead' formulation.

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

Install Server

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

TDQS

A4.6/5.0

Disambiguation5/5

evaluate performs mathematical computation and returns multi-engine results, while list_functions only returns metadata about supported functions. There is no overlap or ambiguity between the two operations.

Naming Consistency4/5

Both names are imperative and clear, but evaluate is a bare verb while list_functions follows a verb_noun pattern. This is a minor stylistic inconsistency that does not create confusion.

Tool Count4/5

Two tools is below the typical 3–15 range, but the server's scope is narrow: one computational entry point plus one discovery helper. Each tool is necessary, so the count is slightly under but reasonable.

Completeness4/5

The core workflow is complete: discover functions with list_functions, then evaluate expressions with evaluate. Since this is a stateless computation service, lifecycle operations do not apply; the main minor gap is that supported constants are documented only in evaluate's description rather than being discoverable through list_functions.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

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
NumProof B
io.github.projecttron
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
Finance Security
42
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
HORIZON SHIELD ADeprecated
dev.workers.oga-surf-project.hs-mcp
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
Finance Open Data Research & Data
142

Related MCP Servers

math-logic-mcp
Code Execution Education & Learning Tools
ismailkerimov
A
license
A
quality
D
maintenance
MCP server that gives small LLMs verified symbolic-math & logic tools.
Updated 6 months ago (2026-02-20 12:40 UTC)
6
1
Apache 2.0
mcp-abacus
Developer Tools
laszlopere
A
license
A
quality
A
maintenance
Pure-Python MCP server for type-faithful calculation — evaluate expressions under fixed-point, IEEE-754 double, or exact rational arithmetic, with every answer labelled with its precision (exact vs inexact).
Updated a month ago (2026-08-07 05:33 UTC)
5
1
GPL 3.0
loadbench-mcp
Developer Tools
jeongho54
A
license
A
quality
C
maintenance
An MCP server that provides structural load and stability math (tipping, support reactions, beam checks) that language models often get wrong, enabling AI assistants to compute accurate engineering estimates.
Updated 2 months ago (2026-06-29 11:10 UTC)
3
MIT
calc-mcp-server
Developer Tools
slettmayer
A
license
A
quality
A
maintenance
An MCP server that performs exact arithmetic calculations, avoiding the pitfalls of float64 and unsafe eval, with resource limits for safe execution.
Updated 14 hours ago (2026-09-03 10:15 UTC)
1
MIT

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/Flupke68/ultimath-mcp'

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

Ultimath MCP

What each engine stands behind

The exact engine

Tools

Setup

Requirements

Links

Under the hood

Privacy

License

Available Tools

Output Schema

TDQS

TDQS

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

math-logic-mcp

mcp-abacus

loadbench-mcp

calc-mcp-server

Latest Blog Posts

MCP directory API