Which integrations are available for this server?

Enables execution of Wolfram Language code in a secure, session-based environment, with tools for session initialization, code execution, and resource management. Provides tools for creating sessions, executing Wolfram Language code, and managing session resources within a Mathematica kernel, enabling secure, session-based interaction with Wolfram Language.

How do I use Mathematica MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mathematica MCP Server solve the equation x^2 + 3x - 4 = 0" 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.

Mathematica MCP Server

by aac6fef

Overview Schema Related Servers Score Discussions

Python

Local

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 solve the equation x^2 + 3x - 4 = 0"

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.

Mathematica MCP Server

This project provides a Model Context Protocol (MCP) server for interacting with a Wolfram Mathematica kernel. It allows Large Language Models (LLMs) to execute Wolfram Language code in a secure, session-based environment.

The animalid folder contains a simple tool for generating unique, animal-based identifiers. Since LLMs often fail to copy UUIDs correctly, this tool replaces them with animal-themed IDs that are more likely to be transcribed accurately.

Tools Provided

create_mathematica_session: Initializes a new Wolfram Language session and returns a unique session ID.
execute_mathematica_code: Executes Wolfram Language code within a specified session.
close_mathematica_session: Terminates a session and releases its resources.

Related MCP server: Wolfram Alpha MCP Server

Prerequisites

Python 3.10 or higher.
uv Python package manager. (Installation guide)
A local installation of the Wolfram Engine or Mathematica. The wolframclient library requires this to function.

Installation & Setup

Set the Security Key:
This server uses a secret key to generate secure session IDs. You must set this as an environment variable.
```
export ANIMALID_SECRET_KEY='your-super-secret-and-long-key-here'
```
Note: Do not use a weak key or hardcode it in the script.

Usage

To use this server, you need to connect it to an MCP-compatible client, such as Claude for Desktop.

Configure the MCP Client:
Open your client's MCP configuration file (e.g., claude_desktop_config.json for Claude for Desktop) and add the following server configuration.
Important: Replace /path/to/your/project/my_mcp with the absolute path to this project's directory on your system.
```
{
  "mcpServers": {
    "mathematica": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/your/project/my_mcp",
        "run",
        "wolfram_mathematica.py"
      ],
       "env": {
            "ANIMALID_SECRET_KEY": "default-secret-key-for-dev"
          }
    }
  }
}
```
You may need to use the full path to the uv executable in the command field if it's not in your system's PATH. You can find it by running which uv (macOS/Linux) or where uv (Windows).

screenshot

Available Tools

3 tools

close_mathematica_sessionA

Terminates a specific Wolfram Language session and releases all associated resources.

It is good practice to call this tool when you are finished with a session to free up system memory and kernel licenses. Once a session is closed, its ID can no longer be used.

Args: session_id: The unique identifier of the session you wish to close. This must be an ID from an active, open session. Example: 'bee-sloth-auk-mole'.

Returns: A confirmation message indicating that the session was successfully closed.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well: it discloses that the tool is destructive (terminates session, releases resources), has irreversible effects (ID becomes unusable), and has system-level implications (frees memory and licenses). It doesn't mention error handling or permissions, but covers core behavioral traits adequately for a termination tool.

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?

Perfectly structured and front-loaded: first sentence states core purpose, second provides usage guidance, third explains irreversible consequence. The Args/Returns sections are clearly labeled but not part of the description text being scored. Every sentence earns its place with no redundancy.

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 1 parameter with 0% schema coverage and no annotations, the description provides complete context: purpose, usage guidelines, parameter semantics, and behavioral implications. The output schema exists, so return values needn't be explained in the description. This is comprehensive for a simple termination tool.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for the single parameter: explains what session_id represents ('unique identifier of the session'), constraints ('must be an ID from an active, open session'), and includes a concrete example ('bee-sloth-auk-mole'). This adds significant value beyond the bare schema.

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 clearly states the specific action ('Terminates a specific Wolfram Language session') and resource ('releases all associated resources'), distinguishing it from sibling tools like create_mathematica_session (creates) and execute_mathematica_code (runs code). The verb 'terminates' is precise and unambiguous.

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?

Explicitly states when to use ('when you are finished with a session to free up system memory and kernel licenses') and when not to use ('Once a session is closed, its ID can no longer be used'), with clear alternatives implied (use create_mathematica_session for new sessions or execute_mathematica_code for active ones). The guidance is practical and actionable.

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

create_mathematica_sessionA

Creates and initializes a new, isolated Wolfram Language session.

This tool is the first step for any Mathematica-related task. It returns a unique, secure session identifier (e.g., 'fox-wolf-bear-lion') that you MUST use in subsequent calls to 'execute_code' and 'close_session'.

Each session is completely independent and maintains its own state (variables, function definitions, etc.).

Returns: A string containing a success message and the unique session ID. Example: "Session created successfully. Your session ID is: bee-sloth-auk-mole"

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the session is 'isolated' and 'independent' with its own state, returns a 'unique, secure session identifier', and includes an example output. However, it lacks details on potential errors, session limits, or initialization time.

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?

The description is well-structured and front-loaded with the core purpose, followed by usage context, behavioral details, and output example. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 simplicity (0 parameters, no annotations, but with an output schema), the description is complete. It explains the purpose, usage workflow, behavioral isolation, and provides an output example, compensating adequately for the lack of annotations while leveraging the output schema for return value details.

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?

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter-specific information (as none exist), which is appropriate and doesn't detract from the high schema coverage.

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 clearly states the specific action ('Creates and initializes') and resource ('new, isolated Wolfram Language session'), distinguishing it from siblings like 'close_mathematica_session' and 'execute_mathematica_code'. It explicitly defines this as the first step for Mathematica tasks, establishing its unique role.

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 provides explicit guidance on when to use this tool ('first step for any Mathematica-related task') and how it relates to alternatives ('MUST use in subsequent calls to 'execute_code' and 'close_session''). It clearly defines the workflow context without misleading exclusions.

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

execute_mathematica_codeA

Executes a string of Wolfram Language code within a specific, active session.

To use this tool, you must provide a valid 'session_id' obtained from a previous call to 'create_session'. The code will be executed in the context of that session, meaning it can access variables and functions defined in previous calls within the same session.

Args: session_id: The unique identifier for an active session, provided by 'create_session'. Example: 'bee-sloth-auk-mole'. code: A string containing the Wolfram Language code to be executed. The code should be syntactically correct. Example 1 (simple calculation): 'Total[Range[100]]' Example 2 (symbolic computation): 'Solve[x^2 - 5x + 6 == 0, x]' Example 3 (data visualization): 'Plot[Sin[x], {x, 0, 2 Pi}]'

Returns: The direct result of the code execution from the Wolfram Engine. The data type can vary (e.g., integer, list, string, or a complex expression). For plots, it may return a representation of the graphics object.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes
`session_id`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well by explaining session context persistence ('can access variables and functions defined in previous calls'), execution constraints ('code should be syntactically correct'), and return value variability. It doesn't mention potential errors, timeouts, or resource limits, keeping it from a perfect score.

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?

Well-structured with a clear opening sentence stating purpose, followed by usage guidelines, then detailed parameter explanations with examples, and finally return value information. Every sentence adds value with no redundancy.

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?

For a 2-parameter tool with no annotations and no output schema, the description provides excellent coverage of purpose, usage, parameters, and return behavior. It could be slightly more complete by mentioning potential error cases or execution limits, but it's very thorough for the given context.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: 'session_id' is explained as a unique identifier from 'create_session' with an example format, and 'code' is described with syntax requirements and three concrete examples showing different use cases.

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 clearly states the specific action ('Executes a string of Wolfram Language code') and resource ('within a specific, active session'), distinguishing it from sibling tools like 'create_mathematica_session' and 'close_mathematica_session' which handle session lifecycle rather than code execution.

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?

Explicitly states when to use ('within a specific, active session') and prerequisites ('must provide a valid session_id obtained from a previous call to create_session'), and distinguishes from alternatives by specifying the session context requirement.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: create_mathematica_session initiates sessions, execute_mathematica_code runs code within them, and close_mathematica_session terminates them. The descriptions reinforce these distinct roles, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with 'mathematica' as a prefix (create_mathematica_session, execute_mathematica_code, close_mathematica_session). The naming is predictable and enhances readability across the set.

Tool Count5/5

With 3 tools, this server is well-scoped for its purpose of managing Mathematica sessions and code execution. Each tool earns its place by covering the essential lifecycle: create, execute, and close, without unnecessary bloat or gaps.

Completeness5/5

The tool set provides complete CRUD/lifecycle coverage for the domain of Wolfram Language sessions: creation, execution, and termination. There are no obvious gaps, as agents can manage sessions end-to-end without dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.wolfram
Integrates Wolfram Language and Wolfram|Alpha accessing curated data and sophisticated algorithms.
Search Knowledge & Memory
32
mcp-server
ai.cdbx
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Code Execution Developer Tools
1
SentinelX MCP
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
25
Sugra API A
ai.sugra
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search Open Data Data Platforms
1122

Related MCP Servers

WolframAlpha LLM MCP Server
Search Developer Tools
Garoth
F
license
C
quality
D
maintenance
Enables querying WolframAlpha's LLM API for natural language questions, providing structured and simplified answers optimized for LLM consumption.
Updated 2 years ago (2025-02-25 23:30 UTC)
3
55
Wolfram Alpha MCP Server
Search Research & Data
henryhawke
F
license
A
quality
D
maintenance
Provides access to Wolfram Alpha's computational knowledge engine for mathematical calculations, scientific computing, data analysis, and factual information through natural language queries.
Updated a year ago (2025-06-18 16:05 UTC)
2
6
Mathematica MCP Server
Code Execution Education & Learning Tools Research & Data
texra-ai
A
license
B
quality
D
maintenance
Enables MCP clients to execute Mathematica code via wolframscript and verify mathematical derivations.
Updated 10 months ago (2025-10-19 22:13 UTC)
2
24
MIT
mathematica-mcp
Code Execution AI & Machine Learning Autonomous Agents
AbhiRawat4841
A
license
C
quality
A
maintenance
Enables AI agents to run Mathematica code, control live notebooks, and verify results through natural language.
Updated 2 months ago (2026-07-06 11:07 UTC)
82
48
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aac6fef/mathematica_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server