Skip to main content
Glama

Equation Steps

Equation Steps

run
Read-only

Solves a linear or quadratic equation in one variable (x) and returns every step: expanding parentheses, combining like terms, moving terms across the equals sign, and (for quadratics) applying the quadratic formula.

Use this whenever you need to solve "ax + b = cx + d" or "ax^2 + bx + c = 0" style equations, or check a step-by-step algebra solution someone else produced.

Do not solve this kind of equation by reasoning through it token by token: the two places language models most often go quietly wrong are (1) the sign when distributing a negative across parentheses, e.g. "5 - (x - 3)" losing the minus on the 3, and (2) dropping one of the two ± roots of a quadratic, or rounding a complex root into a false "no solution". This tool always gets both right because it does exact fraction arithmetic, not floating-point guessing, and reports every root it finds — including complex ones, explicitly labeled as complex.

Input: a single string containing exactly one "=", using x (or X) as the only variable, e.g. "3(x-2) = 5x + 4" or "(x+1)(x-3) = 2x^2 - 5". Numbers may be integers or decimals. Implicit multiplication is fine ("3x", "2(x+1)"). Exponents may only be "^2" on the bare variable — "(x+1)^2" is not supported; write "(x+1)(x+1)" instead.

Refuses rather than guesses on: no "=" or more than one, a second variable or a function name (sin, sqrt, log), a "/" anywhere (rewrite as a decimal), an unsupported exponent, an equation that expands past degree 2, unbalanced parentheses, or an inequality (<, >). Every refusal includes a fixHint saying exactly what to change.

Returns the equation type (linear, quadratic, identity, or contradiction), the standard form, the full list of steps, the solution(s) as exact fractions (with a decimal alongside when not a whole number), and a disclaimer that this covers only one-variable linear and quadratic equations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesTODO: state the exact format, units, and range.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only mark readOnlyHint=true and openWorldHint=false, so the description supplies the behavioral detail: exact fraction arithmetic, no floating-point guessing, explicit reporting of complex roots, and reliable refusal behavior with fixHint. It also states what the tool returns, including the equation type, standard form, steps, and disclaimer, which the annotations do not cover.

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 long but every section earns its place: purpose, usage guidance, failure modes, input syntax, refusals, and return values. The structure is logical and front-loaded, starting with the core operation before moving to constraints. There is no filler or repetition beyond what is useful for an agent.

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, the single schema parameter is underspecified, and there is no output schema, the description covers all necessary ground: what inputs are accepted, what is rejected and why, how numbers are handled, what steps are returned, and the scope limitations. An agent could invoke this tool correctly without additional clarification.

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?

Although the schema reports 100% description coverage, the actual property description is a placeholder: 'TODO: state the exact format, units, and range.' The tool description fully compensates by specifying the single-string format, allowed variables, examples, implicit multiplication, exponent limitations, and exact refusal conditions. This is far more semantic value than 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 states a specific verb and resource: it 'Solves a linear or quadratic equation in one variable (x) and returns every step.' It goes beyond a generic statement by naming the equation forms, the output content, and the scope (one variable, degree 2 max), so the tool's purpose is unambiguous even without siblings.

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

Usage Guidelines5/5

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

It explicitly tells the agent when to use the tool ('Use this whenever you need to solve ...'), and more importantly tells it when not to silently reason: 'Do not solve this kind of equation by reasoning through it token by token.' It also enumerates refusal cases, making the conditions for using or not using the tool explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

With only one tool, there is no possibility of an agent mistaking it for another operation. The description clearly scopes the tool to one-variable linear and quadratic equations.

Naming Consistency3/5

There are no mixed conventions because only one tool exists, but 'run' is a generic verb that gives no hint of the equation-solving domain. A name like solve_equation would align better with the server's purpose.

Tool Count3/5

A single tool feels thin for a general-purpose MCP server, but it is defensible here because the server is narrowly focused on solving one-variable linear/quadratic equations with steps. The scope is coherent rather than bloated.

Completeness5/5

The tool covers the full promised domain: linear and quadratic equations, identities, contradictions, exact fractions, and complex roots, with explicit refusal hints for unsupported input. No important operation within the stated scope is missing.

Resources