Skip to main content
Glama
mathmethods-mcp

mathmethods-mcp

ode_rk4

Solve an initial value problem y'(x)=f(x,y) with Runge-Kutta 4; get a step-by-step table, per-step errors, exact solution when available, and an optional plot.

Instructions

Solve an initial value problem y'(x) = f(x, y) with the Runge-Kutta 4 method.

Args: ecuacion_str: Right-hand side f(x, y), e.g. "y" or "-2xy". x0: Initial x. y0: Initial y(x0). xf: Final x (must be > x0). h: Step size (must be positive). The endpoint xf is always reached. tol: Optional tolerance to flag whether the final error meets it. precision: Rounding digits. plot: When True, also return a PNG plot of the solution.

Returns: Dict with the numerical solution table, exact solution (when SymPy can solve it) and per-step 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

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the endpoint xf is always reached regardless of step size, that the exact solution is included only 'when SymPy can solve it', and that plot=True changes the return shape to [dict, Image]. It omits what happens on failure (e.g., unsolvable equation, h too large) and whether the tolerance merely flags or actually adapts the step.

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 one-line purpose followed by clearly labeled Args and Returns sections, appropriate in size for an 8-parameter tool. A few entries (x0, y0) are near-tautological restatements of the parameter names, which is the only waste.

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 computational tool with no annotations and no output schema, the description covers the math, every parameter, and the return structure including the plot variant. Missing only error/failure behavior and the precise semantics of 'precision' relative to output rounding.

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 description coverage is 0%, so the description must compensate entirely, and it does: every one of the 8 parameters is explained, including constraints ('xf must be > x0', 'h must be positive'), examples for ecuacion_str, and the meaning of tol, precision and plot. This adds substantial meaning beyond the bare titles in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Solve an initial value problem y'(x) = f(x, y)') and names the exact numerical method (Runge-Kutta 4), which implicitly separates it from ode_euler and ode_heun among the siblings. It never explicitly contrasts with those alternatives, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is only implied by the method name and the domain: an agent can infer this is for ODE IVPs with a 4th-order fixed-step method. There is no statement of when to pick RK4 over ode_euler/ode_heun, nor any guidance on accuracy tradeoffs or step-size choice.

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