Skip to main content
Glama
henryhawke

Wolfram Alpha MCP Server

by henryhawke

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 Alpha

  • maxchars (optional): Maximum number of characters in the response (default: 6800)

  • assumption (optional): Assumption to use when Wolfram Alpha provides multiple interpretations

  • units (optional): Unit system preference (e.g., "metric", "imperial")

  • currency (optional): Currency preference for financial calculations

  • countrycode (optional): Country code for localized results

  • languagecode (optional): Language code for results

  • location (optional): Location for location-specific queries

  • timezone (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 query

  • assumption (required): The assumption value to use from the previous query result

  • maxchars (optional): Maximum number of characters in the response (default: 6800)

Setup

Prerequisites

  1. Node.js: Version 18.0.0 or higher

  2. 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 claude

Installation

  1. Clone this repository:

    git clone <repository-url>
    cd wolfram-alpha-mcp-server
  2. Install dependencies:

    npm install
  3. Build the project:

    npm run build

Configuration

Set your Wolfram Alpha App ID as an environment variable:

export WOLFRAM_ALPHA_APP_ID=your_app_id_here

Or create a .env file:

WOLFRAM_ALPHA_APP_ID=your_app_id_here

Getting a Wolfram Alpha App ID

  1. Visit the Wolfram Alpha Developer Portal

  2. Sign up for a Wolfram ID or log in

  3. Go to the "My Apps" tab

  4. Click "Sign up to get your first AppID"

  5. Complete the survey and create your app

  6. Copy your App ID for use with this MCP server

Usage

Running the Server

npm start

Example 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

  1. Query Optimization: Convert complex questions to simplified keyword queries when possible

    • Instead of: "how many people live in France"

    • Use: "France population"

  2. Language: Send queries in English only; translate non-English queries before sending

  3. Mathematical Notation: Use proper mathematical notation

    • Use 6*10^14 instead of 6e14

    • Use single-letter variable names with optional subscripts

  4. 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_ID environment variable

  • Uninterpretable 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 JavaScript

  • npm run dev: Watch mode for development

  • npm 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 file

API 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 tools
wolfram_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesThe 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").
maxcharsNoMaximum number of characters in the response (default: 6800)
assumptionNoAssumption to use when Wolfram Alpha provides multiple interpretations of a query
unitsNoUnit system preference (e.g., "metric", "imperial")
currencyNoCurrency preference for financial calculations
countrycodeNoCountry code for localized results
languagecodeNoLanguage code for results (queries should still be in English)
locationNoLocation for location-specific queries
timezoneNoTimezone for time-related calculations
widthNoWidth for generated images
maxwidthNoMaximum width for generated images
plotwidthNoWidth for plots and graphs
scantimeoutNoTimeout for scanning operations (seconds)
formattimeoutNoTimeout for formatting operations (seconds)
parsetimeoutNoTimeout for parsing operations (seconds)
totaltimeoutNoTotal timeout for the request (seconds)

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesThe exact same input from the previous query
assumptionYesThe assumption value to use from the previous query result
maxcharsNoMaximum number of characters in the response (default: 6800)

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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

A3.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • 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.
    3
    55
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables 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.
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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.
    1
    MIT

Latest Blog Posts

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