Skip to main content
Glama
mcp-abacus

mcp-abacus

solver

Find the value(s) of one or more variables that drive an expression to a root or extremum.

Instructions

Find the value(s) of one or more variables that drive an expression to a root or extremum.

solver takes the SAME expression language as calculate — every operator, function, literal form, and (crucially) multi-line programs with name = expr assignments — but instead of evaluating the expression it SEARCHES for the value of the unknown(s) that drive the expression to the chosen objective:

  • "find-root" (default): find where the expression equals zero. Write an equation f = g as the expression f - g and find its root.

  • "find-minimum" / "find-maximum": find where the expression reaches its smallest / largest value within the bracket(s).

There are two input forms for the unknowns:

  • SINGLE: variable + lower + upper — one unknown searched over the bracket [lower, upper] (lower must be below upper). This is the default golden-section engine. variable may be OMITTED when the expression has exactly one free name; the solver then auto-detects it (e.g. n in 12*n - (450 + 3*n)), needing only lower + upper.

  • MULTIPLE: variables — a dict mapping each unknown name to its [lower, upper] bracket, e.g. {"x": [0, 5], "y": [-4, 2]}. This needs a multivariate engine (algorithm="nelder-mead", "powell" or "bfgs"), which searches all the unknowns jointly. Give exactly one of the two forms. Each unknown must OCCUR in the expression and must NOT be assigned by it; every OTHER name is a constant the program sets via an assignment line (e.g. "r = 0.05\np = 1000\np * (1 + r)**n - 2000" solving for n with r, p fixed). A name that is neither an unknown nor assigned is an error.

objective (optional) names what to search for — "find-root", "find-minimum", or "find-maximum"; omitted, it defaults to "find-root". (The older spellings solve, minimise/maximise and their min/max and American forms are accepted too.)

algorithm (optional) names the search engine — "golden-section-search" (the default, single-variable), "brent-parabolic" (single-variable too, parabolic interpolation with a golden-section fallback — usually faster on smooth extrema), "bisection", "ridders", "brent-dekker", "chandrupatla" or "secant" (single-variable, find-root ONLY — all five bracket a sign change and need not have straddling endpoints, since they scan the bracket for one; bisection halves the bracket, ridders takes a faster exponential-fit step, brent-dekker interpolates inverse-quadratically with a bisection fallback — the usual library default for a bracketed root — chandrupatla admits that same interpolation under a sharper test, which keeps it at bisection's speed on a repeated root where brent-dekker slows to about a third of it, and secant simply chases the chord through the last two points: the leanest of the five on a simple root, but the slowest on a repeated one), "newton-raphson" or "halley" (single-variable, find-root ONLY as well, but the root engines that bracket NOTHING: they step along the expression's own derivatives — newton along the tangent, x - f(x)/f'(x), halley along a tangent hyperbola that carries the curvature too and so converges cubically for the same work — starting from the best point of a coarse scan of the bracket, with the derivatives taken numerically and every step fenced back into [lower, upper]. Fastest of all on a smooth root, and the only engines that reach a root which merely TOUCHES zero without crossing, where the sign-change engines report "no sign change"), or one of the three MULTIVARIATE engines — "nelder-mead" (a bounds-clamped downhill simplex), "powell" (derivative-free too: each iteration sweeps a full bounded line minimisation along every one of n directions, and re-aims that direction set at the sweep's own net displacement, so it follows a diagonal valley the simplex can only feel out — usually the fewest evaluations of the three on a smooth objective) or "bfgs" (quasi-Newton gradient descent, find-minimum / find-maximum only). The single-variable engines solve only the SINGLE form; the variables form requires a multivariate one. (golden, brent, bisect, ridder, brent-root, newton, simplex, powells and a few other spellings are accepted too — note bare brent names the PARABOLIC MINIMISER, while Brent's root method is brent-dekker.)

mode and min_fixed_point_precision behave as in calculate — the search runs in that numeric type and the found value is reported in it — with ONE solver-only rule: in fixed-point mode (the default) a search at scale 0 would floor the variable to whole numbers and miss any non-integer solution, so when min_fixed_point_precision is omitted it DEFAULTS to 9 (sub-unit resolution) rather than 0. Pass an explicit value for more/fewer decimals, or 0 to search integers only; the other modes (floating-point / rational) resolve sub-unit values natively and take no floor. See calculate and help for the shared grammar and modes; if a found value or objective looks off, analyze shows the per-node parse tree of the expression (with the unknowns substituted) to reveal where it rounded or overflowed.

The search is bounded by a hard 2-second time limit. If it has not converged by then it stops and reports the best value reached so far (a find-root that has not got close enough to zero in that time is reported as no-solution, naming the limit).

Returns a dict: solutions is a list of {variable, solution, solution_hex_dump}, one per unknown in input order — each solution rendered and marked "(approximate)" (the search locates it to a tolerance, never exactly), with its bit-backed hex. For the SINGLE form the scalar variable / solution / solution_hex_dump are also set (the one unknown); for the MULTIPLE form those scalars are null and solutions carries every value. value is the EXPRESSION evaluated at that solution, annotated with its own precision verdict (near zero for find-root, the extremum otherwise), and value_hex_dump its hex. mode is the resolved numeric type; exact and precision describe value exactly as in calculate. objective echoes the resolved objective, algorithm names the engine used, and iterations is how many search steps it took. On any failure — a bad mode/precision, a malformed expression, an invalid request (no/both input forms, empty bracket, unknown not in the expression, golden-section asked for multiple unknowns, unknown objective or algorithm), or no solution in the bracket — every data field is null and error carries the message (a no-solution error reports the closest |expr| it reached); on success error is null.

Input Schema

NameRequiredDescriptionDefault
modeNoNumeric type the search runs in: 'fixed-point' (default), 'floating-point', or 'rational' — as in `calculate`.fixed-point
lowerNoSINGLE form: lower bound of the search bracket for `variable` (must be below `upper`). Part of the variable+lower+upper trio; leave unset when using the `variables` form.
upperNoSINGLE form: upper bound of the search bracket for `variable` (must be above `lower`). Part of the variable+lower+upper trio; leave unset when using the `variables` form.
variableNoSINGLE-unknown form: name of the one variable to search for, used together with `lower`+`upper`. OPTIONAL: omit it and the solver auto-detects the sole free name in the expression (it errors only if there is zero or more than one). Give EXACTLY ONE input form: this trio, OR `variables` (never both, never neither).
algorithmNoSearch engine: 'golden-section-search' (default, single-variable), 'brent-parabolic' or 'ternary-search' (single-variable — brent-parabolic is usually the fastest on a smooth extremum, ternary-search the plainest and slowest), 'newton-optimise' (single-variable, find-minimum / find-maximum ONLY — steps to the zero of the objective's own slope, so it lands a smooth extremum in very few steps), 'bisection', 'ridders', 'brent-dekker', 'chandrupatla' or 'secant' (single-variable, find-root only — bracket a sign change; the last four converge faster than bisection, secant being the leanest on a simple root and chandrupatla the fastest on a repeated one), 'newton-raphson' or 'halley' (single-variable, find-root only — follow the expression's own derivatives instead of bracketing, so they also reach a root that only TOUCHES zero; halley adds the curvature to newton's slope and converges cubically for the same cost), or — for the `variables` form — 'nelder-mead' (derivative-free simplex, any objective), 'powell' (derivative-free too, any objective: a sweep of line minimisations along directions it re-aims each pass, usually reaching a smooth minimum in far fewer evaluations than the simplex) or 'bfgs' (quasi-Newton gradient descent, find-minimum / find-maximum only; far fewer iterations than nelder-mead on a smooth bowl).
objectiveNoWhat to search for: 'find-root' (default), 'find-minimum', or 'find-maximum'.
variablesNoMULTIPLE-unknown form: dict mapping each unknown name to its [lower, upper] bracket, e.g. {"x": [0, 5], "y": [-4, 2]}; requires a multivariate algorithm ('nelder-mead', 'powell' or 'bfgs'). Give EXACTLY ONE input form: this, OR `variable`+`lower`+`upper` (never both, never neither).
expressionYesThe expression (or newline-separated program whose `name = expr` lines set constants) to drive to a root or extremum; same grammar as `calculate`.
min_fixed_point_precisionNoFloor on fixed-point fractional digits (non-negative integer). In fixed-point mode, omit it for a default floor of 9 so the search resolves non-integer solutions instead of flooring the variable to whole numbers; pass an explicit value for more/fewer decimals, or 0 to search integers only. Leave null/omit in the other modes, which resolve sub-unit values natively.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / algorithm / description
      Previous value: -"Search engine: 'golden-section-search' (default, single-variable), 'brent-parabolic' (single-variable), or 'nelder-mead' (required for the `variables` form)."New value: +"Search engine: 'golden-section-search' (default, single-variable), 'brent-parabolic' or 'ternary-search' (single-variable — brent-parabolic is usually the fastest on a smooth extremum, ternary-search the plainest and slowest), 'newton-optimise' (single-variable, find-minimum / find-maximum ONLY — steps to the zero of the objective's own slope, so it lands a smooth extremum in very few steps), 'bisection', 'ridders', 'brent-dekker', 'chandrupatla' or 'secant' (single-variable, find-root only — bracket a sign change; the last four converge faster than bisection, secant being the leanest on a simple root and chandrupatla the fastest on a repeated one), 'newton-raphson' or 'halley' (single-variable, find-root only — follow the expression's own derivatives instead of bracketing, so they also reach a root that only TOUCHES zero; halley adds the curvature to newton's slope and converges cubically for the same cost), or — for the `variables` form — 'nelder-mead' (derivative-free simplex, any objective), 'powell' (derivative-free too, any objective: a sweep of line minimisations along directions it re-aims each pass, usually reaching a smooth minimum in far fewer evaluations than the simplex) or 'bfgs' (quasi-Newton gradient descent, find-minimum / find-maximum only; far fewer iterations than nelder-mead on a smooth bowl)."
    • changedInput schema / properties / min_fixed_point_precision / description
      Previous value: -"Floor on fixed-point fractional digits (non-negative integer). REQUIRED in fixed-point mode (else the search floors to integers); null/omit in the other modes."New value: +"Floor on fixed-point fractional digits (non-negative integer). In fixed-point mode, omit it for a default floor of 9 so the search resolves non-integer solutions instead of flooring the variable to whole numbers; pass an explicit value for more/fewer decimals, or 0 to search integers only. Leave null/omit in the other modes, which resolve sub-unit values natively."
    • changedInput schema / properties / variable / description
      Previous value: -"SINGLE-unknown form: name of the one variable to search for, used together with `lower`+`upper`. Give EXACTLY ONE input form: this trio, OR `variables` (never both, never neither)."New value: +"SINGLE-unknown form: name of the one variable to search for, used together with `lower`+`upper`. OPTIONAL: omit it and the solver auto-detects the sole free name in the expression (it errors only if there is zero or more than one). Give EXACTLY ONE input form: this trio, OR `variables` (never both, never neither)."
    • changedInput schema / properties / variables / description
      Previous value: -"MULTIPLE-unknown form: dict mapping each unknown name to its [lower, upper] bracket, e.g. {\"x\": [0, 5], \"y\": [-4, 2]}; requires algorithm='nelder-mead'. Give EXACTLY ONE input form: this, OR `variable`+`lower`+`upper` (never both, never neither)."New value: +"MULTIPLE-unknown form: dict mapping each unknown name to its [lower, upper] bracket, e.g. {\"x\": [0, 5], \"y\": [-4, 2]}; requires a multivariate algorithm ('nelder-mead', 'powell' or 'bfgs'). Give EXACTLY ONE input form: this, OR `variable`+`lower`+`upper` (never both, never neither)."
  2. Changed9 schema fields changedv0.2.0
    • addedInput schema / properties / algorithm / description
      Added value: +"Search engine: 'golden-section-search' (default, single-variable), 'brent-parabolic' (single-variable), or 'nelder-mead' (required for the `variables` form)."
    • addedInput schema / properties / expression / description
      Added value: +"The expression (or newline-separated program whose `name = expr` lines set constants) to drive to a root or extremum; same grammar as `calculate`."
    • addedInput schema / properties / lower / description
      Added value: +"SINGLE form: lower bound of the search bracket for `variable` (must be below `upper`). Part of the variable+lower+upper trio; leave unset when using the `variables` form."
    • addedInput schema / properties / min_fixed_point_precision / description
      Added value: +"Floor on fixed-point fractional digits (non-negative integer). REQUIRED in fixed-point mode (else the search floors to integers); null/omit in the other modes."
    • addedInput schema / properties / mode / description
      Added value: +"Numeric type the search runs in: 'fixed-point' (default), 'floating-point', or 'rational' — as in `calculate`."
    • addedInput schema / properties / objective / description
      Added value: +"What to search for: 'find-root' (default), 'find-minimum', or 'find-maximum'."
    • addedInput schema / properties / upper / description
      Added value: +"SINGLE form: upper bound of the search bracket for `variable` (must be above `lower`). Part of the variable+lower+upper trio; leave unset when using the `variables` form."
    • addedInput schema / properties / variable / description
      Added value: +"SINGLE-unknown form: name of the one variable to search for, used together with `lower`+`upper`. Give EXACTLY ONE input form: this trio, OR `variables` (never both, never neither)."
    • addedInput schema / properties / variables / description
      Added value: +"MULTIPLE-unknown form: dict mapping each unknown name to its [lower, upper] bracket, e.g. {\"x\": [0, 5], \"y\": [-4, 2]}; requires algorithm='nelder-mead'. Give EXACTLY ONE input form: this, OR `variable`+`lower`+`upper` (never both, never neither)."
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: a hard 2-second time limit that returns the best-so-far value, no-solution reporting, the solver-only default precision floor of 9 in fixed-point mode, bracket/sign-change requirements per engine, derivative-based vs bracketing engines, and full failure-mode enumeration with null fields and an `error` message.

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

Conciseness3/5

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

Purpose, objectives, and input forms are front-loaded, but the algorithm paragraph is a dense wall of nested parentheticals (e.g. the extended chandrupatla-vs-brent-dekker speed comparison) whose detail far exceeds what an agent needs to pick an engine. Several sentences do not earn their place.

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?

No output schema exists, so the description carries the return contract itself: the `solutions` list shape, scalar fields for the SINGLE form, `value`/`value_hex_dump`, `mode`, `exact`, `precision`, `iterations`, and the all-null-fields-plus-`error` failure shape. Nothing material is missing for correct invocation.

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%, so the baseline is 3; the description goes beyond it by explaining parameter interplay the schema only hints at — auto-detection of `variable` when omitted, the requirement that each unknown occur in the expression but not be assigned, the coupling of `variables` to multivariate engines, and engine selection semantics.

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?

Opens with a specific verb+resource+outcome: 'Find the value(s) of one or more variables that drive an expression to a root or extremum.' It immediately distinguishes itself from `calculate` ('takes the SAME expression language as calculate — but instead of evaluating the expression it SEARCHES'), so an agent can route between the two without opening a schema.

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?

Gives clear context and alternatives: the objective choices with their meanings, which algorithm suits which case (single-variable vs multivariate, root vs extremum), the exactly-one-input-form rule, and pointers to `calculate` for grammar and `analyze` when a result looks wrong. It does not explicitly state when *not* to reach for this tool versus other siblings like `curve_fit`, so it stops short of full when/when-not coverage.

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