Skip to main content
Glama
mathmethods-mcp

mathmethods-mcp

ode_euler

Solves the initial value problem y'(x)=f(x,y), y(x0)=y0 using the explicit Euler method and returns the numerical solution, exact solution when available, and errors.

Instructions

Solve y'(x) = f(x, y), y(x0) = y0 with the explicit Euler method (1st order).

Args: ecuacion_str: Right-hand side f(x, y). x0, y0: Initial condition. xf: Final x (must be > x0). h: Step size (must be positive). tol: Optional tolerance flag for the final error. precision: Rounding digits. plot: When True, also return a PNG plot of the solution.

Returns: Dict with the numerical solution, exact solution (when available) and errors. With plot=True a list [dict, Image] is returned instead.

Input Schema

NameRequiredDescriptionDefault
hYes
x0Yes
xfYes
y0Yes
tolNo
plotNo
precisionNo
ecuacion_strYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.1
    • addedInput schema / properties / plot
      Added value: +{
      +  "default": false,
      +  "title": "Plot",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does disclose the return shape and the plot=True branching behavior ([dict, Image]). It also states input constraints. However it omits behavioral caveats such as the method's low accuracy relative to RK4 and any performance/step-count considerations.

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?

Front-loaded with the equation and method, then cleanly partitioned into Args and Returns sections; each line maps to a real need. Slightly verbose in restating all params but no wasted marketing prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter solver with no output schema and no annotations, the description supplies the required params, their constraints, and the return structure. Missing only sibling-routing and accuracy caveats, so it is nearly complete 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 description coverage is 0%, so the schema only supplies bare titles ('Tol', 'H', 'Ecuacion Str'). The description compensates by explaining every parameter's meaning and adding constraints (xf must be > x0, h must be positive, precision is rounding digits, plot adds a PNG). Strong compensation for a documentation-poor 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?

States a specific verb (Solve) and resource (the ODE y'(x)=f(x,y)) plus the exact method and order (explicit Euler, 1st order). This clearly distinguishes it from siblings like ode_rk4 and ode_heun, which are different-order ODE solvers.

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

Usage Guidelines2/5

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

No guidance on when to choose Euler over the sibling ode_rk4 or ode_heun, nor any note about its low-accuracy/educational nature. Only the parameter constraints (xf > x0, h positive) are given; the selection context is left entirely to inference.

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