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., "@MCP Mathematics convert 100 km to miles"
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.
A comprehensive Model Context Protocol (MCP) server that turns any AI assistant into a powerful mathematical computation engine. MCP Mathematics gives you professional-grade features including 52 advanced mathematical functions, 158 unit conversions across 15 categories, complete financial calculations, and secure AST-based evaluation—all in a production-ready, secure environment.
MCP Mathematics is the most complete mathematical computation server for AI assistants, built specifically for the Model Context Protocol. This production-ready solution turns any MCP-compatible AI into a powerful mathematical tool that handles everything from simple arithmetic to complex financial calculations, unit conversions across many different fields, and advanced scientific computations.
Key Innovation: Using Python's Abstract Syntax Tree (AST) evaluation, MCP Mathematics gives you exceptional mathematical capabilities while staying completely secure—stopping code injection vulnerabilities without losing any features.
Related MCP server: Math MCP Server
AST-Based Evaluation: Every calculation is checked and verified through Python's AST, which stops code injection attacks
Sandboxed Execution: All calculations run in a secure, controlled environment that only allows safe operations
Zero External Dependencies: Lower security risk since the core features don't need any external libraries
52 Built-In Functions: From simple math to complex scientific calculations
158 Unit Conversions: Wide-ranging unit conversion support covering 15 different categories
Financial Calculations: Full set of financial tools including interest, loan, and tax calculations
Unicode Operator Support: Easy mathematical symbols like ×, ÷, and ^ that feel natural to use
Full Math Library Coverage: Complete access to all of Python's mathematical functions
Type-Safe Design: Complete type checking throughout the code makes sure everything works reliably
Clean Production Code: Professional code with no debugging leftovers or extra comments
Complete Testing: 130 tests make sure all features work properly
Thread-Safe Operations: 100% reliable concurrent execution with Timer-based timeout system
Advanced Memory Management: Bounded LRU/TTL caches stop memory leaks in production environments
Enterprise Error Handling: Proper exception chaining and graceful resource cleanup
Before you install MCP Mathematics, make sure you have:
Python 3.10 or later on your system
An MCP-compatible AI assistant (Claude Desktop, VS Code with Continue, or similar)
Choose the installation method that works best for you:
This is the fastest way to get started:
# Install the uv package manager if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install and run MCP Mathematics
uvx mcp-mathematicsIf you prefer using pip:
pip install mcp-mathematics📦 Package Information: mcp-mathematics on PyPI
If you want to help out or need the latest development version:
git clone https://github.com/SHSharkar/MCP-Mathematics.git
cd MCP-Mathematics
pip install -e .To use MCP Mathematics with Claude Desktop, you'll need to update your configuration file.
Configuration file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"mcp-mathematics": {
"command": "uvx",
"args": [
"mcp-mathematics"
]
}
}
}{
"mcpServers": {
"mcp-mathematics": {
"command": "mcp-mathematics"
}
}
}If you're using VS Code with the Continue extension:
{
"models": [
{
"model": "claude-3-5-sonnet",
"provider": "anthropic",
"mcpServers": {
"mcp-mathematics": {
"command": "uvx",
"args": [
"mcp-mathematics"
]
}
}
}
]
}MCP Mathematics is available as a cloud-hosted service through FastMCP for instant access without local installation. Choose from multiple connection methods:
Access your tools from the command line with quick setup:
claude mcp add --scope local --transport http mathematics https://mathematics.fastmcp.app/mcpUse your tools directly in Claude's desktop app with one-click installation:
Download Link: https://mathematics.fastmcp.app/manifest.dxt?v=aa76634e-bffb-4be5-b1fd-c680cd7f7142
Downloads .dxt file. Open the file to connect automatically.
Access your tools in a Codex CLI session:
codex mcp add -- mathematics npx -y mcp-remote@latest https://mathematics.fastmcp.app/mcpDurably store your MCP via Codex's configuration file by adding this to .codex/config.toml:
[mcp_servers.mathematics]
command = "npx"
args = ["-y", "mcp-remote@latest", "https://mathematics.fastmcp.app/mcp"]Access your tools from the command line with quick setup:
gemini mcp add mathematics https://mathematics.fastmcp.app/mcp --transport httpAI-powered code editor with built-in tool support. Click to connect instantly:
Connection Link: cursor://anysphere.cursor-deeplink/mcp/install?name=mathematics&config=eyJ1cmwiOiJodHRwczovL21hdGhlbWF0aWNzLmZhc3RtY3AuYXBwL21jcCJ9
FastMCP Cloud Benefits:
No local installation required
Always up-to-date with latest features
Enhanced performance with cloud infrastructure
Instant access across multiple platforms
Production-ready deployment
MCP Mathematics gives you access to all its mathematical features through 21 specialized tools with descriptive, mathematical domain names for maximum clarity and memorability. Each tool is designed for specific tasks and built for excellent performance:
evaluate_mathematical_expression - Single Expression EvaluationThe main tool for working with mathematical expressions. It supports all 52 built-in functions, unit conversions, and financial calculations. It handles everything from simple arithmetic to complex scientific computations.
Use Cases:
Quick calculations: "2 * pi * 10" → "62.83185307179586"
Scientific computing: "sin(pi/2) + log10(1000)" → "4.0"
Financial analysis: "compound_interest(5000, 6.5, 15)" → Complete interest breakdown
Unit conversions: "convert_between_measurement_units(100, 'km', 'mi', 'length')" → Automatic unit detection and conversion
evaluate_multiple_mathematical_expressions - Parallel Processing EngineBuilt to handle many expressions at the same time, giving you much better performance when doing lots of calculations or data analysis work.
Use Cases:
Data processing: Process arrays of financial calculations
Scientific analysis: Batch trigonometric computations
Bulk conversions: Convert multiple values simultaneously
Input: ["sin(pi/2)", "cos(0)", "sqrt(16)", "factorial(5)"]
Output: ["1.0", "1.0", "4.0", "120"]convert_between_measurement_units - Advanced Unit Conversion SystemSmart unit conversion system that works with 158 units across 15 categories. It automatically figures out unit types, supports different spellings, and handles complex compound units.
Advanced Features:
Smart detection: Automatically figures out unit categories
Alias support: Accepts multiple spellings and abbreviations
Compound units: Handles complex units like m/s², kg·m/s²
History tracking: Keeps a conversion audit trail
Input: value=100, from_unit="meters", to_unit="feet"
Output: "328.084" (with automatic precision handling)convert_units_from_natural_language - Natural Language Unit ConversionConverts units using natural language queries, making unit conversions more intuitive and accessible. This tool parses natural language requests and automatically determines the appropriate conversion.
Supported Natural Language Patterns:
"convert 100 meters to feet"
"what is 32 Celsius in Fahrenheit"
"50 mph -> km/h"
"5 kilograms equals how many pounds"
"from 100 USD to EUR"
Input: "convert 100 kilometers to miles"
Output: {
"success": true,
"conversion": {
"original_query": "convert 100 kilometers to miles",
"input_value": 100,
"input_unit": "kilometers",
"output_value": 62.137119,
"output_unit": "miles",
"unit_type": "length"
}
}compute_statistical_operations - Statistical Analysis EnginePerforms comprehensive statistical calculations on datasets, providing essential statistical measures for data analysis and scientific computing.
Available Statistical Operations:
Descriptive statistics: mean, median, mode, range
Variability measures: variance, standard deviation
Distribution analysis: skewness, kurtosis
Data quality: quartiles, percentiles
Input: data=[1, 2, 3, 4, 5], operation="mean"
Output: "Result: 3.0"perform_matrix_mathematical_operations - Matrix Mathematics EngineAdvanced matrix operations for linear algebra, engineering calculations, and scientific computing with support for multiple matrix operations.
Supported Matrix Operations:
Basic operations: multiply, transpose
Advanced operations: determinant, inverse
Matrix analysis: rank, eigenvalues (where applicable)
Error handling for invalid operations
Input: matrices=[[[1,2],[3,4]], [[5,6],[7,8]]], operation="multiply"
Output: Matrix multiplication result with proper formattingperform_number_theory_analysis - Number Theory AnalysisAdvanced number theory operations for mathematical research, cryptography, and computational mathematics.
Available Number Theory Operations:
Prime testing: Check if numbers are prime
Prime factorization: Find all prime factors
Divisor analysis: Calculate all divisors
Euler's totient: Compute φ(n) function
Input: n=97, operation="is_prime"
Output: "Result: 97 is prime"create_mathematical_calculation_session - Session InitializationCreates a new calculation session with optional initial variables, enabling stateful mathematical computations across multiple operations.
Session Features:
Variable storage: Save and reuse calculation results
State persistence: Maintain context across operations
Isolated environments: Multiple independent sessions
Custom initialization: Set initial variables
Input: session_id="analysis_1", variables={"x": 10, "pi": 3.14159}
Output: "Session created: analysis_1"evaluate_expression_in_session_context - Stateful CalculationsPerforms calculations within a specific session context, with access to stored variables and the ability to save results for later use.
Input: session_id="analysis_1", expression="x * 2 + pi", save_as="result"
Output: "Result: 23.14159" (and saves as 'result' variable)list_mathematical_session_variables - Variable ManagementLists all variables currently stored in a calculation session, showing their names and values for easy reference.
Input: session_id="analysis_1"
Output: {"x": 10, "pi": 3.14159, "result": 23.14159}delete_mathematical_calculation_session - Session CleanupSafely removes a calculation session and all associated variables, freeing up memory and ensuring clean state management.
get_mathematical_computation_performance_metrics - Performance MonitoringProvides comprehensive system performance metrics including computation statistics, memory usage, and operational uptime for monitoring system health.
Metrics Included:
Computation statistics: Total calculations performed
Performance data: Average response times
Memory usage: Current memory consumption
System uptime: Server operational time
get_mathematical_security_audit_report - Security InformationReturns current security status including rate limiting information and session data for security monitoring and compliance.
get_mathematical_memory_usage_statistics - Memory AnalyticsDetailed memory usage statistics for cache and session management, helping with performance optimization and resource planning.
get_mathematical_computation_history - Calculation Audit TrailKeeps a complete record of all calculations with timestamps, so you can track, check, and repeat any mathematical work.
Features:
Timestamped records: Every calculation includes when it was run
Configurable limits: Get 1-100 recent calculations
Expression tracking: Full input and output logging
Error logging: Failed calculations with error details
clear_mathematical_computation_history - History ManagementLets you safely clear your calculation history when you need to for privacy, performance, or storage reasons.
optimize_mathematical_computation_memory - Memory OptimizationCleans up expired cache entries and optimizes memory usage, helping maintain optimal performance in long-running sessions.
Optimization Features:
Cache cleanup: Removes expired cache entries
Memory defragmentation: Optimizes memory allocation
Resource reclamation: Frees unused resources
Performance improvement: Maintains system responsiveness
list_all_available_mathematical_functions_and_constants - Complete Capability DiscoveryComplete reference tool that gives you instant access to all available mathematical functions, constants, unit conversions, and their settings.
Discovery Categories:
Mathematical functions: All 52 available functions with signatures
Constants: Mathematical and physical constants with values
Unit conversions: All 158 units organized by category
System capabilities: Available operations and limits
Note: This tool consolidates the functionality of listing functions, constants, and recent history access in a single comprehensive interface.
Access these resources directly through the MCP protocol with their corresponding implementation functions:
history://recent - View recent calculation history (implemented by recent_calculation_history)
functions://available - Browse available mathematical functions (implemented by mathematical_functions_catalog)
constants://math - Access mathematical constants with their values (implemented by mathematical_constants_catalog)
Pre-configured prompts for common calculation patterns:
scientific_calculation - Structured template for scientific computations
batch_calculation - Optimized template for batch processing
MCP Mathematics gives you a complete mathematical computation environment with support for over 52 functions spanning basic arithmetic, advanced scientific computing, and specialized mathematical operations. The system handles everything from simple calculations to complex scientific and financial computations with precision and reliability.
Beyond standard arithmetic, MCP Mathematics supports easy-to-use mathematical operators including Unicode symbols for natural mathematical expression:
Addition: +
Subtraction: -
Multiplication: * or ×
Division: / or ÷
Floor Division: //
Modulo: %
Exponentiation: ** or ^
Essential trigonometric operations in radians:
sin(x), cos(x), tan(x) - Standard trigonometric functions
asin(x), acos(x), atan(x) - Inverse trigonometric functions
atan2(y, x) - Two-argument arctangent for proper quadrant
Complete hyperbolic function set:
sinh(x), cosh(x), tanh(x) - Hyperbolic functions
asinh(x), acosh(x), atanh(x) - Inverse hyperbolic functions
Comprehensive logarithmic operations:
log(x) - Natural logarithm
log10(x) - Common logarithm (base 10)
log2(x) - Binary logarithm
log1p(x) - Natural logarithm of (1 + x) for precision
exp(x) - Exponential function (e^x)
exp2(x) - Base-2 exponential
expm1(x) - Exponential minus 1 (e^x - 1)
sqrt(x) - Square root
pow(x, y) - Power function
Control over numerical precision:
ceil(x) - Round up to nearest integer
floor(x) - Round down to nearest integer
trunc(x) - Remove decimal portion
Advanced mathematical operations:
factorial(x) - Factorial computation
gamma(x) - Gamma function
lgamma(x) - Natural logarithm of gamma function
erf(x) - Error function
erfc(x) - Complementary error function
Integer and combinatorial mathematics:
gcd(x, y) - Greatest common divisor
lcm(x, y) - Least common multiple (Python 3.9+)
isqrt(x) - Integer square root
comb(n, k) - Binomial coefficient (combinations)
perm(n, k) - Permutations
Precise control over floating-point arithmetic:
fabs(x) - Floating-point absolute value
copysign(x, y) - Magnitude of x with sign of y
fmod(x, y) - Floating-point remainder
remainder(x, y) - IEEE remainder operation
modf(x) - Separate integer and fractional parts
frexp(x) - Decompose into mantissa and exponent
ldexp(x, i) - Compute x × 2^i efficiently
hypot(x, y) - Euclidean distance calculation
cbrt(x) - Cube root (Python 3.11+)
Functions for numerical analysis:
isfinite(x) - Check for finite values
isinf(x) - Check for infinity
isnan(x) - Check for Not-a-Number
isclose(a, b) - Approximate equality testing
Specialized operations for scientific computing:
nextafter(x, y) - Next representable floating-point value
ulp(x) - Unit of least precision
Seamless conversion between angle units:
degrees(x) - Convert radians to degrees
radians(x) - Convert degrees to radians
Access fundamental mathematical constants:
pi - π ≈ 3.141592653589793
e - Euler's number ≈ 2.718281828459045
tau - τ = 2π ≈ 6.283185307179586
inf - Positive infinity
nan - Not a Number
evaluate_mathematical_expression("2 + 3 * 4") # Result: 14
evaluate_mathematical_expression("10 / 3") # Result: 3.3333333333333335
evaluate_mathematical_expression("2 ** 8") # Result: 256evaluate_mathematical_expression("sin(pi/2)") # Result: 1.0
evaluate_mathematical_expression("log10(1000)") # Result: 3.0
evaluate_mathematical_expression("sqrt(16) + cos(0)") # Result: 5.0evaluate_mathematical_expression("(2 + 3) * sqrt(16) / sin(pi/2)") # Result: 20.0
evaluate_mathematical_expression("factorial(5) + gcd(12, 8)") # Result: 124evaluate_mathematical_expression("5 × 3") # Result: 15
evaluate_mathematical_expression("20 ÷ 4") # Result: 5.0
evaluate_mathematical_expression("2 ^ 10") # Result: 1024MCP Mathematics includes a smart unit conversion system that works with 158 carefully calibrated units across 15 essential categories. This system does more than simple conversions—it provides smart unit detection, supports different spellings, handles complex compound units, and tracks your conversion history. This makes it perfect for scientific work, engineering calculations, and everyday conversions.
The conversion system automatically manages precision, accepts many different input formats, and works seamlessly with the mathematical expression engine for smooth integration in complex calculations.
Metric: m, km, cm, mm, nm, micron, angstrom
Imperial: mi, yd, ft, in
Astronomical: ly (light-years), AU (astronomical units), pc (parsecs)
Nautical: nmi (nautical miles)
Metric: kg, g, mg, ton (metric), t
Imperial: lb, oz, ton_us (short ton), ton_uk (long ton), st (stone)
Special: ct (carats), gr (grains), amu (atomic mass units)
Standard: s, min, h, d, wk, mo, yr
Sub-second: ms, us, ns, ps
Extended: decade, century, millennium, fortnight
K (Kelvin), C (Celsius), F (Fahrenheit)
Metric: m2, km2, cm2, mm2, hectare, are
Imperial: ft2, yd2, in2, mi2, acre, sqch (square chains)
Metric: L, mL, m3, cm3
US: gal, qt, pt, fl_oz, cup, tbsp, tsp
UK: gal_uk, qt_uk, pt_uk
Cubic: ft3, in3
m/s, km/h, mph, ft/s, knot, mach, cm/s, mi/min, in/s, c (speed of light percentage)
Binary: B, KB, MB, GB, TB, PB, EB, ZB
Bits: bit, Kbit, Mbit, Gbit, Tbit
IEC: KiB, MiB, GiB
Pa, kPa, MPa, atm, bar, mbar, psi, torr, mmHg, inHg
J, kJ, MJ, cal, kcal, Wh, kWh, BTU, eV, ft_lb, erg, therm
W, kW, MW, hp, PS, BTU/h, ft_lb/s, cal/s, erg/s, ton_refrigeration
N, kN, lbf, kgf, dyne, pdl, ozf, tonf
deg, rad, grad, arcmin, arcsec, turn
Hz, kHz, MHz, GHz, rpm, rad/s
mpg, mpg_uk, L/100km, km/L, mi/L, gal/100mi
MCP Mathematics supports common unit aliases for convenience:
convert_between_measurement_units(
100, "kilometers", "miles", "length"
) # Works with full names
convert_between_measurement_units(100, "km", "mi", "length") # Works with abbreviations
convert_between_measurement_units(
100, "metre", "yard", "length"
) # Supports alternate spellingsThe system automatically figures out unit types from context:
convert_between_measurement_units(
100, "kg", "lb", "mass"
) # Automatically detects mass conversionParse and handle complex compound units:
parse_compound_unit("m/s²") # Acceleration units
parse_compound_unit("kg·m/s²") # Force unitsAutomatic formatting for very large or small values:
format_scientific_notation(0.000001, precision=2) # 1.00e-6
format_scientific_notation(1000000, precision=2) # 1.00e+6Track all conversions with timestamps:
convert_with_history(100, "m", "ft", precision=2) # Stores in history
conversion_history.get_recent(10) # Retrieve last 10# Length conversions
convert_between_measurement_units(100, "meters", "feet", "length") # 328.084
convert_between_measurement_units(1, "mile", "kilometers", "length") # 1.60934
# Mass conversions
convert_between_measurement_units(1, "kg", "pounds", "mass") # 2.20462
convert_between_measurement_units(100, "grams", "ounces", "mass") # 3.52740
# Temperature conversions
convert_between_measurement_units(0, "C", "F", "temperature") # 32
convert_between_measurement_units(100, "F", "C", "temperature") # 37.7778
# Data storage conversions
convert_between_measurement_units(1024, "MB", "GB", "data") # 1.024
convert_between_measurement_units(1, "TB", "bytes", "data") # 1099511627776MCP Mathematics includes a complete set of financial tools designed for professional use, education, and personal money management. The financial system supports advanced calculations including compound interest modeling, loan analysis, tax calculations, and business financial work.
All financial functions use high precision to make sure you get accurate money calculations and support different compounding frequencies, payment schedules, and tax situations you'll find in real-world financial work.
calculate_percentage(1000, 15) # 150 (15% of 1000)
calculate_percentage_of(50, 200) # 25 (50 is 25% of 200)
calculate_percentage_change(100, 150) # 50 (50% increase)# Simple Interest
calculate_simple_interest(1000, 5, 10)
# Returns: {"interest": 500, "amount": 1500}
# Compound Interest
calculate_compound_interest(1000, 5, 10, 12) # Monthly compounding
# Returns: {"amount": 1647.01, "interest": 647.01}# Calculate monthly payment
calculate_loan_payment(100000, 5, 30, 12) # $100k, 5%, 30 years, monthly
# Returns: {"payment": 536.82, "total_paid": 193255.78, "interest_paid": 93255.78}# Calculate tax (inclusive or exclusive)
calculate_tax(100, 10, is_inclusive=False) # 10% tax on $100
# Returns: {"amount": 100, "tax": 10, "total": 110}
calculate_tax(110, 10, is_inclusive=True) # Price includes 10% tax
# Returns: {"amount": 100, "tax": 10, "total": 110}# Split bill with tip
split_bill(100, 4, tip_percent=20)
# Returns: {"total": 120, "per_person": 30, "tip": 20}
# Calculate tip
calculate_tip(100, 18) # 18% tip on $100
# Returns: 18# Calculate discount
calculate_discount(100, 20) # 20% off $100
# Returns: {"original": 100, "discount": 20, "final": 80}
# Calculate markup
calculate_markup(100, 25) # 25% markup on $100 cost
# Returns: {"cost": 100, "markup": 25, "price": 125}MCP Mathematics is built as an enterprise-grade mathematical computation platform that combines strong security measures with production-ready architecture. The system is designed to handle mission-critical calculations while maintaining the highest standards of code quality and security.
Zero-Trust Architecture: Every input is checked and every operation is verified
Defense in Depth: Multiple security layers give you complete protection
Principle of Least Privilege: Only essential operations are allowed
Fail-Safe Defaults: Safe defaults stop accidental security issues
AST Evaluation Engine: Every mathematical expression is processed through an Abstract Syntax Tree before evaluation, which stops code injection attacks while keeping full mathematical capability
Operation Whitelisting: Only specifically approved mathematical operations and functions can run, which stops unauthorized code execution
Input Sanitization: Thorough checking of all expressions and parameters before processing
Error Containment: Complete error handling makes sure calculation failures don't affect system security
Dependency Minimization: Core features need no external libraries, which greatly reduces security risks
Type Safety: Complete type annotations using Python 3.10+ features make sure you catch errors at compile-time
Clean Architecture: Modular design with clear separation of concerns makes maintenance and scaling easier
Professional Codebase: Production-ready code with no debug statements, console logs, or unnecessary comments
Complete Testing: 130 unit tests give you thorough coverage across all mathematical functions and edge cases
Automated Quality: Code standards enforced through Black formatting and Ruff linting
Optimized Computation: Efficient algorithms and data structures for high-performance calculations
Advanced Memory Management: Bounded LRU and TTL cache systems with automatic cleanup stop memory leaks in long-running processes
Thread-Safe Concurrency: 100% reliable concurrent execution using Timer-based timeouts instead of signal-based approaches
Session Management: Graceful resource cleanup and session handling for enterprise environments
Error Recovery: Proper exception chaining with better traceability for debugging and monitoring
Scalability: Architecture designed to handle high-volume calculation workloads with concurrent processing
This complete guide gives you everything you need to contribute to MCP Mathematics, from setting up your development environment to building production-ready distributions. The project follows strict quality standards and automated workflows to make sure everything works reliably and stays maintainable.
# Ensure Python 3.10+ is installed
python --version # Should be 3.10 or higher
# Clone the repository
git clone https://github.com/SHSharkar/MCP-Mathematics.git
cd MCP-Mathematics
# Create virtual environment
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
# Install development dependencies
pip install -e ".[dev]"Run the comprehensive test suite covering all 130 test cases:
# Run all tests with detailed output
python -m pytest tests/ -v
# Run tests with coverage reporting
python -m pytest tests/ --cov=src --cov-report=html
# Run specific test categories
python -m pytest tests/test_calculator.py -v # Core functionality
python -m pytest tests/test_unit_conversion.py -v # Unit conversions
python -m pytest tests/test_financial.py -v # Financial calculationsKeep professional code standards with automated quality tools:
# Auto-format code with Black (100-character line limit)
black src/ tests/ --line-length 100
# Comprehensive linting with Ruff
ruff check src/ tests/ --fix
# Type checking with mypy
mypy src/
# Run complete pre-commit validation
pre-commit run --all-files# Security analysis
bandit -r src/
# Performance profiling for mathematical operations
python -m cProfile -s cumtime scripts/benchmark.py
# Memory usage analysis
python -m memory_profiler scripts/memory_test.pyCreate optimized distribution packages for PyPI:
# Install build tools
pip install build twine
# Clean previous builds
rm -rf dist/ build/
# Build source and wheel distributions
python -m build
# Verify package integrity
twine check dist/*
# Test installation in clean environment
pip install dist/*.whl# Tag release version
git tag -a v1.0.0 -m "Release version 1.0.0"
# Push tags to trigger CI/CD
git push origin --tags
# Upload to PyPI (maintainers only)
twine upload dist/*MCP Mathematics gives you clear, helpful error messages to help you figure out what went wrong:
Syntax Errors: Clear identification of malformed expressions
Division by Zero: Smooth handling of mathematical impossibilities
Invalid Functions: Helpful messages when unknown functions are called
Type Errors: Detailed information about incompatible operations
Empty Expressions: Helpful feedback when input is missing
Python 3.10 or higher
MCP SDK 1.4.1 or later
MCP Mathematics is released under the MIT License. Copyright © 2025 Md. Sazzad Hossain Sharkar
Md. Sazzad Hossain Sharkar GitHub: @SHSharkar Email: md@szd.sh
We welcome contributions that maintain our high standards for code quality. When you contribute:
Write clean, comment-free production code
Include complete type annotations
Add complete test coverage for new features
Keep a clean, logical git history
MCP Mathematics is built on the Model Context Protocol (MCP) specification developed by Anthropic, extending it with production-ready mathematical capabilities designed for professional use.
Number theory operations
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Integer to analyze | |
| operation | Yes | Number theory operation (is_prime, prime_factors, divisors, totient) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must disclose behavior. It says 'Number theory operations' but does not mention whether it is read-only, requires authentication, or how it handles errors. The safety profile is unclear.
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 a single short sentence, which is concise but lacks structure and essential details. It is under-specified rather than efficiently informative.
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 moderate complexity (2 params, many sibling tools), the description is incomplete. It does not explain outputs, differentiate from similar tools, or provide behavioral context, despite the output schema existing.
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 coverage is 100% with clear parameter descriptions (number: 'Integer to analyze', operation: 'Number theory operation (is_prime, prime_factors, divisors, totient)'). The description adds no extra semantic value beyond the schema, earning a baseline score of 3.
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 'Number theory operations' is vague and does not specify a clear verb+resource. The title 'Number Theory' is equally generic. The schema shows operations like is_prime, prime_factors, divisors, totient, but the description omits these, making it unclear what the tool does.
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?
No guidance on when to use this tool vs. alternatives like calculate_expression or calculate_statistics. The description provides no context for selection, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch calculate expressions
| Name | Required | Description | Default |
|---|---|---|---|
| expressions | Yes | List of mathematical expressions to evaluate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Batch calculate expressions' without mentioning side effects, performance implications, or error handling, leaving the agent uninformed.
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 only 3 words, which is excessively brief. While short, it lacks necessary information such as what constitutes a valid expression or return behavior, making it under-specified.
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 of batch evaluation and the existence of many sibling tools, the description is insufficient. It does not mention output format, supported operations, or error modes, relying solely on the output schema which is not described.
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 coverage is 100% and the parameter 'expressions' is well-described in the schema. The description adds no extra meaning, but the schema suffices, so baseline 3 applies.
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 'Batch calculate expressions' states the action and resource but is vague. It does not clarify that it processes multiple expressions in a single call, which would distinguish it from siblings like 'calculate_expression'.
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 no guidance on when to use this tool versus alternatives, such as 'calculate_expression' for single expressions or 'session_calculate' for session context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate math expression
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | Mathematical expression to evaluate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. The single sentence 'Evaluate math expression' provides no information about side effects, error handling, limitations, or safety (though calculating is inherently read-only). It adds minimal value beyond the name.
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 concise (three words) but lacks structure or front-loading of key information. It is not verbose, but the brevity sacrifices clarity and does not earn its place as a complete sentence.
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 simplicity (one parameter, no nested objects, output schema exists), the description is partially complete. However, it omits details like supported expression syntax, error behavior, or variable support, leaving gaps for the 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 baseline is 3. The description 'Evaluate math expression' adds no new meaning beyond the schema's parameter description 'Mathematical expression to evaluate'. No extra semantics are provided.
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 action (evaluate) and resource (math expression), but does not differentiate from sibling tools like batch_calculate or session_calculate. It lacks specificity about scope or context.
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?
No guidance is provided on when to use this tool versus alternatives such as batch_calculate or convert_natural_language. There are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate statistics
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | List of numbers to analyze | |
| operation | Yes | Statistical operation (mean, median, mode, stdev, etc.) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure, but it provides none. It does not contradict annotations (since there are none), but also fails to convey side effects, permissions, or limitations.
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 extremely short, but it is not concise—it is under-specified. A single sentence that only repeats the name wastes the opportunity to provide useful information.
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?
Although an output schema exists, the description does not explain what the tool returns. Given 17 sibling tools, the description fails to provide enough context for an AI agent to select this tool correctly.
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 explains both parameters (data array and operation string). The description adds no additional meaning, but a baseline of 3 is appropriate given high schema coverage.
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 "Calculate statistics" is a tautology that merely restates the tool name and title. It provides no specific verb-resource combination or scope, and fails to distinguish from siblings like batch_calculate or matrix_operation.
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 offers no guidance on when to use this tool versus its many siblings (e.g., analyze_number_theory, memory_statistics). There is no mention of context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear history
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden for behavioral disclosure. It says nothing about side effects (e.g., irreversibility, what data is affected, or any confirmation required).
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?
While extremely concise, the description is under-specified. It consists of a single word that provides no useful structure or front-loading of key information.
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?
For a tool with no parameters and no annotations, the description should explain the scope, effects, and return value. The one-word description is completely inadequate.
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?
Input schema has zero parameters with 100% coverage, but the description adds no meaning beyond the schema. It fails to contextualize the operation, such as explaining what 'history' refers to or the result of clearing.
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?
Tautological: description restates name/title.
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?
No guidance is provided on when to use this tool vs alternatives. The sibling tools include several history-related and session-related tools, but the description offers no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Natural language conversion
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language conversion request |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it provides none. There is no mention of side effects, performance, or any behavior beyond the tautology.
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?
At only 3 words, the description is under-specified, not concise. It lacks structure and fails to provide any substantive information.
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?
Despite having an output schema, the description does not compensate for the lack of purpose, usage, or behavioral context. It is wholly inadequate for a tool with one parameter and many siblings.
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?
Although schema coverage is 100%, the parameter description 'Natural language conversion request' adds no meaning beyond the field name. The description is redundant and uninformative.
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?
Tautological: description restates name/title.
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?
No guidance is given on when to use this tool versus sibling tools like convert_units or calculate_expression. The description lacks any context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unit conversion
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Numeric value to convert | |
| from_unit | Yes | Source unit | |
| to_unit | Yes | Target unit | |
| unit_type | Yes | Unit category (length, mass, time, temperature, etc.) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral details (e.g., supported unit categories, error handling, or return format). Minimal disclosure for a simple conversion tool.
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?
Extremely concise (two words) but under-specified. Lacks any structure or helpful context; does not earn its place.
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 simplicity and rich schema, the description fails to add contextual completeness (e.g., supported unit types or usage examples). Leaves agent guessing.
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 baseline is 3. The description itself adds no meaning beyond schema, but schema already documents parameters adequately.
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?
Tautological: description restates name/title.
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?
No guidance on when to use this tool vs alternatives such as 'convert_natural_language' or 'calculate_expression'. No usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create session
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Optional session identifier | |
| variables | No | Initial session variables |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it says nothing about side effects, idempotency, authorization needs, or what happens if the session already exists. This is a critical gap.
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 extremely short but at the cost of necessary information. It is under-specified rather than appropriately concise.
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 presence of sibling tools and an output schema, the description fails to provide sufficient context about return values, scope, or behavior. It leaves the agent with many unanswered questions.
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 coverage is 100% with descriptions for both parameters. The description adds no extra meaning, so baseline score of 3 is appropriate.
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?
Tautological: description restates name/title.
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?
No guidance is provided on when to use this tool versus alternative session-related tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete session
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session identifier |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behaviors like idempotency, side effects, or permissions. It simply says 'Delete session' without any behavioral detail.
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?
While only two words, the description is under-specified rather than appropriately concise. It lacks essential context and does not earn its place as a meaningful explanation.
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?
The tool is simple with one parameter and an output schema, but the description does not mention return values or effects. It fails to provide a complete picture 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% for the single parameter 'session_id', which is already documented as 'Session identifier'. The description adds no further meaning, so baseline score applies.
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?
Tautological: description restates name/title.
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?
No guidance is provided on when to use this tool, its prerequisites, or how it differs from alternatives like creating or listing sessions. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get calculation history
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent calculations to retrieve |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must disclose behavior. It only states 'Get calculation history', which implies a read operation but does not explicitly confirm safety or mention any side effects, authentication needs, or potential limitations. This is insufficient for a tool with no annotation support.
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 extremely short (one sentence) but lacks substance. While it is concise, it does not earn its place with meaningful content; it is closer to under-specification than efficient communication.
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?
Despite having an output schema and a single optional parameter, the description fails to provide context about what constitutes 'calculation history' or how it relates to sessions or users. Important for a tool that could be ambiguous among many siblings, but left unaddressed.
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 coverage is 100%, so the schema already documents the 'limit' parameter with a default and description. The tool description adds no extra information about the parameter's purpose or constraints beyond what the schema provides, meeting the baseline but not exceeding it.
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 'Get calculation history' provides a verb+resource combination that is clear in a basic sense, but it lacks specificity about the scope or context of the history (e.g., per session, global). It distinguishes itself from siblings like clear_history, but not strongly.
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?
No guidance is provided on when to use this tool versus alternatives such as session_calculate or clear_history. The description does not mention any conditions or preferences, leaving the agent with no help in choosing between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List functions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits, but it only says 'List functions' with no mention of read-only, safety, or side effects.
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?
While extremely concise at two words, it sacrifices completeness and fails to be helpful; conciseness should not come at the cost of clarity.
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?
With no annotations, no parameter details, and only a bare description, the tool lacks sufficient context for an agent to use it appropriately.
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?
The input schema has zero parameters, so the description does not need to explain them. Baseline 4 applies as no parameter info is required.
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?
Tautological: description restates name/title.
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?
No guidance is provided on when to use this tool versus siblings like calculate_expression or session_calculate, leaving the agent without differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List session variables
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session identifier |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear full burden. It states 'list' implying a non-destructive read, but fails to disclose behavior on missing session, authorization needs, or any side effects. The tool name suggests safety, but no explicit assurance.
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 a single, clear sentence with no redundancy. It is appropriately sized for a simple tool, but could benefit from a brief note on what 'session variables' entails.
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?
The tool has one parameter and an output schema (not provided). The description is minimal but functional for a straightforward list operation. However, it lacks explanation of return format or edge cases, making it just adequate.
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 coverage is 100% and the parameter has a minimal description 'Session identifier'. The tool description adds no additional meaning beyond that. Given high coverage, baseline 3 is appropriate.
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?
Tautological: description restates name/title.
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?
No guidance on when to use this tool versus alternatives like get_calculation_history or security_status. The description does not mention prerequisites, expected context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Matrix operations
| Name | Required | Description | Default |
|---|---|---|---|
| matrices | Yes | List of matrices for operation | |
| operation | Yes | Matrix operation (multiply, determinant, inverse) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must fully convey behavioral traits. The description only says 'Matrix operations', giving no insight into side effects, permissions, or return behavior. It fails to disclose that operations like 'determinant' require a single matrix or that 'inverse' may fail for singular matrices.
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 extremely short (two words), but this is under-specification rather than conciseness. It fails to provide necessary context, wasting the opportunity to add value.
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?
For a tool with 2 required parameters and an output schema, the description is completely inadequate. It does not explain how to provide matrices, what operations are supported, or the return format, leaving the agent with no actionable guidance.
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 coverage is 100%, so the schema documents both parameters. The description adds no additional meaning beyond the parameter names and types, but the baseline of 3 is appropriate as the schema itself is sufficient.
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?
Tautological: description restates name/title.
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?
No usage context or guidelines are provided. The agent receives no information about when to use this tool versus alternatives, such as analyze_number_theory or batch_calculate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read operation via 'Get', but does not explicitly confirm no side effects, rate limits, or authentication requirements. The word 'statistics' is ambiguous.
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 a single short sentence, front-loaded with the verb. It is concise but lacks expansion, which might be acceptable for a simple tool but risks under-specification.
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 simplicity (0 params, output schema exists), the description is partially complete. It states the core function but fails to clarify what 'memory statistics' entails or how it differs from similar tools like performance_metrics.
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?
There are no parameters (schema coverage 100%), so the description adds no param info beyond schema. Baseline score is appropriate as it is impossible to add more meaning for zero parameters.
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 'Get memory statistics' specifies a verb and resource, but is vague about what 'memory statistics' refers to (e.g., application vs. system memory). It does not distinguish from sibling tools like performance_metrics or optimize_memory, which likely provide related but different data.
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?
No guidance is provided on when to use this tool vs. alternatives such as performance_metrics or optimize_memory. The user must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize memory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description should disclose behaviors. It merely states 'Optimize memory' without detailing whether it is destructive, requires specific permissions, or has side effects.
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?
Extremely concise (two words) but does not earn its place as it adds minimal value beyond the title. Acceptable length but lacking substance.
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 no annotations and no parameter details, the description is incomplete. It fails to explain what memory is optimized, the operation's nature (read/write), or possible outcomes.
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?
No parameters exist, so the description cannot add meaning beyond the empty schema. Trivially meets the baseline for 0 parameters.
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?
Tautological: description restates name/title.
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?
No guidance on when to use this tool versus alternatives. No context on prerequisites or conditions for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It fails to disclose any behavioral traits beyond the name, such as what metrics are returned or any side effects.
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?
Extremely short at three words, but it is under-specified. Conciseness does not compensate for lack of useful information.
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?
An output schema exists, so return values are covered, but the description still lacks context about what 'performance metrics' entails. Incomplete for any meaningful use.
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?
No parameters exist, and schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema.
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 states the verb 'Get' and resource 'performance metrics', which is clear but vague. It does not distinguish from siblings, but no sibling is specifically about performance metrics.
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?
No guidance on when to use this tool versus alternatives. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get security status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but otherwise no behavioral traits (e.g., authentication needs, rate limits, result nature) are mentioned.
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 a single sentence, which is concise. However, it is essentially a restatement of the title, adding only the verb 'Get'. It is minimally adequate but not exceptionally 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 has no parameters and an output schema exists (thus return values need not be explained), the description is minimally complete. However, it does not elaborate on the meaning or scope of 'security status'.
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?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter details since none exist. It appropriately does not confuse the agent with extraneous information.
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 'Get security status' clearly specifies the action (get) and resource (security status). It is distinct from siblings like 'performance_metrics' by topic, but does not explicitly differentiate itself.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it state any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Session calculation
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session identifier | |
| expr | Yes | Mathematical expression to evaluate | |
| var_name | No | Variable name to store result |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, and the description provides no behavioral information beyond the name. It does not clarify whether the tool mutates session state, requires specific permissions, or what the return value is, despite an output schema existing.
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?
While very short, it is under-specified rather than concise. It lacks essential information to be considered 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 complexity (3 parameters, output schema, many similar siblings), the description is completely inadequate. It fails to explain what a session calculation is, how it differs from other calculation tools, or how to use it effectively.
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 documents all parameters. The description adds no extra meaning beyond the parameter titles, so it meets the baseline of 3.
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?
Tautological: description restates name/title.
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?
No guidance on when to use this tool vs alternatives such as calculate_expression or batch_calculate. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.3.1analyze_number_theorybatch_calculatecalculate_expressioncalculate_statisticsclear_historyconvert_natural_languageconvert_unitscreate_sessiondelete_sessionget_calculation_historylist_functionslist_session_variablesmatrix_operationmemory_statisticsoptimize_memoryperformance_metricssecurity_statussession_calculateMost tools have distinct purposes, but calculate_expression, batch_calculate, and session_calculate could cause confusion since all involve evaluating expressions. Memory_statistics and performance_metrics also overlap slightly.
Naming is inconsistent: the majority use verb_noun pattern (e.g., calculate_expression, clear_history), but several use noun_noun (e.g., matrix_operation, memory_statistics) or noun_verb (session_calculate), breaking the pattern.
18 tools is on the higher side for a mathematics server, with many system utilities (memory, performance, security) that are not core to math. Could be streamlined to 10-12 essential tools.
The tool set covers basic arithmetic, statistics, number theory, and matrices, but misses common math areas like algebra, calculus, geometry, and equation solving. Inclusion of non-math tools (memory, security) dilutes completeness for a math-focused server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SHSharkar/MCP-Mathematics'
If you have feedback or need assistance with the MCP directory API, please join our Discord server