Ultimath

Evaluate & cross-check a math expression

evaluate

Read-only

Check any math expression with eight independent engines and compare results, exposing unreliable values from floating-point error, singularities, or branch cuts. Use it when correctness matters.

Instructions

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.

Input Schema

TableJSON 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

TableJSON 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

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.6.0Aug 27, 2026

changedInput schema / properties / precision / description

Previous value: -"Decimal digits of precision (default 50). The free beta caps at 50; higher values are rejected server-side."New value: +"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."

changedInput schema / properties / precision / maximum
```
Previous value: -50New value: +999
```

addedOutput schema / properties / accuracy

Added value: +{
+  "additionalProperties": false,
+  "description": "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",
+  "properties": {
+    "agree": {
+      "description": "Engines returning this same reading",
+      "type": "number"
+    },
+    "engines": {
+      "description": "Engines asked — refusals included, since a refusal is part of the answer",
+      "type": "number"
+    },
+    "exact": {
+      "description": "An agreeing engine HOLDS this value — the reading is a truncation of it",
+      "type": "boolean"
+    },
+    "proved": {
+      "description": "Leading significant digits of `result` covered by a DIFFERENT engine's own error bound. Past this point the digits were printed at the precision asked for and no engine underwrites them — quoting them is quoting one implementation. 0 is a real answer; absent means no other engine carries a bound at all, which is not the same statement",
+      "type": "number"
+    },
+    "source": {
+      "description": "Engine the reading came from",
+      "type": "string"
+    }
+  },
+  "required": [
+    "source",
+    "agree",
+    "engines"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / engines / items / properties / digits

Added value: +{
+  "description": "Leading significant digits of `result` this engine backs with its OWN error bound; 0 means the bound covers none of them. With `exact` and `digits` BOTH absent, the engine carries no error bound at all and can say nothing about any digit it printed — which is not 0, and is the single most useful thing to read before trusting a number",
+  "type": "number"
+}

addedOutput schema / properties / engines / items / properties / diverges

Added value: +{
+  "description": "This engine's reading CONTRADICTS the consensus — a finding, not a formatting difference. Absent on an engine that agrees or cannot be compared",
+  "type": "boolean"
+}

addedOutput schema / properties / engines / items / properties / exact

Added value: +{
+  "description": "True when this engine holds the value EXACTLY — the reading is a truncation of the number itself, so every further digit you ask for is a digit of it. Not a very large `digits`: a different statement, never set alongside it",
+  "type": "boolean"
+}

changedOutput schema / properties / engines / items / properties / name / description

Previous value: -"Engine id: flint, dec, cpp, mpfi, or ntl"New value: +"Engine id: calcium, flint, mpfi, or cpp"

addedOutput schema / properties / engines / items / properties / symbolic

Added value: +{
+  "description": "Closed form of the value, e.g. Add(Sqrt(2), 1) — present only when the engine proved one AND the printed digits are a truncation of it",
+  "type": "string"
+}

addedOutput schema / properties / engines / items / properties / symbolic_latex

Added value: +{
+  "description": "The closed form as LaTeX",
+  "type": "string"
+}

addedOutput schema / properties / result

Added value: +{
+  "description": "The retained reading — read `accuracy` before quoting any of its digits",
+  "type": "string"
+}

Changed1 schema field changedv0.2.0Jul 5, 2026
- changedOutput schema / properties / engines / items / properties / name / description
```
Previous value: -"Engine id: flint, dec, cpp, or mpfi"New value: +"Engine id: flint, dec, cpp, mpfi, or ntl"
```
First observedv0.1.5Jul 1, 2026

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.

Deploy Server