SageMath MCP Server

Evaluate Sage

evaluate_sage

Execute SageMath code in a persistent session to build and explore complex mathematical objects across multiple calls when dedicated tools cannot handle the workflow.

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

Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: session persistence across calls, deny-by-default restrictions, refusal of imports/external CAS/file/display/persistence calls, and the contrast that dedicated tools run in a fresh namespace. This adds substantial operational context that annotations alone do not provide, and it does not contradict any annotation.

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?

The description is long, but every section earns its place: core behavior, routing guidance, categorized alternatives, and worked examples. It is well-structured and front-loaded with the most important facts before the lengthy lists. The length is justified by the large sibling set and the need to disambiguate.

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 rich sibling set, and the existing output schema, the description covers everything an agent needs: restrictions, persistence semantics, session selection, timeout override, and detailed routing examples. The presence of an output schema means return-value details need not be repeated here.

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?

Schema coverage is 100%, so the schema already documents all five parameters. The description still adds meaning by showing valid SageMath code examples, explaining that the default session persists, and clarifying when session handles are bearer credentials. This goes beyond the schema's basic property descriptions.

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: 'Run SageMath code in a persistent session; variables persist across calls.' It also differentiates itself from the many dedicated sibling tools by explicitly framing itself as the LAST RESORT for self-contained calculations and the right choice for persistent multi-step workflows. The purpose is unmistakable and not confused with any sibling.

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?

The description gives explicit when-to-use and when-not-to-use guidance: dedicated tools should be preferred for single calculations because they validate arguments and return typed results, while evaluate_sage should be used for multi-step work requiring state persistence. It even lists alternate tools by category and supplies concrete examples of cases not covered by those tools.

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