SageMath MCP Server

number_theory_operation

Idempotent

Perform primality testing, integer factorization, next prime, gcd, and lcm on large integers. Pass values above 2^53 as strings to avoid precision errors.

Instructions

Number theory: primality testing, integer factorisation, the next prime above n, gcd and lcm. Prefer this over evaluate_sage for any of these.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`a`	Yes	Primary integer. Pass values above 2^53 as a decimal STRING: JSON numbers are IEEE doubles in JavaScript-based clients, so 10^30 arrives as 1000000000000000019884624838656 and the answer is silently wrong.
`b`	No	Second integer, required for gcd and lcm. Same string rule.
`session`	No	Workspace to use, as a name or a portable handle. Workspaces have independent variables. A name is scoped to this MCP session; a handle returned by start_sage_session (workspace_token) reaches the same workspace across reconnects and is a bearer credential -- keep it secret. Omit for 'default'.	default
`operation`	Yes	Operation: 'is_prime', 'factor_integer', 'next_prime', 'gcd', 'lcm'

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0Sep 12, 2026

changedInput schema / properties / session / description

Previous value: -"Named workspace to use. Workspaces have independent variables; omit for 'default'."New value: +"Workspace to use, as a name or a portable handle. Workspaces have independent variables. A name is scoped to this MCP session; a handle returned by start_sage_session (workspace_token) reaches the same workspace across reconnects and is a bearer credential -- keep it secret. Omit for 'default'."

Changed6 schema fields changedv0.5.0Aug 14, 2026

addedInput schema / properties / a / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]

changedInput schema / properties / a / description

Previous value: -"Primary integer argument"New value: +"Primary integer. Pass values above 2^53 as a decimal STRING: JSON numbers are IEEE doubles in JavaScript-based clients, so 10^30 arrives as 1000000000000000019884624838656 and the answer is silently wrong."

removedInput schema / properties / a / type
```
Removed value: -"integer"
```

changedInput schema / properties / b / anyOf

Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / b / description

Previous value: -"Second integer (required for gcd, lcm)"New value: +"Second integer, required for gcd and lcm. Same string rule."

addedInput schema / properties / session

Added value: +{
+  "default": "default",
+  "description": "Named workspace to use. Workspaces have independent variables; omit for 'default'.",
+  "type": "string"
+}

First observedv0.3.1Jul 31, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description need not restate safety. However, it adds no behavioral context of its own — nothing about cost, determinism, or workspace side effects beyond what the schema's session field already explains.

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?

Two sentences, zero waste, with the operation list front-loaded and the routing instruction last. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, return values and argument mechanics are fully covered elsewhere, so the description only needs to establish scope and routing — which it does. It is slightly thin on workspace/session implications for a tool that takes a session parameter, but not enough to be blocking.

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

Parameters3/5

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 schema already explains the big-integer string rule, the b requirement for gcd/lcm, and the session/workspace semantics in detail; the description adds only the operation list, which largely duplicates the enum-adjacent schema text.

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 names a specific resource (number theory) and enumerates the exact operations (primality, factorisation, next prime, gcd, lcm) with a verb-level match to the 'operation' enum. It also names the sibling it supersedes, so an agent can distinguish it from evaluate_sage without opening a schema.

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?

'Prefer this over evaluate_sage for any of these' explicitly routes the agent away from the general-purpose evaluator, which is strong guidance. It stops short of a 5 because it gives no when-not condition (e.g. what to do if evaluate_sage is needed alongside, or whether session/workspace setup is a prerequisite).

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