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., "@symath differentiate sin(x)^2 + x^3" 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.

symath

by lingeerr

Overview Schema Related Servers Score Discussions

JavaScript

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., "@symath differentiate sin(x)^2 + x^3"

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.

SyMath MCP

SyMath MCP is a high-precision mathematics server for MCP clients. It gives LLMs a reliable calculator layer for exact integer work, configurable decimal precision, symbolic derivatives and simplification, numerical calculus, statistics, number theory, and common LaTeX-style math input.

Features

High-precision expression evaluation powered by mathjs BigNumber mode.
Common LaTeX normalization, including \frac{}, \sqrt{}, trig/log functions, \pi, \cdot, and braced powers.
Dedicated tools for arithmetic, statistics, number theory, and calculus.
Symbolic derivative and simplification support.
Exact integer algorithms using BigInt for gcd, lcm, prime checks, factorization, modular exponentiation, and modular inverse.
Structured errors for edge cases such as division by zero, invalid domains, malformed LaTeX, and non-integer number theory input.
Official MCP transports:
- stdio for local desktop clients.
- Streamable HTTP at /mcp for remote or local HTTP clients.
- Legacy HTTP+SSE for older clients that have not migrated yet.

Related MCP server: Math MCP Server

Install

npm install

After npm publication, users can run it without cloning:

npx symath-mcp

Run Locally

stdio

Use this for Claude Desktop and other local MCP clients that launch a command.

npm start

Equivalent direct command:

node /Users/fengling/AiProjects/symath/src/stdio.js

Streamable HTTP

Use this for clients that connect to an MCP URL.

npm run start:http

Defaults:

URL: http://127.0.0.1:3000/mcp
Health check: http://127.0.0.1:3000/health

Configuration:

HOST=0.0.0.0 PORT=3000 MCP_PATH=/mcp npm run start:http

Legacy SSE

SSE is deprecated by the MCP SDK, but some older clients still support it.

npm run start:sse

Defaults:

SSE endpoint: http://127.0.0.1:3000/mcp
Messages endpoint: http://127.0.0.1:3000/messages

Configuration:

HOST=0.0.0.0 PORT=3000 SSE_PATH=/mcp MESSAGES_PATH=/messages npm run start:sse

Client Configuration

Claude Desktop, local clone

Add this to Claude Desktop's MCP configuration and restart Claude Desktop:

{
  "mcpServers": {
    "symath": {
      "command": "node",
      "args": ["/Users/fengling/AiProjects/symath/src/stdio.js"]
    }
  }
}

Claude Desktop, after npm publication

{
  "mcpServers": {
    "symath": {
      "command": "npx",
      "args": ["-y", "symath-mcp"]
    }
  }
}

MCP clients with Streamable HTTP support

Start the HTTP server:

npm run start:http

Then configure the client URL:

http://127.0.0.1:3000/mcp

For a remote deployment, replace the URL with your public HTTPS endpoint, for example:

https://your-domain.example/mcp

Older SSE clients

Start the SSE server:

npm run start:sse

Configure:

SSE URL:      http://127.0.0.1:3000/mcp
Messages URL: http://127.0.0.1:3000/messages

Publish

GitHub

git add .
git commit -m "Support all MCP transports"
git push

npm

npm login

Publish:

npm publish --access public

Package binaries:

symath-mcp: stdio server.
symath-mcp-http: Streamable HTTP server.
symath-mcp-sse: legacy SSE server.

Tools

calculate: Evaluate a math expression or common LaTeX expression at configurable precision.
arithmetic: Run basic arithmetic operations with explicit operands.
statistics: Compute descriptive statistics over numeric data.
number_theory: Run exact integer operations such as gcd, lcm, primality, factorization, modular exponentiation, modular inverse, and Euler totient.
calculus: Differentiate symbolically, simplify symbolically, or compute a definite integral numerically.
latex_to_expression: Convert supported LaTeX math syntax to a mathjs expression.

Examples

{
  "expression": "\\frac{1}{3} + \\sqrt{2}",
  "precision": 80
}

{
  "operation": "modPow",
  "values": ["7", "560", "561"]
}

{
  "operation": "derivative",
  "expression": "sin(x)^2 + x^3",
  "variable": "x"
}

Test

npm test
node --check src/server.js
node --check src/stdio.js
node --check src/http.js
node --check src/sse.js

Available Tools

6 tools

arithmeticBasic high precision arithmeticC

Perform add, subtract, multiply, divide, power, and sqrt with explicit operands.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No		auto
`values`	Yes	Operands. Strings are recommended for very large or precise numbers.
`operation`	Yes
`precision`	No

TDQS

C2.5/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It mentions 'high precision' but does not explain error handling, edge cases (e.g., division by zero), or whether operations are destructive. Significant gaps exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but overly sparse. It lacks structure and front-loads only a list of operations. While not verbose, it sacrifices informativeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, low schema coverage, and no output schema, the description is severely incomplete. A tool with 4 parameters and multiple operations requires details on return format, error handling, precision behavior, and operation-specific nuances. The description fails to cover these essential aspects.

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

Parameters2/5

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

Schema description coverage is only 25% (only 'values' has a description). The description adds minimal meaning beyond the schema: it lists operations but does not explain the 'format', 'precision', or 'operation' enum values. The agent would need to infer semantics from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists specific arithmetic operations (add, subtract, etc.), making the purpose clear. However, it does not differentiate from sibling tools like 'calculate' or 'calculus', which may overlap. A more explicit distinction would improve clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, suitability, or exclusions. The phrase 'with explicit operands' is too vague to guide tool selection.

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

calculateHigh precision expression calculatorA

Evaluate a mathjs or common LaTeX math expression with configurable high precision.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output numeric format.	auto
`precision`	No	Decimal precision in significant digits.
`expression`	Yes	Expression to evaluate. Supports mathjs syntax and common LaTeX such as \frac and \sqrt.
`inputFormat`	No	Input expression format.	auto

TDQS

A3.5/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 configurable precision and expression format support, implying a read-only operation, but does not explicitly state lack of side effects, safety, or any other behavioral traits beyond what is implied by 'evaluate'.

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 a single, efficient sentence that conveys the core functionality without extraneous words. Every word serves a purpose.

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?

Despite no output schema, the description does not clarify return value format or behavior (e.g., whether it returns a number or string). With 4 parameters and sibling tools, additional context on usage distinctions would be beneficial.

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 coverage is 100% with each parameter described. The description adds general context about configurability and syntax support but does not enhance individual parameter semantics beyond the schema definitions. Baseline 3 is appropriate.

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 evaluates mathjs or LaTeX expressions with configurable high precision. It uses a specific verb 'Evaluate' and identifies the resource, making it distinct from sibling tools like arithmetic or latex_to_expression.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings like arithmetic or calculus.

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

calculusCalculus and symbolic algebraC

Differentiate symbolically, simplify symbolically, or compute definite integrals numerically with Simpson's rule.

ParametersJSON Schema

Name	Required	Description	Default
`lower`	No	Lower bound for definite integration.
`upper`	No	Upper bound for definite integration.
`format`	No		auto
`variable`	No		x
`intervals`	No	Simpson intervals. Odd values are rounded up to the next even value.
`operation`	Yes
`precision`	No
`expression`	Yes
`inputFormat`	No		auto

TDQS

C2.6/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 full burden. It mentions Simpson's rule for integration but omits details on error handling, precision limitations, return format, or behavior for invalid inputs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise. However, it is too sparse; while it earns its place by stating the three operations, it lacks necessary detail for effective use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters, no output schema, no annotations), the description is inadequate. It does not explain return values, parameter usage, or constraints, leaving the AI agent underinformed.

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

Parameters1/5

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

Schema description coverage is low (33%), and the description adds no parameter information. It does not explain the required 'operation' and 'expression' parameters or optional ones like 'lower', 'upper', 'intervals', etc.

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 states three specific calculus operations: symbolic differentiation, symbolic simplification, and numeric definite integration via Simpson's rule. This clearly identifies the tool's purpose and distinguishes it from sibling tools like arithmetic and calculate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not specify when to use this tool over alternatives such as calculate for numeric evaluation or latex_to_expression for conversion. No guidance is provided on prerequisites or when not to use the tool.

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

latex_to_expressionLaTeX to math expression converterC

Convert supported LaTeX math syntax into a mathjs-compatible expression.

ParametersJSON Schema

Name	Required	Description	Default
`latex`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It mentions 'supported LaTeX' implying limitations but does not elaborate on error handling, supported subset, or side effects. A simple conversion tool likely has no destructive actions, but this is not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it lacks additional structure or detail that would aid understanding. It is not front-loaded with critical information beyond the basic purpose.

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 tool's simplicity and lack of output schema, the description is too brief. It does not explain what 'supported LaTeX' means, the exact output format, error behavior, or provide an example, leaving gaps in understanding.

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

Parameters2/5

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

The schema has 0% description coverage for the 'latex' parameter. The description only mirrors the parameter name without adding format, examples, or constraints beyond the schema's minLength and type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (convert) and the input/output (LaTeX math syntax to mathjs expression). It distinguishes from computational sibling tools like arithmetic or calculate, but could be more specific about the output format.

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?

No explicit guidance on when to use this tool versus alternatives. The purpose is implicit from the name, but the description does not provide context such as 'use when you need to parse a LaTeX string into an expression for evaluation'.

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

number_theoryExact number theoryB

Run exact integer operations using BigInt.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes	Integer operands. Use strings for large integers.
`operation`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; description only mentions BigInt for precision, but lacks disclosure of performance, limits, side effects, or other behavioral traits.

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?

Extremely concise at 7 words, no wasted text, but could include more useful information without becoming verbose.

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 no output schema, an enum of 7 operations, and no annotations, the description is too minimal to fully inform an agent about tool behavior and return values.

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

Parameters2/5

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

Schema describes two parameters with 50% coverage (only 'values' has a note on string usage). Description adds no extra meaning to 'operation' or parameter details.

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?

Clearly states verb 'run' and resource 'exact integer operations using BigInt', distinguishing it from siblings like arithmetic or calculus which deal with floating-point or calculus.

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?

Implies use for exact integer math with BigInt, but provides no explicit guidance on when to use versus alternatives like arithmetic or calculate.

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

statisticsHigh precision statisticsB

Compute count, sum, mean, median, min, max, range, variance, standard deviation, percentile, or summary.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No		auto
`sample`	No	Use sample variance/stddev denominator n-1.
`values`	Yes
`operation`	Yes
`precision`	No
`percentile`	No	Required when operation is percentile.

TDQS

B3.2/5.0

Behavior2/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 fails to mention that the tool is read-only (non-destructive), whether there are rate limits, or how inputs like string values are handled. The description only lists operations, lacking essential behavioral context.

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 a single, efficient sentence listing all operations in a readable format. It front-loads the key information without extraneous words. However, it could be slightly restructured to separate operations from usage notes, but overall it is appropriately concise.

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 tool has 6 parameters (2 required) and no output schema, the description is incomplete. It omits critical details: parameter dependencies (percentile requires the 'percentile' param), output format, and error handling (e.g., empty array). The 33% schema coverage exacerbates the gaps, leaving the agent without sufficient context for correct invocation.

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

Parameters2/5

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

Schema description coverage is only 33% (only sample and percentile have descriptions). The tool description does not add meaning to other parameters (format, precision, values). For example, it doesn't explain that 'values' can include string numbers or that 'precision' controls significant digits. The low coverage and lack of explanation hinder correct invocation.

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 computes common statistical measures (count, sum, mean, etc.), which distinguishes it from sibling tools like arithmetic (basic operations) and calculus (differentiation/integration). The verb 'compute' and enumeration of specific resources make the purpose 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 lists operations but provides no guidance on when to use this tool versus alternatives (e.g., arithmetic for simple sums). It does not specify prerequisites, typical use cases, or when to avoid using the tool. Usage is implied but not explicitly stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.2.0Jul 12, 2026
- First observedarithmetic
- First observedcalculate
- First observedcalculus
- First observedlatex_to_expression
- First observednumber_theory
- First observedstatistics

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct area of mathematics: basic arithmetic, expression evaluation, calculus, LaTeX conversion, number theory, and statistics. No overlapping purposes.

Naming Consistency4/5

Names are mostly single-word or snake_case nouns describing the domain. 'latex_to_expression' and 'number_theory' are descriptive and follow a consistent pattern, though mixing single-word and multi-word names is a minor inconsistency.

Tool Count5/5

Six tools is well-scoped for a symbolic math server, covering core mathematical operations without being overly numerous or sparse.

Completeness4/5

Covers arithmetic, expression evaluation, calculus, LaTeX conversion, integer theory, and statistics. Minor gaps like solving equations or linear algebra are absent but not critical for basic math support.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

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

Aman-Amith-Shastry-scientific_computation_mcpOAuth
ai.smithery
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Research & Data
22
Math MCP Learning A
io.github.clouatre-labs
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Education & Learning Tools Research & Data Developer Tools
1725
mathjs A
io.github.pipeworx-io
Math.js MCP — wraps the mathjs.org API (free, no auth)
Developer Tools
332
IO Aerospace MCP Server C
org.io-aerospace
MCP server for aerospace calculations: orbital mechanics, ephemeris, DSN operations, ...
Aerospace & Astrodynamics Research & Data
214

Related MCP Servers

Symath-MCP
Education & Learning Tools Research & Data
3aKHP
A
license
A
quality
D
maintenance
A symbolic mathematics MCP server supporting calculus, linear algebra, number theory, statistics, and unit conversion via natural language.
Updated 4 months ago (2026-05-21 22:03 UTC)
8
MIT
Math MCP Server
Data Visualization Research & Data
111-test-111
A
license
B
quality
D
maintenance
A Python-based MCP server providing mathematical computation tools and plotting utilities for a wide range of math topics including calculus, matrix operations, statistics, and more.
Updated a year ago (2025-06-13 17:50 UTC)
22
5
MIT
mcp-abacus
Developer Tools
laszlopere
A
license
A
quality
A
maintenance
Pure-Python MCP server for type-faithful calculation — evaluate expressions under fixed-point, IEEE-754 double, or exact rational arithmetic, with every answer labelled with its precision (exact vs inexact).
Updated a month ago (2026-08-07 05:33 UTC)
5
1
GPL 3.0
calculator-mcp-server
Developer Tools
cyanheads
A
license
Not graded
quality
A
maintenance
Evaluate, simplify, and differentiate mathematical expressions via MCP. Provides a single tool for arithmetic, algebra, and symbolic differentiation with secure sandboxing.
Updated 15 days ago (2026-08-22 13:52 UTC)
265
1
Apache 2.0

Appeared in Searches

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/lingeerr/symath'

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