How do I use math-logic-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@math-logic-mcp solve x^2 - 4 = 0" 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.

math-logic-mcp

by ismailkerimov

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Click on "Deploy 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., "@math-logic-mcp solve x^2 - 4 = 0"

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.

math-logic-mcp

MCP server that gives small LLMs verified symbolic-math & logic tools.

$PyPI$ $License$

Small language models (Mistral, Llama, Phi, Gemma) struggle with multi-step math and formal logic. Instead of fine-tuning, give them tools. This project exposes a set of verified math and logic solvers via the Model Context Protocol (MCP), so any MCP-compatible LLM can call them as functions.

Features

Tool	What it does	Backend
`verify_arithmetic`	Safe arithmetic evaluation	Python stdlib (zero deps)
`solve_equation`	Symbolic equation solving	SymPy (optional)
`simplify_expression`	Simplify / factor / expand	SymPy (optional)
`compute_derivative`	Differentiation	SymPy (optional)
`compute_integral`	Integration	SymPy (optional)
`check_logic`	SAT / tautology / truth tables	Z3 (optional)

Every result includes proof steps and verification — the LLM gets a machine-checked answer, not a guess.

Related MCP server: Chiasmus

Quick Start

Install from PyPI

pip install math-logic-mcp

Install (full — all solvers)

pip install "math-logic-mcp[full]"

Run the MCP server

# stdio transport (for Claude Desktop, Cursor, etc.)
math-logic-mcp

# HTTP/SSE transport (for remote clients)
math-logic-mcp --http

Configure in Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "math-logic": {
      "command": "math-logic-mcp"
    }
  }
}

Configure in Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "math-logic": {
      "command": "math-logic-mcp"
    }
  }
}

Use as a Python Library

from math_logic import MathLogicEngine

engine = MathLogicEngine()

# Arithmetic (always available)
result = engine.solve("compute 2 + 3 * 4")
print(result.solutions)  # ['14']

# Algebra (requires sympy)
result = engine.solve("Solve x^2 - 4 = 0")
print(result.solutions)  # ['x = -2', 'x = 2']

# Logic (requires z3-solver)
result = engine.solve('Check satisfiability of "p and q"')
print(result.solutions)  # ['Satisfiable: p=True, q=True']

Architecture

LLM ─── MCP Protocol ──▶ mcp_server.py
                              │
                          engine.py  (router → solver → result)
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
     ArithmeticSolver   SymPySolver      Z3Solver
      (zero deps)       (pip: sympy)    (pip: z3-solver)

The router classifies each problem by regex patterns and routes to the best available solver. Solvers are loaded lazily — if SymPy isn't installed, algebra problems gracefully report the missing dependency.

Installation Extras

Extra	What it adds	Install size
(none)	Arithmetic only	~1 MB
`[sympy]`	+ algebra, calculus, simplification	~50 MB
`[z3]`	+ propositional logic, SAT	~30 MB
`[full]`	Everything	~80 MB
`[dev]`	+ pytest, ruff	~85 MB

pip install "math-logic-mcp[sympy]"      # algebra + calculus
pip install "math-logic-mcp[z3]"         # logic
pip install "math-logic-mcp[full]"       # everything
pip install "math-logic-mcp[full,dev]"   # everything + dev tools

Development

git clone https://github.com/ismailkerimov/math-logic-mcp.git
cd math-logic-mcp
pip install -e ".[full,dev]"
pytest tests/ -v

Docker

docker build -t math-logic-mcp .
docker run -p 8080:8080 math-logic-mcp

License

Apache 2.0 — see LICENSE.

Available Tools

6 tools

check_logicCheck LogicA

Read-onlyIdempotent

Check a propositional logic formula for satisfiability, tautology, or generate a truth table.

ParametersJSON Schema

Name	Required	Description	Default
`formula`	Yes	A Boolean formula using variables and operators (and/&, or/\|, not/!, ->/implies). Examples: 'p and (q or r)', '(p -> q) and (q -> r) -> (p -> r)'
`check_type`	No	Type of check: 'satisfiability', 'tautology', or 'truth_table'.	satisfiability

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, which align with the description. The description adds the specific check types, which are also reflected in the schema, so minimal additional transparency beyond annotations.

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?

Single sentence front-loading the verb 'Check' and listing all key operations with no wasted words.

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?

With an output schema present, the description sufficiently covers all input semantics and behavior. No gaps for a logic-checking tool.

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%. The description supplements by providing formula examples and clarifying check_type values, adding value beyond the schema alone.

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 explicitly states three distinct actions (satisfiability, tautology, truth table) on propositional logic formulas, clearly distinguishing it from siblings which are calculus and algebra tools.

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 lists the three check types, providing context for when each might be used. No explicit exclusions needed since siblings are unrelated domains.

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

compute_derivativeCompute DerivativeA

Read-onlyIdempotent

Compute the derivative of a mathematical expression with proof steps.

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	The mathematical expression to differentiate. Example: 'x^3 + 2x^2 - 5x + 1'
`variable`	No	The variable to differentiate with respect to.	x

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds 'with proof steps' but does not disclose additional behavioral traits. No contradiction.

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?

One sentence of 11 words, front-loaded, with no wasted information. Ideal conciseness.

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 an output schema exists (return values documented elsewhere) and annotations cover safety, the description is mostly complete. Could mention supported functions or limitations, but adequate for the task.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions. The description does not add meaning beyond what the schema provides.

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 action (compute derivative), resource (mathematical expression), and distinctive feature (with proof steps). Among siblings like compute_integral, it is unambiguous.

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 explicit guidance on when to use this tool versus alternatives like compute_integral or simplify_expression. The description does not mention when not to use it or provide context for choosing among siblings.

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

compute_integralCompute IntegralA

Read-onlyIdempotent

Compute the indefinite integral of a mathematical expression with proof steps.

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	The mathematical expression to integrate. Example: '3x^2 + 4x'
`variable`	No	The variable to integrate with respect to.	x

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds that the tool returns proof steps, which is useful behavioral context beyond annotations.

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, clear, and informative sentence with no unnecessary words.

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?

Given the simple parameter set (2 params, 1 required), high schema coverage, and presence of an output schema, the description is complete enough for an agent to understand and invoke the tool correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the description does not need to add much. It does not provide additional meaning beyond what the schema already conveys for the two parameters.

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 'Compute the indefinite integral', which is a specific verb and resource. It also mentions 'with proof steps', adding unique value. This distinguishes it from sibling tools like 'compute_derivative'.

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

Usage Guidelines3/5

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

The description implies usage for finding indefinite integrals but does not provide explicit guidance on when to prefer this tool over siblings or mention any prerequisites or limitations.

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

simplify_expressionSimplify ExpressionA

Read-onlyIdempotent

Simplify, factor, or expand a mathematical expression with proof steps.

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	A math expression with an operation verb. Examples: 'simplify (x^2 - 1)/(x - 1)', 'factor x^2 - 5x + 6', 'expand (x + 1)^3'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by noting the tool returns 'proof steps', which is beyond what annotations provide.

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

Conciseness4/5

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

The description is a single, clear sentence that is front-loaded with the tool's purpose. It is appropriately sized but could benefit from slightly more structure.

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?

Despite one parameter and full schema coverage, the description mentions the output includes 'proof steps', which is helpful. With an output schema present, the description is sufficiently complete for an agent to understand and use the tool.

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

Parameters3/5

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

Schema description coverage is 100% with a detailed description and examples for the 'expression' parameter. The tool description adds no extra parameter information beyond the schema, so a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool can 'Simplify, factor, or expand a mathematical expression' and mentions 'proof steps', clearly differentiating it from siblings like solve_equation or compute_derivative.

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

Usage Guidelines3/5

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

The description implies usage for algebraic manipulation but does not explicitly state when to use this tool over alternatives like solve_equation or check_logic. No when-not or alternative guidance is provided.

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

solve_equationSolve EquationA

Read-onlyIdempotent

Solve an algebraic equation symbolically and return solutions with proof steps.

ParametersJSON Schema

Name	Required	Description	Default
`equation`	Yes	A math equation to solve. Examples: 'x^2 + 2x - 8 = 0', 'Solve 3x + 5 = 20', 'Find x if 2x - 7 = 3'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that it solves symbolically and returns proof steps, adding useful behavioral context.

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

Conciseness5/5

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

Single concise sentence with no wasted words, efficiently conveying the tool's purpose.

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 the simple input schema and presence of output schema, the description provides adequate context, though it could mention supported equation types.

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

Parameters3/5

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

Schema coverage is 100% with examples; the description adds no additional parameter meaning, so baseline score applies.

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 it solves algebraic equations symbolically with proof steps, distinguishing it from sibling tools like compute_derivative or simplify_expression.

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

Usage Guidelines2/5

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

No usage guidance is provided; it does not specify when to use this tool over siblings or mention any prerequisites or limitations.

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

verify_arithmeticVerify ArithmeticB

Read-onlyIdempotent

Safely evaluate an arithmetic expression using only whitelisted operators and functions.

ParametersJSON Schema

Name	Required	Description	Default
`expression`	Yes	A numeric expression to evaluate safely (no eval). Examples: '2 + 3 * 4', 'sqrt(144)', '2^10', 'factorial(10)', 'log(100, 10)'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only the word 'safely' and 'whitelisted,' which are implied by annotations. It does not disclose additional behavioral traits like error handling or expression parsing details.

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 sentence that immediately conveys the core function. It is concise with no redundant information or explanatory fluff.

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 simple tool with one highly documented parameter and an output schema, the description covers essential aspects. However, it lacks details about the whitelist of operators/functions, but these are illustrated in the schema examples.

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

Parameters3/5

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

Schema coverage is 100% with the 'expression' parameter clearly described and with examples. The tool description does not add further parameter-specific meaning beyond what the schema already provides.

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 'safely evaluate an arithmetic expression using only whitelisted operators and functions,' which precisely identifies the tool's action and resource. It is distinct from siblings like 'simplify_expression' or 'solve_equation' that perform different 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?

The description provides no guidance on when to use this tool versus alternatives such as 'check_logic' or 'compute_derivative.' It does not mention prerequisites, when not to use, or fallback options.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.2.0May 30, 2026
- First observedcheck_logic
- First observedcompute_derivative
- First observedcompute_integral
- First observedsimplify_expression
- First observedsolve_equation
- First observedverify_arithmetic

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-05-30 00:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct operation: propositional logic, derivatives, integrals, algebraic simplification, equation solving, and safe arithmetic evaluation. No two tools have overlapping purposes, making selection straightforward.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores, such as check_logic, compute_derivative, and solve_equation. The style is uniform and predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for a general math and logic server. It covers core areas without being bloated, balancing comprehensiveness and manageability.

Completeness3/5

While fundamental operations are present, notable gaps exist: no predicate logic, no limits or series, no linear algebra or matrix operations, and no statistical functions. This leaves several common math tasks unsupported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
DevSpeak
io.github.juanjaragavi
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
Developer Tools AI & Machine Learning Documentation Access
2
Proofable MCPOAuth
io.github.proofable
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
Security Agent Orchestration Autonomous Agents
1

Related MCP Servers

verifiable-thinking-mcp
Autonomous Agents Developer Tools
CoderDayton
A
license
B
quality
Not graded
maintenance
MCP server for structured reasoning with cognitive trap detection, verification, and context compression
Updated 7 months ago (2026-02-10 19:36 UTC)
5
41 npm
1
-
Chiasmus
Code Analysis Developer Tools
yogthos
A
license
Not graded
quality
A
maintenance
MCP server that gives LLMs access to formal verification via Z3 and SWI-Prolog, plus tree-sitter-based source code analysis. Translates natural language problems into formal logic using a template-based pipeline, verifies results with mathematical certainty, and analyzes call graphs for reachability, dead code, and impact analysis.
Updated 10 days ago (2026-09-04 19:34 UTC)
100 npm
212
Apache 2.0
SymKit
Knowledge & Memory Research & Data AI & Machine Learning
LBurny
A
license
B
quality
B
maintenance
MCP server for symbolic computation that enables AI agents to perform step-by-step derivations, transform formulas, and verify results with full provenance, combining natural language with formal mathematical operations.
Updated 3 days ago (2026-09-12 07:16 UTC)
41
12
Apache 2.0
slac-mcp
Code Execution Developer Tools
DennisPrediger
A
license
Not graded
quality
B
maintenance
MCP server exposing SLAC (Simple Logic & Arithmetic Compiler) as tools for LLM agents, enabling evaluation of expressions and retrieval of syntax reference.
Updated 2 months ago (2026-07-18 18:41 UTC)
Apache 2.0

math-logic-mcp

Features

Quick Start

Install from PyPI

Install (full — all solvers)

Run the MCP server

Configure in Claude Desktop

Configure in Cursor

Use as a Python Library

Architecture

Installation Extras

Development

Docker

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches