Skip to main content
Glama

math

Simplify, solve, differentiate, integrate, and transform mathematical expressions with one unified tool supporting over 25 symbolic operations.

Instructions

    Run mathematical operations (unified Mathematica-style tool)

    ═══════════════════════════════════════════════════════════════════════
    SymKit's core tool — supports ~25 mathematical operations.
    One tool handles derivation, calculation, solving, and transformation.
    ═══════════════════════════════════════════════════════════════════════

    **Supported operations (operation):**

    | Category | Operation | Description |
    |------|------|------|
    | Parse | `parse` | Parse expression and extract symbols |
    | Simplify | `simplify` | General simplification |
    | | `expand` | Expand polynomial |
    | | `factor` | Factorization |
    | | `collect` | Collect like terms (requires variable) |
    | | `cancel` | Cancel rational function |
    | | `apart` | Partial fraction expansion (requires variable) |
    | | `together` | Combine over common denominator |
    | | `trigsimp` | Trigonometric simplification |
    | | `powsimp` | Power simplification |
    | | `radsimp` | Radical simplification |
    | | `combsimp` | Combinatorial simplification |
    | Solve | `solve` | Solve for variable (requires variable) |
    | Substitute | `substitute` | Substitute variables (requires substitution dict) |
    | Calculus | `diff` | Differentiate (requires variable; order optional) |
    | | `integrate` | Integrate (variable, lower/upper optional) |
    | | `limit` | Limit (variable, point, direction) |
    | | `series` | Series expansion (variable, point, order) |
    | ODE | `dsolve` | Solve ODE (variable=function name, with_respect_to=independent variable) |
    | Vector | `gradient` | Gradient (variable="x,y,z" comma-separated coordinates) |
    | | `divergence` | Divergence |
    | | `curl` | Curl |
    | | `laplacian` | Laplacian |
    | Matrix | `det` | Determinant |
    | | `inv` | Inverse matrix |
    | | `eigenvals` | Eigenvalues |
    | | `eigenvects` | Eigenvectors |
    | Transform | `laplace` | Laplace transform (variable=time, with_respect_to=s) |
    | | `ilaplace` | Inverse Laplace transform (variable=s, with_respect_to=t) |
    | | `fourier` | Fourier transform |
    | | `ifourier` | Inverse Fourier transform |

    Args:
        operation: Operation name (see table above)
        expression: Mathematical expression (SymPy or LaTeX format)
        variable: Differentiation/integration/solving variable (for vector operations can be comma-separated like "x,y,z")
        with_respect_to: Second variable (independent variable for ODE, target variable for transforms)
        substitution: Substitution mapping {"var": "replacement", ...}
        point: Limit point / series expansion point (default "0")
        direction: Limit direction "+-", "+", "-"
        order: Differentiation order / number of series terms (default 1)
        lower: Definite integral lower bound
        upper: Definite integral upper bound
        assumptions: Symbolic assumptions ["x is positive", "t is real"]
        method: Simplification method "auto", "trig", "radical", "expand_then_simplify"
        session: True=record to derivation session, False=stateless computation
        description: Description of this step (used when recording to session)
        notes: Human insight (used when recording to session)

    Returns:
        Result dict containing expression, latex, operation

    Examples:
        # Stateless quick calculation
        math("diff", "x**3", variable="x")
        → {"expression": "3*x**2", "latex": "3 x^{2}"}

        # Substitute
        math("substitute", "m*a", substitution={"m": "2", "a": "9.8"})
        → {"expression": "19.6", ...}

        # Laplace transform
        math("laplace", "exp(-k*t)", variable="t", with_respect_to="s")
        → {"expression": "1/(k + s)", ...}

        # Vector calculus
        math("gradient", "x**2 + y**2 + z**2", variable="x,y,z")
        → gradient in vector form

        # Solve ODE
        math("dsolve", "diff(y,t) - k*y", variable="y", with_respect_to="t")
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lowerNo
notesNo
orderNo
pointNo
upperNo
methodNoauto
sessionNo
variableNo
directionNo+-
operationYes
expressionYes
assumptionsNo
descriptionNo
substitutionNo
with_respect_toNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations, the description carries full burden. It explains the unified nature, stateless vs. session recording (session parameter), and lists operations and parameters. It does not mention destructive behavior (likely none) or rate limits, but provides good context on behavior for a math tool.

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 long but well-structured with a summary, table of operations, parameter list, and examples. It is front-loaded and each section serves a purpose. Slightly verbose but justified due to the tool's complexity.

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?

The description is very complete: covers purpose, all operations, parameter semantics, return format (Result dict with expression, latex, operation), and examples. With an output schema existing, it goes beyond minimum. It covers edge cases like integral bounds and assumptions.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It does so excellently: each parameter is explained in the Args section, and the operation table indicates which parameters are required for each operation. This adds significant meaning beyond the raw schema.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Run mathematical operations (unified Mathematica-style tool)'. It lists ~25 operations, making it distinct from sibling tools which are about sessions, assumptions, formulas, etc. The description explicitly says it is SymKit's core tool for mathematical tasks.

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 mathematical operations but does not explicitly guide when to use this tool versus siblings like 'derive' or other tools. It lacks statements about when not to use it or alternatives. Usage is implied by the broad scope.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LBurny/symkit-mcp'

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