SageMath MCP Server

evaluate_sage

Execute SageMath code in a persistent session where variables persist across calls, enabling multi-step workflows like transforms, modular arithmetic, and number fields.

Instructions

Run SageMath code in a persistent session; variables persist across calls. Caller code is deny-by-default -- ordinary mathematics is allowed, but imports, external CAS interfaces and file/display/persistence calls are refused.

LAST RESORT for a single self-contained calculation: a dedicated tool exists for most of those and should be preferred, because it validates arguments and returns a typed result instead of a repr string. One exception overrides that steer -- the dedicated tools evaluate in a FRESH namespace and cannot see variables you defined here, so any multi-step workflow that builds an object once and then explores it (a graph and its invariants, a number field, a matrix decomposition) belongs in evaluate_sage across as many calls as it takes. For a one-off, reach for one of these first:

calculus: differentiate_expression, integrate_expression, limit_expression, series_expansion, symbolic_sum, solve_ode
algebra: solve_equation, simplify_expression, expand_expression, factor_expression, find_root
linear algebra: matrix_operation (determinant, inverse, eigenvalues, rank, rref, transpose), matrix_multiply
discrete: number_theory_operation, combinatorics_operation (binomial, partitions, catalan, fibonacci, bell), graph_operation, group_operation
specialised: elliptic_curve_operation, coding_theory_operation, polynomial_ring_operation, boolean_algebra_operation, geometry_operation, vector_calculus_operation
data: statistics_summary, distribution_operation
plots: plot_expression, plot3d_expression, plot_multi_expression

Use evaluate_sage only for what those do not cover, for example:

Transforms: var('t s'); laplace(sin(t), t, s); inverse_laplace(1/(s^2+1), s, t) Modular arithmetic: Mod(17, 5); power_mod(3, 100, 97) Recurrences: var('n'); f = function('f'); desolve_rec(f(n+2)-f(n+1)-f(n), f, [0, 1]) Continued fractions: continued_fraction(pi).convergents()[:10] Number fields: K. = NumberField(x^3 - 2); K.class_number() Any multi-step work that builds on values defined earlier in the same session, since the dedicated tools cannot see them.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`code`	Yes	SageMath code to execute
`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
`timeout`	No	Override the evaluation timeout in seconds
`want_latex`	No	Return LaTeX representation when possible
`capture_stdout`	No	Capture stdout emitted by Sage code

Output Schema

TableJSON Schema

Name	Required	Description
`latex`	No	LaTeX serialization of the result when requested and supported.
`result`	No	String representation of the expression result if available.
`stdout`	No	Captured stdout emitted during execution.
`elapsed_ms`	Yes	Wall-clock execution time in milliseconds.
`result_type`	Yes

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'."

Changed1 schema field changedv0.5.0Aug 14, 2026

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.6/5.0

Behavior5/5

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

Annotations declare the write/open/idempotency profile, and the description adds the sandbox policy the agent cannot infer: deny-by-default execution with imports, external CAS interfaces, and file/display/persistence calls refused. It also discloses the namespace-persistence behavior that fundamentally changes how the tool is used, plus the fact that dedicated tools cannot see session state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly: purpose, then the LAST RESORT directive, then the overriding exception, then the routing lists. It is long, but the bulk is a routing index that directly serves tool selection; the trade-off is length rather than wasted sentences.

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?

An output schema exists, so return values need not be explained, and the description still supplies everything else an agent needs: execution policy, session persistence, timeout/latex flags' existence via schema, and precise routing versus ~35 siblings. Nothing material is missing for a code-execution tool of this complexity.

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% and parameter docs already cover code, session workspace semantics, timeout, want_latex, and capture_stdout. The description adds session-state context ('variables persist', 'builds on values defined earlier in the same session') but no per-parameter syntax or format guidance. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource ('Run SageMath code') plus the scope that matters most ('in a persistent session; variables persist across calls'). It then explicitly positions itself against its many siblings ('LAST RESORT for a single self-contained calculation'), so an agent can distinguish it from evaluate_sage_streaming, calculate_expression, and the domain-specific tools without opening any schema.

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?

Names the when-not condition ('only for what those do not cover') and enumerates the alternative tools by category, then carves out the one case that overrides the steer: multi-step work where a built object must be revisited, because dedicated tools evaluate in a fresh namespace. Concrete example snippets show exactly what qualifies.

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