Skip to main content
Glama
laszlopere

mcp-abacus

solver

Find variable values that drive an expression to zero, minimum, or maximum. Specify bounds and objective for root finding or extremum search.

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.

  • MULTIPLE: variables — a dict mapping each unknown name to its [lower, upper] bracket, e.g. {"x": [0, 5], "y": [-4, 2]}. This needs the Nelder-Mead engine (algorithm="nelder-mead"), 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), or "nelder-mead" (multivariate, a bounds-clamped downhill simplex). The two single-variable engines solve only the SINGLE form; the variables form requires "nelder-mead". (golden, brent, simplex and a few other spellings are accepted too.)

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) min_fixed_point_precision is REQUIRED. Without it the search would run at scale 0, flooring the variable to whole numbers and missing any non-integer solution, so the call is refused; pass it (e.g. 9), or switch to floating-point / rational, which resolve sub-unit values natively and need 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

TableJSON 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`. Give EXACTLY ONE input form: this trio, OR `variables` (never both, never neither).
algorithmNoSearch engine: 'golden-section-search' (default, single-variable), 'brent-parabolic' (single-variable), or 'nelder-mead' (required for the `variables` form).
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 algorithm='nelder-mead'. 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). REQUIRED in fixed-point mode (else the search floors to integers); null/omit in the other modes.
Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: 2-second time limit, convergence behavior, error handling, fixed-point precision requirement, and input constraints. No contradictions.

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 well-structured with clear sections and bullet points, and is front-loaded with the main purpose. However, it is quite long; some details could be condensed without losing clarity.

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 no output schema, the description explains the return format in full detail including all fields, edge cases, and error states. Covers input, behavior, and output comprehensively.

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 coverage is 100%, but the description adds substantial meaning beyond parameter names: explains expression language, single vs multiple forms, algorithm details, mode interplay, and precision requirements. Every parameter is contextualized.

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 finds variable values to drive an expression to a root or extremum, distinguishing from sibling tools like calculate (evaluate) and analyze (debug parse tree). The verb 'find' plus resource 'solver' is specific.

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?

Extensive guidance on when to use single vs multiple variables, which algorithm to choose, and modes. Explicitly references calculate, analyze, and help for alternative contexts. Provides explicit 'when-not' and alternatives.

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/laszlopere/mcp-abacus'

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