Wolfram Alpha MCP Server
Provides access to Wolfram Alpha's computational knowledge engine for mathematical calculations, scientific computing, geographic information, data analysis, and factual queries through natural 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., "@Wolfram Alpha MCP Serverwhat's the derivative of x^2 + 3x?"
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.
Wolfram Alpha MCP Server
A Model Context Protocol (MCP) server that provides access to Wolfram Alpha's computational knowledge engine through natural language queries.
Features
š§® Mathematical Calculations: Solve equations, perform complex calculations, and work with mathematical formulas
š¬ Scientific Computing: Access physics, chemistry, and scientific data
š Geographic Information: Get information about countries, cities, and geographic features
š Knowledge Base: Query facts about history, art, astronomy, and more
š Data Analysis: Generate plots, analyze datasets, and perform statistical calculations
š Multiple Interpretations: Handle ambiguous queries with assumption-based clarification
Related MCP server: Wolfram Alpha MCP Server
Tools
wolfram_query
Query Wolfram Alpha for computational, mathematical, scientific, and factual information.
This has been invaluable to me as LLMs have such a tough time with math computation so Wolfram Alpha comes in so handy.
Parameters:
input(required): The natural language query to send to Wolfram Alphamaxchars(optional): Maximum number of characters in the response (default: 6800)assumption(optional): Assumption to use when Wolfram Alpha provides multiple interpretationsunits(optional): Unit system preference (e.g., "metric", "imperial")currency(optional): Currency preference for financial calculationscountrycode(optional): Country code for localized resultslanguagecode(optional): Language code for resultslocation(optional): Location for location-specific queriestimezone(optional): Timezone for time-related calculations
wolfram_query_with_assumptions
Query Wolfram Alpha with specific assumptions when the initial query returns multiple interpretations.
Parameters:
input(required): The exact same input from the previous queryassumption(required): The assumption value to use from the previous query resultmaxchars(optional): Maximum number of characters in the response (default: 6800)
Setup
Prerequisites
Node.js: Version 18.0.0 or higher
Wolfram Alpha App ID: Get one from the Wolfram Alpha Developer Portal
Installing via Smithery
To install wolfram-llm-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @henryhawke/wolfram-llm-mcp --client claudeInstallation
Clone this repository:
git clone <repository-url> cd wolfram-alpha-mcp-serverInstall dependencies:
npm installBuild the project:
npm run build
Configuration
Set your Wolfram Alpha App ID as an environment variable:
export WOLFRAM_ALPHA_APP_ID=your_app_id_hereOr create a .env file:
WOLFRAM_ALPHA_APP_ID=your_app_id_hereGetting a Wolfram Alpha App ID
Visit the Wolfram Alpha Developer Portal
Sign up for a Wolfram ID or log in
Go to the "My Apps" tab
Click "Sign up to get your first AppID"
Complete the survey and create your app
Copy your App ID for use with this MCP server
Usage
Running the Server
npm startExample Queries
Mathematics: "solve x^2 + 5x + 6 = 0"
Physics: "speed of light in vacuum"
Chemistry: "molecular weight of caffeine"
Geography: "population of Tokyo"
Astronomy: "distance to Andromeda galaxy"
History: "when was the Eiffel Tower built"
Unit Conversion: "convert 100 fahrenheit to celsius"
Financial: "apple stock price"
Handling Multiple Interpretations
When Wolfram Alpha provides multiple interpretations of a query, the server will include available assumptions in the response. You can then use the wolfram_query_with_assumptions tool to get more specific results.
Best Practices
Query Optimization: Convert complex questions to simplified keyword queries when possible
Instead of: "how many people live in France"
Use: "France population"
Language: Send queries in English only; translate non-English queries before sending
Mathematical Notation: Use proper mathematical notation
Use
6*10^14instead of6e14Use single-letter variable names with optional subscripts
Units: Include spaces between compound units (e.g., "Ī© m" for "ohm*meter")
Error Handling
The server provides comprehensive error handling for common issues:
Invalid App ID: Check your
WOLFRAM_ALPHA_APP_IDenvironment variableUninterpretable Input: The query cannot be understood by Wolfram Alpha
Network Issues: Connection problems with the Wolfram Alpha API
Timeouts: Query too complex or service temporarily unavailable
Development
Scripts
npm run build: Compile TypeScript to JavaScriptnpm run dev: Watch mode for developmentnpm start: Run the compiled server
Project Structure
src/
āāā index.ts # Main server implementation
package.json # Package configuration and MCP metadata
tsconfig.json # TypeScript configuration
README.md # This fileAPI Reference
This server implements the Model Context Protocol (MCP) specification and uses the Wolfram Alpha LLM API.
License
MIT License
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
Available Tools
2 toolswolfram_queryB
Query Wolfram Alpha for computational, mathematical, scientific, and factual information. Supports natural language queries about entities in chemistry, physics, geography, history, art, astronomy, mathematics, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The natural language query to send to Wolfram Alpha. Convert complex questions to simplified keyword queries when possible (e.g., "how many people live in France" becomes "France population"). | |
| maxchars | No | Maximum number of characters in the response (default: 6800) | |
| assumption | No | Assumption to use when Wolfram Alpha provides multiple interpretations of a query | |
| units | No | Unit system preference (e.g., "metric", "imperial") | |
| currency | No | Currency preference for financial calculations | |
| countrycode | No | Country code for localized results | |
| languagecode | No | Language code for results (queries should still be in English) | |
| location | No | Location for location-specific queries | |
| timezone | No | Timezone for time-related calculations | |
| width | No | Width for generated images | |
| maxwidth | No | Maximum width for generated images | |
| plotwidth | No | Width for plots and graphs | |
| scantimeout | No | Timeout for scanning operations (seconds) | |
| formattimeout | No | Timeout for formatting operations (seconds) | |
| parsetimeout | No | Timeout for parsing operations (seconds) | |
| totaltimeout | No | Total timeout for the request (seconds) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool queries Wolfram Alpha and supports natural language queries, but does not disclose behavioral traits such as rate limits, authentication needs, error handling, or response formats. This is a significant gap for a tool with 16 parameters and no output schema.
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 appropriately sized and front-loaded, starting with the core purpose and then listing supported domains. It uses two sentences efficiently without waste, though it could be slightly more structured by separating usage tips from the purpose statement.
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 complexity (16 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral aspects, response handling, and error cases, which are crucial for a tool with many optional parameters and no structured output documentation. This leaves significant gaps for an AI agent.
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%, so the schema already documents all 16 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage tips for the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
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 the tool's purpose with specific verbs ('Query Wolfram Alpha') and resources ('computational, mathematical, scientific, and factual information'), and distinguishes it from its sibling by specifying the types of queries supported. It explicitly lists domains like chemistry, physics, geography, etc., making the scope unambiguous.
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 implies usage for computational and factual queries across various domains, but does not explicitly state when to use this tool versus its sibling 'wolfram_query_with_assumptions' or other alternatives. It provides context on supported query types but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wolfram_query_with_assumptionsA
Query Wolfram Alpha with specific assumptions when the initial query returns multiple interpretations. Use this when you need to clarify ambiguous queries.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The exact same input from the previous query | |
| assumption | Yes | The assumption value to use from the previous query result | |
| maxchars | No | Maximum number of characters in the response (default: 6800) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool's behavior in handling ambiguous queries and using assumptions, but lacks details on rate limits, authentication needs, error handling, or response format. For a query tool with no annotation coverage, this leaves gaps in behavioral understanding, though it covers the core operational context.
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 highly concise and well-structured in two sentences, with the first stating the purpose and the second providing usage guidelines. Every sentence earns its place by adding critical information without redundancy, making it front-loaded and efficient.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and usage well, but lacks details on behavioral aspects like response handling or error cases. Without annotations or output schema, more context on what to expect from the tool would enhance completeness, though it meets minimum viability.
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%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain the format of 'assumption' or examples). Baseline 3 is appropriate as the schema handles the heavy lifting, but no extra semantic value is added.
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 the tool's purpose with specific verbs ('Query Wolfram Alpha with specific assumptions') and resource ('Wolfram Alpha'), and explicitly distinguishes it from its sibling tool by specifying it's for when 'the initial query returns multiple interpretations.' This provides clear differentiation and a specific use case.
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 explicit usage guidelines: 'Use this when you need to clarify ambiguous queries' and specifies it's for when 'the initial query returns multiple interpretations.' This clearly indicates when to use this tool versus alternatives (like the sibling 'wolfram_query'), offering direct context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have clearly distinct purposes: wolfram_query handles general queries, while wolfram_query_with_assumptions is specifically for disambiguating queries when multiple interpretations arise. There is no overlap or confusion between them.
Both tools follow a consistent snake_case naming pattern with 'wolfram_query' as the base, and the second tool adds a descriptive suffix '_with_assumptions'. This makes the naming predictable and easy to understand.
With only 2 tools, the server feels thin for a domain as broad as Wolfram Alpha's capabilities (covering computational, mathematical, scientific, and factual information). While the tools cover basic querying and disambiguation, more specialized operations might be expected.
The tools provide core query functionality and a mechanism for handling ambiguous queries, which covers essential use cases. However, there are minor gaps, such as lack of tools for structured data retrieval, image generation, or step-by-step solutions, which are common in Wolfram Alpha's offerings.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Integrates Wolfram Language and Wolfram|Alpha accessing curated data and sophisticated algorithms.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Math.js MCP ā wraps the mathjs.org API (free, no auth)
Loan & mortgage calculator, compound interest, ROI, crypto prices, FX conversion for AI agents.
Related MCP Servers
- FlicenseCqualityDmaintenanceEnables querying WolframAlpha's LLM API for natural language questions, providing structured and simplified answers optimized for LLM consumption.355
- FlicenseNot gradedqualityDmaintenanceEnables users to query Wolfram Alpha's computational knowledge engine through natural language. Provides access to mathematical computations, scientific data, and factual information via the Wolfram Alpha API.
- AlicenseNot gradedqualityDmaintenanceEnables scientific computing, mathematical problem solving, and step-by-step mathematical solutions through Wolfram Alpha's mobile API. Supports real-time streaming responses and multiple output formats for enhanced mathematical and scientific queries.1MIT
- AlicenseNot gradedqualityDmaintenanceEnables mathematical computation via Wolfram Language/Mathematica integration, supporting calculations, equation solving, calculus, matrix operations, and symbolic mathematics.13MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/henryhawke/wolfram-llm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server