de en es ja ko ru zh

Ultimath

Name: Ultimath
Author: Flupke68

by Flupke68

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Ultimath MCP

숫자를 환각하지 마세요. 모든 수식 표현을 여덟 개의 독립적인 엔진으로 병렬 실행하는 MCP 서버입니다. 정확한 기호 연산, 볼 연산, 구간 연산, 서로 다른 세 가지 임의 정밀도 부동소수점, 지연 기호 연산, IEEE 754가 각각 고유한 실패 모드를 가지고 있으며, 여덟 개의 결과를 나란히 반환합니다. 결과가 서로 다르면 그 답이 수치적으로 신뢰할 수 없다는 것을 알 수 있습니다.

엔진	하는 일
Exact symbolic	정확한 연산: 근삿값 대신 값을 판정합니다
Multiprecision	볼 연산, 엄밀한 반지름을 끝까지 유지합니다
Interval	엄밀한 하한/상한 (보장된 포위)
Binary float	GMP 없이 임의 정밀도 이진 부동소수점
PARI/GP	GMP 없이 구축: 자체 정수 및 초월 함수 커널
NTL RR	정확한 정수 가수 × 2^e; 연산만 반올림됩니다
Deferred symbolic	평가 전에 재기록: 소거는 절대 반올림되지 않습니다
IEEE-754 double	표준 하드웨어 부동소수점

각 엔진이 보증하는 것

여덟 개의 숫자를 읽는 것은 답의 절반에 불과합니다. 각 엔진은 또한 자신이 어디까지 보증하는지 말해줍니다. 그리고 세 가지 응답은 서로의 등급이 아닙니다:

필드	엔진이 말하는 것
`"exact": true`	값을 보유하고 있습니다. 읽은 값은 그것의 절단입니다. 추가로 요청하는 모든 자릿수는 더 가까운 근삿값이 아니라 그 숫자의 자릿수입니다.
`"digits": N`	자체 오차 한계가 처음 `N`개의 유효 숫자를 포함합니다. `0`은 실제 답입니다. 그것이 치명적 소거가 값에 하는 일입니다.
어느 쪽도 아님	오차 한계가 없습니다. 요청한 만큼의 자릿수를 출력했지만 그 어떤 자릿수에 대해서도 말할 수 없습니다.

마지막 행은 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)로 반환됩니다. 이는 저장된 체(field) 원소가 아니라 명명된 값입니다.

닫힌 형태는 HTTP API에서 선택 사항입니다 ("closed_form": true). 닫힌 형태를 증명하는 것이 숫자를 읽는 것보다 비용이 더 들기 때문입니다. 이 클라이언트는 항상 그것을 요청합니다: 정확한 값을 제시하는 것이 이 클라이언트의 출력 스키마가 약속하는 바이기 때문입니다.

도구

evaluate — 여덟 개의 엔진에서 식을 평가하고 비교합니다. 사칙연산, 삼각함수 (sin, cos, tan), 지수/로그 (exp, ln, log), 근과 거듭제곱 (sqrt, x^y), 계승, 복소수 (3+2i), 다른 진법 (0xFF, 0b1010), 상수 (pi, e, 황금비 PHI)를 지원합니다.
list_functions — 엔진들이 제공하는 모든 함수를 나열합니다 (이름, 인자 수, 분류, 설명). 선택적으로 분류로 필터링할 수 있습니다.

비교는 모든 엔진에서 같은 의미를 갖지 않습니다. 포위(enclosure) 엔진에서 !=, <, >는 증명된 경우에만 참입니다. ==, <=, >=는 반증되지 않는 한 참입니다. 거기서 참인 ==는 등식의 증명이 아닙니다. calcium이 그것을 정확히 판정합니다. 그러나 참인 !=는 다름의 증명입니다.

곱셈은 명시적이어야 합니다: 2*pi, 2*sin(x), (ab)*(c+d)처럼 쓰세요. 붙여 쓰기는 곱이 아닙니다 (2pi는 오류입니다). 식은 순수하게 수학적입니다. 타입 캐스트나 생성자가 없습니다. 복소수는 1+2i로 쓰세요.

설정

**https://ultimath.ai**에서 무료 API 키를 받으세요.
MCP 클라이언트 설정에 서버를 추가하세요 (Claude Desktop 예시):

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

그게 전부입니다 — npx가 필요할 때 서버를 가져와서 실행합니다.

요구 사항

Node.js ≥ 18
Ultimath API 키 (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 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.

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

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.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev0.6.0Aug 27, 2026

Changedevaluate10 fields changed

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"
+}

1 tool updatev0.2.0Jul 5, 2026
- Changedevaluate1 field changed
  - 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"
```
2 tool updatesv0.1.5Jul 1, 2026
- First observedevaluate
- First observedlist_functions

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A4.6/5.0

Scored 2026-08-27 16:55 across 2 tools

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

ActivityStale

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Math MCP LearningA
io.github.clouatre-labs
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Education & Learning Tools Research & Data Developer Tools
1725
https://math-mcp.fastmcp.app/mcp
NumProofB
io.github.projecttron
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
Finance Security
42
https://numproof.com/mcp
Aman-Amith-Shastry-scientific_computation_mcpA
ai.smithery
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Research & Data
2623
https://server.smithery.ai/@Aman-Amith-Shastry/scientific_computation_mcp/mcp
ActionGuard Protocol Inspector AgentB
io.github.lsendel
Diff and poisoning detection for MCP servers: catch schema drift and prompt poisoning.
Security Monitoring Developer Tools
21
https://actionguard.ai/mcp

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 9 months ago (2026-02-20 12:40 UTC)
6
2
Apache 2.0
mcp-abacus
Developer Tools
laszlopere
A
license
A
quality
B
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-10-13 12:18 UTC)
6
1
GPL 3.0
loadbench-mcp
Developer Tools
jeongho54
A
license
A
quality
D
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 4 months ago (2026-06-29 11:10 UTC)
3
MIT
calc-mcp-server
Developer Tools
slettmayer
A
license
A
quality
B
maintenance
An MCP server that performs exact arithmetic calculations, avoiding the pitfalls of float64 and unsafe eval, with resource limits for safe execution.
Updated 4 days ago (2026-11-05 10:15 UTC)
1
42 PyPI
MIT

Ultimath MCP

각 엔진이 보증하는 것

정확한 기호 엔진

도구

설정

요구 사항

링크

내부 동작

개인정보 보호

라이선스

Available Tools

Output Schema

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

math-logic-mcp

mcp-abacus

loadbench-mcp

calc-mcp-server