Math MCP Server

by YasogaN

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
Most tools have distinct purposes: evaluate for general evaluation, expand for expansion, factor for factoring, etc. However, evaluate is quite broad and could be confused with simplify or expand for certain expressions, though descriptions mitigate this.
Naming Consistency3/5
Tool names are all single words but lack a consistent pattern: some are verbs (evaluate, expand, factor, simplify, solve), while others are nouns (matrix, statistics, units). The naming is readable but not uniform.
Tool Count5/5
With 8 tools covering arithmetic, algebra, matrices, statistics, and unit conversion, the count feels well-scoped for a math server. Each tool serves a clear purpose without redundancy.
Completeness4/5
The tool set covers core mathematical operations including symbolic manipulation, matrix operations, statistics, and units. Minor gaps exist, such as no dedicated tool for solving systems of equations or advanced calculus like limits, but agents can often work around these using existing tools.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states inputs are 2D number arrays and lists ops, but does not describe output format, error handling, shape constraints, or side effects. For example, it doesn't clarify that some ops may return complex numbers. Minimal disclosure beyond 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 concise with two sentences and an example. It front-loads the purpose, then lists ops, mentions unsupported SVD, and gives input requirements. Well-structured and no wasted words.
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 complexity of multiple ops and no output schema, the description provides a reasonable overview but lacks details on return values, constraints (e.g., square matrices for determinant), and error conditions. It is adequate but incomplete.
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 0%, so description must explain parameters. It clarifies that inputs are 2D number arrays and that binary ops require both 'a' and 'b'. It also lists op values and gives an example. However, it does not explain what each operation does in detail, leaving some ambiguity.
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 'Performs matrix operations' and lists many specific operations (multiply, add, etc.). It distinguishes itself from sibling math tools (evaluate, simplify, solve) by focusing on matrix operations. However, it could be more explicit that this tool is exclusively for matrix operations.
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?
No guidance on when to use this tool vs. alternatives like 'solve' or 'statistics'. It mentions that SVD is not supported and binary ops require both 'a' and 'b', but does not compare with siblings or provide context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and description only mentions using Algebrite and gives examples. Omits behavioral details like error handling, unsupported expressions, or performance 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?
Single sentence with examples; concise and front-loaded. No wasted words.
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?
Adequate for a simple 1-param tool with no output schema, but lacks error conditions, input validation hints, or output description.
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 coverage is 0%, and description provides only examples, not explicit semantics for the 'expression' parameter beyond being a string. Doesn't specify valid formats or constraints.
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 it expands factored or compound expressions using Algebrite, with examples that distinguish it from siblings like factor and simplify.
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 when-to-use or when-not-to-use guidance. Examples imply usage for algebraic expansion, but doesn't contrast with sibling tools like factor or simplify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose error handling, input restrictions, or domain boundaries beyond stating 'mathjs rules' and giving examples.
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?
Concise three sentences with front-loaded main action and helpful examples, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter and no output schema; covers purpose and examples, but lacks edge cases or error info.
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?
Only one parameter 'expression' with 0% schema coverage; examples add context but no formal description of expected format or constraints.
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 it simplifies mathematical expressions using mathjs rules, with specific actions (combine like terms, trig identities, reduce constants) and examples that distinguish it from siblings like expand and factor.
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 when to use (when simplification is needed) via examples, but does not explicitly state when not to use or compare to sibling tools like expand or factor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the use of Algebrite, returns factored form, and gives behavioral insight via examples (including prime factorization for constants). It doesn't mention error handling for invalid inputs, but overall is transparent.
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 concise: two sentences plus a list of examples. The purpose is front-loaded, though examples could be integrated more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description explains functionality and provides examples. It is fairly complete but missing error cases or constraints on input format.
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 coverage is 0% and the description only provides examples as parameter hints. It does not formally describe what the expression parameter should contain (e.g., 'a valid polynomial string') beyond examples.
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 factors polynomial expressions and provides concrete examples distinguishing it from siblings like simplify and expand. The verb 'factors' and resource 'polynomial expression' are specific.
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?
Usage is implied through examples and sibling names, but no explicit when-to-use or when-not-to-use guidance is given. For instance, it doesn't differentiate from simplify for factoring tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the underlying libraries (mathjs, Algebrite) and mode behavior (numeric vs symbolic). However, it omits error handling, output format, side effects, or permission requirements. For a computation tool, the description is adequate but not fully transparent.
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, well-structured paragraph that front-loads the core function ('Evaluates any mathematical expression using mathjs'), then lists supported operations, introduces the symbolic mode, and provides illustrative examples. Every sentence adds value without redundancy.
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 complexity and absence of output schema, the description is moderately complete. It covers capabilities and modes but fails to specify the return format (e.g., numeric value, string, object) or error behavior. For a tool with extensive functionality like calculus and matrices, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by providing concrete examples and listing supported expression types (e.g., 'det([[1,2],[3,4]])'), which goes beyond the schema's basic description of 'expression' as a string. The mode parameter is further clarified with defaults and library names.
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 mathematical expressions using mathjs, with specific verb 'Evaluates' and resource 'mathematical expression'. The comprehensive list of supported operations (arithmetic, trigonometry, calculus, etc.) effectively distinguishes it from sibling tools like expand or factor, which handle specific transformations.
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 does not explicitly state when to use this tool versus alternatives. It implies general applicability with 'any mathematical expression' but lacks explicit when-not-to-use guidance or comparison with sibling tools. The mode parameter is explained, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, error handling, or return behavior. For a computational tool, this is acceptable but minimal; basic transparency about potential errors or output format is missing.
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 dense but efficient, front-loading the overall purpose. Every sentence adds value, though it could be broken into sections for readability. It is not excessively long.
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?
The description lacks specification of return values or output format. For 'linear_regression', it mentions input but not output. Given the complexity of operations and no output schema, more completeness is needed, though many ops have implied returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter descriptions, but the description adds significant meaning: it explains each op, what 'data' and 'args' are used for, and specific constraints for many operations (e.g., 'normal_pdf needs {x, mean, std}'). This fully compensates for the missing schema descriptions.
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 that the tool computes descriptive statistics and probability distributions, listing all operations with their required parameters. It distinguishes between two categories (descriptive ops using 'data' and distribution ops using 'args'), and the op enum is exhaustive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context per operation, including constraints like 'quantile needs args.prob' and 'skewness needs n≥3'. However, it does not explicitly state when to avoid this tool or name alternatives, though sibling tools are different domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that it returns 'all solutions including complex ones', which is useful. However, it lacks details on error handling (e.g., unsolvable equations) or performance traits.
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 concise with only two sentences plus examples. It front-loads the main purpose and uses minimal words to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains the parameters and output behavior. It could be slightly more complete by mentioning what happens for equations with no solutions, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds value by providing examples and specifying the expected format for the equation string.
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 'Solves an equation for a variable' which is a specific verb+resource. It distinguishes from sibling tools like simplify, factor, etc., which perform different algebraic operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit format requirements ('lhs = rhs') and two examples, making it clear how to use the tool. It does not explicitly state when not to use it, but the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains the supported unit categories and format but does not mention error handling, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one well-structured paragraph with no extraneous information. It includes the purpose, format, supported categories, and examples concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete. It covers what the tool does, how to use it, and what units are supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'expression' is described in the schema. The tool description adds value by providing the format, examples, and supported units, which go beyond the schema's brief description.
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 'Converts between units' and specifies the exact format and supported unit categories. This distinguishes it from sibling tools like 'solve' or 'simplify' which perform different mathematical operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the required format and examples, making it clear when to use this tool. However, it does not explicitly state when not to use it or compare to alternatives beyond listing siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

$math-mcp MCP server$

Copy to your README.md:

[![math-mcp MCP server](https://glama.ai/mcp/servers/YasogaN/math-mcp/badges/card.svg)](https://glama.ai/mcp/servers/YasogaN/math-mcp)

Score Badge

$math-mcp MCP server$

Copy to your README.md:

[![math-mcp MCP server](https://glama.ai/mcp/servers/YasogaN/math-mcp/badges/score.svg)](https://glama.ai/mcp/servers/YasogaN/math-mcp)

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/YasogaN/math-mcp'

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