Allows execution of Mathematica code and verification of mathematical derivations via the Wolfram Language.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mathematica MCP Server Calculate the integral of sin(x) from 0 to pi"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This repository contains a Model Context Protocol (MCP) server that allows MCP clients (like Cursor) to execute Mathematica code via wolframscript and verify mathematical derivations.
This server acts as a bridge, enabling applications that support MCP to leverage the power of a local Mathematica installation for tasks such as:
Performing complex mathematical calculations.
Verifying mathematical derivation steps provided by humans or AI models.
Generating LaTeX or Mathematica string representations of expressions.
Related MCP server: scicompute-mcp
Mathematica must be installed on your system.
The wolframscript command-line utility must be available in your system's PATH. You can test this by running wolframscript -help in your terminal.
Node.js (Recommended: v16 or later, as inferred from tsconfig.json target ES2022).
Clone the repository:
git clone <repository-url>
cd <repository-directory>Install dependencies:
npm installBuild the server:
npm run buildThis command compiles the TypeScript source code from src/ into JavaScript in the build/ directory and makes the main script executable.
To start the MCP server, run the following command in your terminal:
node build/index.jsThe server will start and listen for connections from MCP clients via standard input/output (stdio). Keep this terminal window open while you intend to use the server.
For more robust deployments, consider using a process manager like pm2 to run the server in the background and manage restarts.
MCP clients generally discover and communicate with running MCP servers. The exact configuration steps can vary depending on the client application.
General Steps:
Start the Mathematica MCP Server: Ensure the server is running in a terminal:
node build/index.jsConfigure Your MCP Client: Add the server to your client's configuration. This often involves editing a JSON settings file. See client-specific instructions below.
Restart Your MCP Client: After starting the server or changing configuration, restart your client application to ensure it detects the Mathematica server.
Client-Specific Configuration:
Cline:
According to the Cline MCP Server Development Protocol, you typically configure servers in a settings file (often settings.json within the Cline configuration directory). You would add an entry like this:
{
"mcpServers": {
"mathematica-server": {
"command": "node",
"args": ["/full/path/to/mcp-server-mathematica/build/index.js"], // Replace with the actual absolute path
"disabled": false,
"autoApprove": [] // Optional: Add tool names to auto-approve
}
// ... other servers ...
}
}Replace /full/path/to/mcp-server-mathematica/build/index.js with the absolute path to the built index.js file on your system.
Cursor:
Cursor might require editing a specific settings file, potentially like ~/Library/Application Support/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json (though this path might change). The structure would be similar to the Cline example above.
Other Clients (e.g., Claude Desktop):
Consult the documentation for your specific MCP client. Look for sections on "MCP Servers," "Tool Configuration," or "External Tools." The configuration generally involves specifying the command (node), the path to the server script (build/index.js), and potentially environment variables if needed.
The server exposes the following tools to MCP clients:
execute_mathematicaExecutes arbitrary Mathematica code and returns the result.
Input Schema:
{
type: "object",
properties: {
code: {
type: "string",
description: "Mathematica code to execute"
},
format: {
type: "string",
description: "Output format (text, latex, or mathematica)",
enum: ["text", "latex", "mathematica"],
default: "text"
}
},
required: ["code"]
}Example Usage (Client Request):
Natural Language: "Calculate the integral of x^2 from 0 to 1 using Mathematica and format as LaTeX"
Direct Tool Call:
{
"tool_name": "execute_mathematica",
"arguments": {
"code": "Integrate[x^2, {x, 0, 1}]",
"format": "latex"
}
}verify_derivationVerifies a sequence of mathematical expressions to check if each step logically follows from the previous one using Simplify[prev == current].
Input Schema:
{
type: "object",
properties: {
steps: {
type: "array",
description: "Array of mathematical expressions (as strings) representing steps in a derivation. Requires at least two steps.",
items: {
type: "string"
}
},
format: {
type: "string",
description: "Output format for the verification report (text, latex, or mathematica)",
enum: ["text", "latex", "mathematica"],
default: "text"
}
},
required: ["steps"]
}Example Usage (Client Request):
Natural Language: "Verify this derivation: ['x^2 - y^2', '(x-y)(x+y)']"
Direct Tool Call:
{
"tool_name": "verify_derivation",
"arguments": {
"steps": [
"x^2 - y^2",
"(x-y)*(x+y)"
],
"format": "text"
}
}Server Not Found/Not Responding:
Ensure the server is running in a terminal (node build/index.js).
Check if wolframscript is installed and accessible in your PATH (wolframscript -help).
Restart your MCP client application.
Check the client's MCP configuration.
Tool Errors:
Check the server's terminal output (stderr) for logs and error messages from wolframscript.
Verify the syntax of the Mathematica code or steps provided.
Ensure the steps array for verify_derivation has at least two elements.
Mathematica Issues: Ensure your Mathematica installation is licensed and working correctly.
src/: TypeScript source code for the server.
build/: Compiled JavaScript output (generated by npm run build).
package.json: Project metadata and dependencies.
tsconfig.json: TypeScript compiler configuration.
Execute Mathematica code and return the result
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Mathematica code to execute | |
| format | No | Output format (text, latex, or mathematica) | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks disclosure of behavioral traits like environment constraints, side effects, security implications, or output handling. For a code execution tool, critical details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too brief. It lacks structure and fails to provide essential details while being overly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no output schema and moderate complexity (2 params, code execution). Description does not cover return values, execution behavior, or constraints, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema; it doesn't explain code capabilities or format nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool executes Mathematica code and returns the result, with specific verb 'execute' and resource 'Mathematica code'. It distinguishes from sibling 'verify_derivation' by focusing on execution rather than verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like verify_derivation. Missing context such as prerequisites, safety considerations, or when execution is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a mathematical derivation step by step
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Array of mathematical expressions representing steps in a derivation | |
| format | No | Output format (text, latex, or mathematica) | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'step by step' but does not explain what verification entails, whether it checks mathematical correctness, or what happens on failure. Key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 7 words and front-loaded with the action. It wastes no words, but might be too brief for complex guidance. Still, it earns a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (verification) and lack of output schema, the description should explain what the tool returns or how correctness is indicated. It does not address return values, success criteria, or error handling, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear explanations for both parameters. The description adds no extra meaning beyond the schema, so it meets baseline expectations but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Verify a mathematical derivation step by step', specifying the action (verify) and resource (mathematical derivation). However, it does not explicitly differentiate from the sibling tool 'execute_mathematica', which could cause confusion, but the purpose is still clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'execute_mathematica'. There is no mention of prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0execute_mathematicaverify_derivationThe two tools have clearly distinct purposes: execute_mathematica runs arbitrary code, while verify_derivation checks mathematical derivations. No overlap in functionality.
Both tools follow a consistent verb_noun pattern (execute_mathematica, verify_derivation) with snake_case, which is predictable and clear.
With only 2 tools, the server feels underpowered for a general Mathematica interface. It may be acceptable for a very narrow use case, but lacks the breadth expected from a computation server.
There are obvious gaps: no tools for plotting, data import/export, symbolic manipulation, or notebook management. The tool surface is severely incomplete for typical Mathematica workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Math.js MCP — wraps the mathjs.org API (free, no auth)
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Integrates Wolfram Language and Wolfram|Alpha accessing curated data and sophisticated algorithms.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/texra-ai/mcp-server-mathematica'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
