SageMath MCP Server

Matrix Multiply

matrix_multiply

Idempotent

Multiply two matrices and return the product as nested lists, enabling quick linear algebra calculations.

Instructions

Multiply two matrices and return the result as nested lists

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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
`matrix_a`	Yes	Left matrix (rows of numbers). Integers stay exact; pass values from 2^53 up as decimal strings, e.g. "9007199254740993".
`matrix_b`	Yes	Right matrix (rows of numbers). Integers stay exact.

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

Changed7 schema fields changedv0.5.0Aug 14, 2026

changedInput schema / properties / matrix_a / description

Previous value: -"Left matrix (rows of numbers)"New value: +"Left matrix (rows of numbers). Integers stay exact; pass values from 2^53 up as decimal strings, e.g. \"9007199254740993\"."

addedInput schema / properties / matrix_a / items / items / anyOf

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

removedInput schema / properties / matrix_a / items / items / type
```
Removed value: -"number"
```

changedInput schema / properties / matrix_b / description

Previous value: -"Right matrix (rows of numbers)"New value: +"Right matrix (rows of numbers). Integers stay exact."

addedInput schema / properties / matrix_b / items / items / anyOf

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

removedInput schema / properties / matrix_b / items / items / type
```
Removed value: -"number"
```

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

B3.2/5.0

Behavior3/5

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

Annotations already convey idempotency and non-destructive behavior, and the description adds that the result is returned as nested lists. It does not disclose behavior on dimension mismatch, session state changes, or error handling, but given the annotation coverage the description is adequate, not rich.

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 a single sentence with no filler and front-loads the action. It is appropriately concise, though it is thin on usage and edge-case details; this keeps it from a perfect score but it is not verbose or redundant.

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

Completeness3/5

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

For a simple operation with a fully documented schema and an output schema, the description plus annotations are mostly sufficient for calling the tool. However, it omits any mention of matrix dimension compatibility and provides no help distinguishing this tool from sibling Sage operations, leaving a meaningful gap.

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?

The schema already documents all parameters thoroughly, including session behavior and exact integer handling, with 100% description coverage. The tool description only repeats that two matrices are multiplied and adds no parameter-level meaning beyond the schema, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Multiply') and resource ('two matrices'), and states the output shape ('nested lists'). It clearly identifies the operation, but it does not explicitly differentiate itself from sibling tools like matrix_operation or evaluate_sage, so it falls one step short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives, and no mention of matrix_operation or evaluate_sage as possible substitutes. The intended use is only implied by the verb and object, leaving the agent to infer when this dedicated matrix multiplication tool is the right choice.

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