Skip to main content
Glama
Sign In
mathmethods-mcp

mathmethods-mcp

by agmonetti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

dynamic_2d_lanchester_solve

Simulate 2D Lanchester combat model to predict winner, survivors, and time to annihilation, with numerical trajectories and optional phase portrait.

Instructions

Simulate a Lanchester combat model x' = f(x,y), y' = g(x,y) with analytic time-to-annihilation.

Args: eq_x, eq_y: Math expressions (classic default is x'=-αy, y'=-βx). alpha, beta, gamma, epsilon, mu, delta: Greek parameter values. x0, y0: initial force sizes. t0, t_fin, h: simulation grid. plot: When True, also return a PNG phase portrait of the battle.

Returns: Dict with the analytic winner/survivors, state equation and the numerical trajectories. With plot=True a list [dict, Image] is returned instead.

Input Schema

NameRequiredDescriptionDefault
hNo
muNo
t0No
x0No
y0No
betaNo
eq_xNo-α * y
eq_yNo-β * x
plotNo
alphaNo
deltaNo
gammaNo
t_finNo
epsilonNo

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

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose a key behavioral trait: the return type switches to [dict, Image] when plot=True, and results include analytic winner/survivors plus trajectories. It does not state the integration scheme, accuracy/step-size behavior, or failure modes (e.g. non-terminating battles), so the disclosure is partial.

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?

Purpose is front-loaded in one sentence, then Args and Returns are cleanly sectioned with no padding. The restatement of the schema defaults ('classic default is x'=-αy, y'=-βx') is mildly redundant but harmless.

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

Completeness3/5

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

For a 14-parameter tool with no annotations and no output schema, the description does cover the return structure and most parameter groupings. It falls short on the six free coefficients whose role in the equations is undefined and on how this model class relates to its 2D solver siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it names all 14 arguments and gives semantics for x0/y0 (initial force sizes), t0/t_fin/h (simulation grid) and plot. The six Greek parameters are lumped as 'Greek parameter values' without saying which term each multiplies (gamma, epsilon, mu, delta roles are never defined), leaving a real gap.

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?

The first sentence gives a specific verb (simulate) plus the exact model class and ODE form, and 'Lanchester' plus 'analytic time-to-annihilation' distinguishes it from generic siblings like dynamic_2d_linear_solve. However, it never explicitly contrasts itself with the other four 2D solvers, so an agent must infer the boundary.

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?

There is no statement of when to choose this tool over dynamic_2d_nonlinear_solve, dynamic_2d_conservative_solve or dynamic_2d_linear_solve, and no preconditions or exclusions. The 'classic default' note is a parameter hint, not usage guidance, so the agent gets no routing help.

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