Ultimath
Ultimath MCP
Хватит галлюцинировать числами. MCP-сервер, который прогоняет каждое математическое выражение через восемь независимых движков параллельно — точный символьный, шаровой, интервальный, три разных варианта чисел с плавающей запятой произвольной точности, отложенный символьный и IEEE 754, каждый со своими собственными режимами сбоев — и возвращает все восемь показаний рядом, так что когда они расходятся, вы знаете, что ответ численно ненадёжен.
Engine | Что делает |
Exact symbolic | Точная арифметика: определяет значение, а не приближает его |
Multiprecision | Шаровая арифметика со сквозным строгим радиусом |
Interval | Строгие нижние/верхние границы (гарантированное включение) |
Binary float | Двоичные числа с плавающей запятой произвольной точности, без GMP внизу |
PARI/GP | Собран без GMP: собственные целочисленные и трансцендентные ядра |
NTL RR | Точная целочисленная мантисса × 2^e; округляются только операции |
Deferred symbolic | Переписывает перед вычислением: сокращение никогда не округляется |
IEEE-754 double | Стандартное аппаратное число с плавающей запятой |
За что отвечает каждый движок
Прочитать восемь чисел — лишь половина ответа. Каждый движок также говорит, насколько он ручается за собственный результат, — и эти три ответа не являются градациями друг друга:
Поле | Что говорит движок |
| Оно хранит точное значение. Отображаемое значение — его усечение: каждая следующая запрошенная цифра — это цифра самого числа, а не более точное приближение. |
| Его собственная граница погрешности покрывает первые |
ни то, ни другое | Оно не несёт никакой границы погрешности. Оно напечатало столько цифр, сколько вы запросили, и не может сказать ничего ни об одной из них. |
Эта последняя строка — не 0, и именно поэтому существуют остальные движки. Пять из восьми таковы по построению.
Для exp(pi*sqrt(163)) - 262537412640768744 один движок печатает 63 цифры, из которых 34 верны, — и ничего об этом не говорит. Два других доказывают 33 цифры и останавливаются. Один хранит значение точно. Одно лишь чтение восьми чисел не скажет вам, что есть что.
Ни один движок никогда не спрашивают о другом: каждое утверждение — о самом себе.
Related MCP server: mcp-abacus
Точный движок
calcium разрешает вопрос равенства, а не сравнивает цифры, достигает полюсов, к которым остальные могут лишь приближаться (tan(pi/2) — это uinf), и когда напечатанные цифры — лишь усечение, он также возвращает замкнутую форму — sqrt(2)+1 возвращается вместе с Add(Sqrt(2), 1) — в обычной форме и в LaTeX, а acosh(0.5) — с Div(Mul(NumberI, Pi), 3) — именованное значение, а не элемент поля, в котором оно хранится.
Замкнутая форма включается по желанию в HTTP API ("closed_form": true), потому что доказательство такой формы стоит дороже, чем чтение цифр. Этот клиент всегда запрашивает её: выдача точного значения — это то, что обещает его схема вывода.
Инструменты
evaluate— вычислить выражение на всех восьми движках и сравнить. Поддерживает арифметику, тригонометрию (sin,cos,tan), экспоненту/логарифм (exp,ln,log), корни и степени (sqrt,x^y), факториал, комплексные числа (3+2i), альтернативные основания (0xFF,0b1010) и константы (pi,e, золотое сечениеPHI).list_functions— перечислить все функции, которые предоставляют движки (имя, арность, категория, описание). Опционально фильтровать по категории.
Сравнения не означают одно и то же на каждом движке. На движках с гарантированным включением
!=,<и>истинны только после того, как доказаны;==,<=и>=истинны, как только они не опровергнуты. Истинный==там — не доказательство равенства — calcium решает это точно, — но истинный!=— доказательство различия.
Умножение должно быть явным: пишите
2*pi,2*sin(x),(a+b)*(c+d). Соседство не является умножением (2pi— ошибка). Выражения чисто математические — никаких приведений типов или конструкторов; записывайте комплексное число как1+2i.
Установка
Получите бесплатный API-ключ на https://ultimath.ai.
Добавьте сервер в конфигурацию вашего MCP-клиента (пример для Claude Desktop):
{
"mcpServers": {
"ultimath": {
"command": "npx",
"args": ["-y", "ultimath-mcp"],
"env": {
"ULTIMATH_API_KEY": "your_api_key_here"
}
}
}
}Вот и всё — npx загружает и запускает сервер по требованию.
Требования
Node.js ≥ 18
API-ключ Ultimath (
ULTIMATH_API_KEY)
Ссылки
Веб-сайт: https://ultimath.ai
Исходный код: https://github.com/Flupke68/ultimath-mcp
Под капотом
Движки Ultimath основаны на FLINT/Arb, Calcium, GMP/MPFR и MPFI — полные сведения об авторах на https://ultimath.ai/credits.
Конфиденциальность
Ultimath хранит только хэш вашего API-ключа и базовые метрики использования для работы и защиты сервиса; выражения вычисляются, но не сохраняются для обучения. Полная политика: https://ultimath.ai/privacy/
Лицензия
MIT
Available Tools
2 toolsevaluateEvaluate & cross-check a math expressionARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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', '2*pi', '2*(3+4)', 'factorial(10)' |
Output 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
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.
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.
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.
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.
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.
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 functionsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category, e.g. 'special', 'trigonometric'. Omit to list all. |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.6.0- Changed
evaluate10 fields changed- changed
Input schema / properties / precision / descriptionPrevious 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." - changed
Input schema / properties / precision / maximumPrevious value: -50New value: +999 - added
Output schema / properties / accuracyAdded 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" +} - added
Output schema / properties / engines / items / properties / digitsAdded 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" +} - added
Output schema / properties / engines / items / properties / divergesAdded 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" +} - added
Output schema / properties / engines / items / properties / exactAdded 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" +} - changed
Output schema / properties / engines / items / properties / name / descriptionPrevious value: -"Engine id: flint, dec, cpp, mpfi, or ntl"New value: +"Engine id: calcium, flint, mpfi, or cpp" - added
Output schema / properties / engines / items / properties / symbolicAdded 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" +} - added
Output schema / properties / engines / items / properties / symbolic_latexAdded value: +{ + "description": "The closed form as LaTeX", + "type": "string" +} - added
Output schema / properties / resultAdded value: +{ + "description": "The retained reading — read `accuracy` before quoting any of its digits", + "type": "string" +}
1 tool update
v0.2.0- Changed
evaluate1 field changed- changed
Output schema / properties / engines / items / properties / name / descriptionPrevious value: -"Engine id: flint, dec, cpp, or mpfi"New value: +"Engine id: flint, dec, cpp, mpfi, or ntl"
2 tool updates
v0.1.5- First observed
evaluate - First observed
list_functions
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Diff and poisoning detection for MCP servers: catch schema drift and prompt poisoning.
21
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server that gives small LLMs verified symbolic-math & logic tools.62Apache 2.0
- AlicenseAqualityAmaintenancePure-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).61GPL 3.0
- AlicenseAqualityDmaintenanceAn 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.319 PyPIMIT
- AlicenseAqualityAmaintenanceAn MCP server that performs exact arithmetic calculations, avoiding the pitfalls of float64 and unsafe eval, with resource limits for safe execution.167 PyPIMIT