Add Licensed Wolfram Checks to Claude Code with mma-mcp

This seed is useful, but only if it is rescued from the wrong frame. The everyday failure is familiar: an AI coding assistant hand-waves algebra, invents confidence about a numerical result, or produces a plot explanation that no one can reproduce. The answer is not to trust the model harder. The answer is to give it a narrow, reviewable computation boundary.

The original topic sounded like a broad promise to give AI assistants more computation. That is too vague. The real article is about whether a developer should let Claude Code, Codex-adjacent MCP clients, or web AI clients call a local Wolfram kernel at all.

mma-mcp deserves publication because its own documentation gives a concrete adoption boundary. It is an unofficial MCP server for licensed individual Wolfram Engine or Mathematica users. It exposes two tools, supports stdio and HTTP, filters Wolfram Language expressions before the kernel sees them, and lets HTTP clients use per-role policy. That is not a press release. It is a useful pattern for adding specialist computation to an agent workflow without pretending the kernel is just another harmless API.

Why this seed is worth saving

Wolfram access can change the shape of an AI coding session. A model that is guessing algebra, plotting behavior, or numerical stability can ask for exact computation instead of inventing confidence. For a Codex or Claude Code workflow, that matters when a task crosses into symbolic derivation, parameter search, graph math, statistics, geometry, or plot generation. The article becomes valuable when it answers the engineering question: what must be true before an agent can call that kernel safely?

The license boundary comes first

The README is explicit that mma-mcp is unofficial, independent, and does not ship Wolfram binaries, activation keys, license files, or proprietary materials. It is meant for a licensed individual invoking their own locally installed kernel. That statement should be the first adoption test. If the use case is team-wide sharing, a hosted computation endpoint, or third-party redistribution of Wolfram access, this is the wrong tool. The safe editorial framing is personal local use under the user's license, not general compute-as-a-service.

The tool surface is deliberately small

mma-mcp exposes evaluate for text results and evaluate_image for PNG output. That small surface is a strength. Instead of giving an AI client a menu of many special-purpose operations, the server routes Wolfram Language through two universal MCP tools and puts policy around expression execution. For coding agents, this means the review target is clear: what expression was sent, which client sent it, which role allowed it, what timeout applied, and whether the result was text or an image artifact.

Start with stdio, not public HTTP

The README includes a .mcp.json shape for Claude Code and VS Code: run uv with --directory /path/to/mma-mcp run mma-mcp. That should be the first path for a local coding setup because the transport stays inside the developer machine and avoids account, TLS, and network policy questions. HTTP transport exists, and the command is straightforward: uv run mma-mcp serve --transport http --host 127.0.0.1 --port 8000. But HTTP is a different project. Once a kernel can be reached over a socket, auth, reverse proxy behavior, timeout policy, logs, and client identity become part of the quality bar.

The security model is useful but not magic

The architecture document makes the right call by filtering expressions before they reach the Wolfram kernel. The project extracts symbols in Python and checks them against blacklist or whitelist policy. Default blacklist mode blocks dangerous groups such as system execution, file I/O, networking, dynamic evaluation, and system mutation. Whitelist mode is stricter: only named safe groups are allowed. This is useful because Wolfram Language is an execution environment, not just a calculator. It is also not a proof of perfect sandboxing. The article should tell readers to treat the filter as a front-door control, then pair it with roles, resource limits, local binding, and verification.

Capability groups make policy review concrete

The docs describe 29 capability groups, with 22 safe groups and 7 dangerous groups. The project generates group JSON files from the user's local Wolfram kernel with uv run mma-mcp setup, and recommends uv run mma-mcp setup --force after a Wolfram Engine upgrade. That detail is important. A reviewer can ask a concrete question before enabling a client: should this role be allowed visualization, calculus, graph theory, or optimization? Should it ever be allowed file read, file write, networking, or dynamic evaluation? Without those group names, the policy review becomes hand-waving.

Client roles are the reason HTTP can be discussed

The security policy describes multi-client OAuth 2.1, legacy Bearer token mode, password hashing with hashlib.scrypt, per-role tool permissions, per-role resource limits, and contextvar-based identity propagation. The adoption point is not that every user should expose mma-mcp to web clients. It is that if a user insists on Claude.ai, ChatGPT, or another HTTP MCP client, the server has a vocabulary for separating clients. Claude can have one role, ChatGPT another, and a local CLI another. Each role can have its own allowed tools, symbol policy, timeout, and result size.

The kernel pool is the real isolation story

The architecture document describes a KernelPool with independent Wolfram kernel workers. Each tool call acquires a worker exclusively, runs in a temporary context, cleans up, and returns the worker to the pool. Workers can restart periodically and idle workers can be reclaimed. That is a better story than pretending one shared kernel namespace is enough. For an AI workflow, it means a bad expression should not casually bleed state into the next client call. The limitation still matters: system-level mutations must be blocked before execution, and periodic restart is a backstop, not a reason to allow broad dangerous groups.

Long computations need client-specific expectations

The README's compatibility table is a good example of honest documentation. Claude.ai is listed as supporting long computations through progressToken and server heartbeat. ChatGPT may time out around 60 seconds because it does not send progressToken. Claude Desktop and Claude Code local stdio are marked as not tested. That last note should stay in the article. A Claude Code team should not assume production readiness from the config snippet alone. They should run a first-use checklist and record actual behavior in their environment.

A practical first run

Use a local machine where Wolfram Engine or Mathematica is already installed and licensed. Clone the repo, run uv sync, install the headless graphics libraries only if image export on a server is needed, then run uv run mma-mcp init and uv run mma-mcp setup. Start with uv run mma-mcp serve over stdio and add the .mcp.json entry to the target coding client. Test with harmless expressions first: arithmetic, symbolic simplification, a small plot, and an intentionally blocked file or network operation. The test should prove both capability and denial behavior.

Use this local command sequence

A first pass should be boring and repeatable. Run git clone https://github.com/siqiliu-tsinghua/mma-mcp.git, cd mma-mcp, and uv sync. Confirm the kernel exists with which WolframKernel or set the kernel path in mma_mcp.toml. Generate the config with uv run mma-mcp init. Generate local security groups with uv run mma-mcp setup. Start the server with uv run mma-mcp serve. Only after that should the coding client be connected. If any step fails, fix the local Wolfram or Python environment before involving Claude Code or another agent.

Add the client entry explicitly

For Claude Code or VS Code stdio, the README's shape is a small .mcp.json block: server name mma-mcp, command uv, and args --directory, /path/to/mma-mcp, run, mma-mcp. Put the absolute project path in the config rather than relying on the current working directory. Restart the client, ask it to list available MCP tools, and confirm that only evaluate and evaluate_image appear. If more tools appear, the local checkout or config has drifted from the reviewed source.

Run acceptance tests before trusting results

Use four checks before letting the agent rely on Wolfram output. First, run a simple exact expression and compare it with a known answer. Second, run a symbolic simplification that would be awkward to do by hand and save the expression plus result in the task notes. Third, request a tiny plot through evaluate_image only if image output is needed. Fourth, ask for a file, network, system command, or dynamic evaluation operation that the policy should block. The adoption is not complete until the allowed path and denied path are both observed.

Check setup failures in this order

Most early failures should be handled before blaming the AI client. If uv sync fails, resolve the Python 3.11 or uv environment first. If which WolframKernel is empty, set the kernel path in mma_mcp.toml before starting the server. If uv run mma-mcp setup fails, confirm that the local Wolfram installation is licensed and can start outside MCP. If evaluate_image fails on a headless Linux box, install the graphics libraries from the README or deployment guide. If the client shows no tools, recheck the absolute path in .mcp.json, restart the client, and confirm the server command works in a terminal.

Keep an audit note for every task

When mma-mcp contributes to a code decision, record the expression, result, client, policy mode, and any blocked attempt in the issue, pull request, or task log. That habit prevents a subtle failure mode: the model cites 'Wolfram says so' without preserving the actual computation. For production code review, the computed evidence should be inspectable the same way benchmark output, SQL query output, or a failing test log is inspectable.

Review mma_mcp.toml like code

The config is part of the product surface. Review [kernel] for the kernel path and timeout, [server] for transport and host, [security] for blacklist or whitelist policy, [tools] for exposed tool names, [tls] for domain settings, and [auth] for client identity. In a first local test, keep transport on stdio and leave HTTP out. In a stricter test, switch from blacklist to whitelist for the role that the AI coding client uses, then add only the groups needed for the current repository task.

When HTTP is justified

HTTP is justified only when the client cannot use local stdio or when the user intentionally wants access from web or mobile AI clients. The deployment guide points toward a safer shape: bind mma-mcp to 127.0.0.1, put Caddy in front for TLS, generate a Caddyfile from config, and enable authentication. For a personal server, also use a dedicated runtime user, keep credentials outside the repo, and inspect the generated service files. If this sounds like too much ceremony, that is the signal to stay on stdio.

Where not to use it

Do not use mma-mcp as a shared team Wolfram service unless the license and security model explicitly permit that use. Do not expose HTTP on a public interface before auth, TLS, role policy, and denial tests are complete. Do not enable file, network, dynamic evaluation, or system mutation groups because a model asked for them once. Do not route unreviewed user prompts from a public app into the kernel. Do not assume Claude Code compatibility is proven; the README says local stdio for Claude Desktop and Claude Code is not tested.

The Codex angle

Codex users should care because this is the right shape for specialist tools. The agent does not need every library embedded in its prompt. It needs a narrow MCP boundary, source-backed instructions, local configuration, and a verification harness. A math-heavy repository could use mma-mcp during design review, benchmark analysis, numerical debugging, or visual inspection. The same team should keep the Wolfram calls visible in logs or artifacts so that the final code review can separate model reasoning from computed evidence.

Save mma-mcp as a local Wolfram kernel boundary article. It is useful when a licensed individual needs symbolic, numeric, or visualization help inside an MCP-based coding workflow; it should be skipped when the desired use is shared compute, untrusted public prompting, or HTTP exposure without role policy and denial tests.

Practical takeaway

Start with a licensed local Wolfram install and stdio transport. Run uv run mma-mcp init, uv run mma-mcp setup, and uv run mma-mcp serve; add the .mcp.json entry; test harmless expressions and blocked dangerous operations; document actual Claude Code or Codex-client behavior; regenerate groups after kernel upgrades; move to HTTP only after auth, TLS, role limits, local binding, and source-visible logs are in place.