Skip to main content
Glama
Sign In
kimi94279-glitch

openstem-mcp

by kimi94279-glitch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

수식 검산

verify_math
Read-only

Verify math steps and answers with SymPy, including equations, calculus, matrices, and probability; compare equivalent forms and get numeric counterexamples when matches fail.

Instructions

Check math with sympy: a solution step, or whether an answer equals a reference in another form. You solve; this only computes. ops: equal (expr vs against → matches true/false/"unknown", plus a numeric check at 5 random points), simplify, solve (equation "x2 = 4", inequality "x2 > 4", system "x + y = 3; x - y = 1" with var="x, y"; var also isolates a formula), diff (order), integrate (bounds → definite), limit (point "0", "oo", "0+", "0-"), evaluate (point "x=2, y=3"), ode (expr "y'' + 3y' + 2y = sin(x)", ics "y(0)=1, y'(0)=0"; against = your solution's right-hand side), matrix (matrix rows → det, rank, inverse, eigen, rref; expr "det, eigen" picks; matrix_b → A·B), laplace (in t), inverse_laplace (in s), series (point, order), sum (bounds [1, "oo"], index n), probability (dist Normal(mean, std) | Binomial(n, p) | Poisson(λ) | Exponential(rate) | Uniform(a, b); expr is an event "X > 1.96" or a quantity "X**2" for its expectation). Example: {"op": "equal", "expr": "sin(x)2", "against": "(1 - cos(2*x))/2"} Syntax: x2, sqrt, exp, log (= ln), log10, abs, factorial; constants are pi and e only (E is a variable); radians. Physical quantities: assume="positive". Decimals become fractions; numeric comparison is relative, so 9.8 ≠ 9.81. latex=true reads expr and against as LaTeX (not for ode, matrix, probability, inequalities; send the integrand without \int). Check parsed and read note. matches=false: numeric.counterexample shows where it breaks. "unknown": judge from numeric and say so. On failure: errors name the input and character; fix and call again. Timeout: split into smaller steps.

Input Schema

NameRequiredDescriptionDefault
opYes
icsNoode initial conditions
varNoVariable: "x, y" for systems, "t" for ode/laplace, "n" for sum
distNo"Normal(0, 1)"
exprNoExpression, equation or inequality (sympy syntax)
latexNo
orderNodiff order / series degree (0 = default)
pointNolimit "0+", evaluate "x=2", series center
assumeNoreal
boundsNo[0, "pi"], [1, "oo"]
matrixNoRows: [["1", "2"], ["3", "4"]]
againstNoequal: the other expression / ode: your solution
matrix_bNoB for A·B

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations indicate read-only and closed-world, and the description adds substantial behavioral detail: it computes via sympy, does not solve, reports 'unknown' with numeric checks, provides counterexamples for mismatches, and describes error and timeout handling. This goes well beyond the annotations.

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

Conciseness4/5

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

The description is dense but well-organized, with a clear opening, an enumerated ops list, an example, and syntax notes. It is appropriately sized for a tool with 14 operations and 13 parameters, though the ops list is somewhat run-on and could benefit from slightly more structure.

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 tool's complexity (14 ops, 13 params, no output schema), the description is thorough: it covers all operations, their parameter usage, syntax rules, constants, error handling, and return semantics for key ops. No critical gaps remain for an agent to invoke it correctly.

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?

Despite 77% schema coverage, the description extensively documents how each parameter applies to specific operations (e.g., var for solve/diff/ode, bounds for sum, against for equal/ode, dist for probability). It adds op-specific meaning and syntax examples that enrich the 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: 'Check math with sympy: a solution step, or whether an answer equals a reference in another form. You solve; this only computes.' It distinguishes from a solver and from sibling tools like plotting or rendering by specifying computational verification.

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?

It provides clear context on when to use it: for checking math expressions or answers, not for solving. It implies boundaries with 'You solve; this only computes' and gives guidance on failure and timeouts. However, it does not explicitly name alternatives or when to avoid it beyond the solve/compute distinction.

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

Deploy Server

Other Tools