Skip to main content
Glama
Sign In
mathmethods-mcp

mathmethods-mcp

by agmonetti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ode_heun

Solves first-order ODE initial value problems with Heun's predictor-corrector method, returning numerical and exact solutions, error estimates, and an optional plot.

Instructions

Solve y'(x) = f(x, y), y(x0) = y0 with Heun's predictor-corrector method (2nd 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.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It does disclose the return contract usefully: a dict with numerical solution, exact solution when available, and errors, or a [dict, Image] list when plot=True. It does not mention cost, failure behavior for a diverging/degenerate step, or whether the exact solution is always computed, so it stops short of full disclosure.

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 statement of the mathematical problem, followed by clean Args/Returns blocks. Efficient and scannable, with only minor redundancy between the Args list and the schema titles.

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?

With no annotations and no output schema, the description must cover parameter meanings and return values, and it does both, including the plot-conditional return shape. Missing only edge-case behavior (e.g., what happens when h is too large or tol is unused), which is a modest gap for a self-contained numeric routine.

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 description must compensate, and it documents all 8 parameters including the two optional ones (tol, precision, plot). It adds real constraints (xf > x0, h positive) beyond the bare schema titles, though tol is described only as an 'optional tolerance flag', which is vague against its numeric type.

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 and resource: solves the IVP y'(x)=f(x,y), y(x0)=y0 using Heun's predictor-corrector method (2nd order). The named method cleanly separates it from sibling solvers ode_rk4 and ode_euler without needing to open any schema.

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 indication of when to prefer Heun over the sibling ode_euler (1st order) or ode_rk4 (4th order), nor of accuracy/cost tradeoffs. The only guidance given (xf > x0, h positive) is a parameter constraint, not usage routing.

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