Wolfram Documentation Interface MCP Service

Configuration and Execution

Developed utilizing the mcp-python-sdk.

[!ATTENTION]
Users on legacy FastMCP implementations should transition immediately; FastMCP services are now officially deprecated.

Prerequisites: Install dependencies via pip install -r requirements.txt and ensure that the Wolfram Engine (or accessible wolframscript binary, potentially via the free Wolfram Engine for Developers) is present on the system path.

To initialize the local server instance, execute: mcp dev path/to/mcp-mma-doc.py

For system integration (e.g., with Claude/cline), install using: mcp install path/to/mcp-mma-doc.py or manually configure your claude/cline settings:

"mathematica-docs": { "command": "uv", "args": [ "run", "--with", "mcp", "mcp", "run", "/path/to/mcp-mma-doc.py" ] }

[!CAUTION] On specific Linux/macOS environments running Claude-desktop, leveraging uv with mcp may cause instability. A direct invocation method is recommended as a fallback:

"mathematica-docs": { "command": "/path/to/mcp", "args": [ "run", "/path/to/mcp-mma-doc.py" ] }

Where /path/to/mcp is derived from executing which mcp in your terminal.

Specifying WolframScript Location

If wolframscript is not discoverable in the standard system PATH, its location can be explicitly defined via an environment variable:

Environment variable setup: bash export WOLFRAMSCRIPT_PATH="/usr/bin/wolframscript"

Alternatively, integrate it directly into the MCP configuration as an env directive:

"mathematica-docs": { "command": ..., "args": ..., "env": { "WOLFRAMSCRIPT_PATH": "/usr/bin/wolframscript" } }

Available Capabilities

The plugin exposes the following operational routines:

• retrieve_function_details: Supports retrieval for factory methods, functions belonging to installed packages, and functions provided by external add-ons.
• Standard query syntax: retrieve_function_details("Plot")
• Querying package-specific symbols: retrieve_function_details("WeightSystem", packages=["LieART"])
• Querying symbols requiring addon loading: retrieve_function_details("FCFeynmanParametrize", packages=["FeynCalc"], load_addons=["FeynArts"])
• enumerate_package_symbols: Lists all accessible symbols or functions within a specified package namespace.
• Basic invocation: enumerate_package_symbols("FeynCalc")

Observed Limitations

• Ignore Console Noise: If diagnostic output such as INFO Processing request of type __init__.py:431 ListToolsRequest appears in cline logs, this can be safely disregarded. This noise results from the tool list parsing overlapping with standard console debugging output, a limitation inherent to the current python-sdk structure. Functionality remains unaffected.
• Documentation Formatting: Certain Mathematica documentation pages feature intricate formatting that basic regular expressions struggle to sanitize. Instruct the language model to prioritize displaying content strictly in InputForm notation to avoid interference from complex visual styling.

Visual References

[WIKIPEDIA Snippet on XMLHttpRequest (XHR)]

XMLHttpRequest (XHR) is a JavaScript object API enabling the transmission of HTTP requests from a web browser to a server. These methods allow web applications to initiate server communications post-page load and receive subsequent data. XHR is foundational to Ajax programming. Before its advent, server interaction predominantly relied on standard hyperlink navigation or form submissions, which typically necessitated a full page refresh.

== Genesis == Microsoft Outlook developers conceptualized the mechanism behind XMLHttpRequest around 2000. It first materialized in Internet Explorer 5 (1999), though initially utilizing ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP") instead of the standardized identifier. By Internet Explorer 7 (2006), all mainstream browsers had adopted the XMLHttpRequest identifier.

The XMLHttpRequest identifier is now the established standard across major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Process === The World Wide Web Consortium (W3C) released the first Working Draft specification for the XMLHttpRequest object on April 5, 2006. A Level 2 specification followed on February 25, 2008, introducing capabilities for event progress monitoring, cross-site data fetching, and byte stream handling. By the close of 2011, Level 2 features were merged back into the primary specification. Development transitioned to WHATWG at the conclusion of 2012, which now maintains the standard as a living document leveraging Web IDL.

== Operational Flow == Generating a server request via XMLHttpRequest typically involves these programming stages:

1. Instantiation: Create an XMLHttpRequest object via its constructor.
2. Configuration: Invoke the "open" method to define the request method (GET/POST, etc.), target URI, and whether the operation should be synchronous or asynchronous.
3. Listener Setup (Async Only): For asynchronous operations, register an event listener to handle state transitions.
4. Initiation: Trigger the request execution by calling the "send" method.
5. Response Handling: Monitor state changes via the registered listener. Upon completion (state 4, "done"), response data is typically accessible via the "responseText" property. Beyond these fundamentals, XHR offers mechanisms for request control: custom headers can dictate server behavior; data can be transmitted within the "send" call payload; responses can be immediately parsed into JavaScript objects (e.g., JSON) or streamed incrementally; and requests can be terminated early or set with timeouts.