Skip to main content
Glama
qxkt222

sci-mcp

by qxkt222
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

solve_wave_3d

Solve the 3D wave equation on a unit cube with Dirichlet boundaries using an explicit finite-difference scheme, returning downsampled fields and saving full results.

Instructions

Solve u_tt = c^2 (u_xx + u_yy + u_zz) on the unit cube.

``nx``, ``ny``, ``nz`` are the number of intervals per axis and ``nt`` the
number of time steps. The interior uses the explicit second-order central
scheme; the first time level uses the Taylor expansion
``u(dt) = u0 + dt*v0 + c^2*dt^2/2 * Laplacian(u0)``. All six faces use the
constant Dirichlet value ``boundary``.

Stability requires ``c*dt*sqrt(3)/min(dx,dy,dz) <= 1``. Grids above
500,000 cells and histories above 20,000,000 stored points are rejected.
The full (t, z, y, x) grid is saved to .npz; returned arrays are
downsampled to at most 20 points per spatial axis and 20 time points.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cYes
ntYes
nxYes
nyYes
nzYes
t_endYes
boundaryNo
initial_velocityNo0
initial_displacementYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 so well: it discloses the numerical scheme, the Taylor-expansion first time level, the stability condition, hard rejection thresholds (500,000 cells / 20,000,000 points), the .npz persistence, and the downsampling of returned arrays. Minor gap: it doesn't say whether a stability violation is rejected or merely produces inaccurate results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the governing equation, then organized into scheme, boundary conditions, stability/limits, and output. Every sentence is information-dense with no filler.

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?

No output schema exists, and the description responsibly covers return behavior (npz file plus downsampled arrays) as well as limits, stability, and boundary handling. It falls just short of complete because the string-parameter input format and exact return structure remain unspecified.

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. It explains nx/ny/nz as intervals per axis, nt as time steps, and boundary as the Dirichlet value, but leaves c and t_end implicit and — critically — gives no format for the string-typed initial_displacement and initial_velocity, which are the most ambiguous inputs.

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 — solve the 3D wave equation on the unit cube — and gives the exact PDE, immediately distinguishing it from siblings like solve_wave_1d, solve_heat_3d, and solve_laplace_3d. An agent can identify the tool without opening the schema.

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?

The PDE domain and constraints (unit cube, constant Dirichlet boundary, stability requirement, size limits) imply when the tool applies, but the description never explicitly states when to prefer this over solve_wave_1d or other PDE solvers. Usage is inferred from the mathematical scope rather than stated.

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