Gradient Dynamics: thermal and CFD simulation

Plan mesh (dry run)

plan_mesh

Read-onlyIdempotent

Dry run of an external octree mesh: send the create_mesh request (octree_prism.controls, no idempotency_key) and see the domain, sizes, boundary layer, refinement regions, predicted cells and the cores and memory it would get, without meshing. The mesher refuses what it cannot mesh, with numbers: a target too small for the sizes or first layer, a first layer thinner than the curved wall sags, or a target too large for meshing memory. Read feasible, then refusal or predicted_cells and notes, and tell the user before create_mesh when the prediction is far from target_cells. Internal fluid and CHT meshes, and requests with explicit domain and spacings, are not planned. Starts no compute and is not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "surface_artifact_id": "<surface_artifact_id>",
      "engine": "<engine>"
    },
    "name": "plan_mesh"
  }
}

Input Schema

Name	Required	Description
`engine`	Yes	structured = Cartesian; octree_prism = native octree/polyhedral with prism layers; openfoam = legacy engine identifier. Prefer configured octree_prism for generic unstructured requests; preserve explicit methods. Choose delivered file formats separately with export_formats.
`openfoam`	No
`project_id`	No
`structured`	No
`octree_prism`	No
`target_cells`	No
`export_formats`	No	Delivered mesh formats, in preference order. Default cgns is Standard CGNS (NGON/NFACE) for ParaView. gd_cgns is GD CGNS for Fluxcore/Studio; fluent is a Fluent-format polyhedral .msh; openfoam is a polyMesh archive. Select formats independently of the meshing engine. The first format is the primary download. GD CGNS is also retained internally for simulation and viewing. Preserve an explicit user choice; do not ask for a format when none was specified.
`reviewed_job_id`	No	Explicitly requested new attempt after reviewing this completed mesh job, including quality or resource failures. Use a fresh idempotency key; this records lineage and never restarts the prior execution.
`decision_context`	No
`surface_artifact_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations declare readOnly, idempotent and non-destructive; the description corroborates and extends them with cost and side-effect facts ('Starts no compute and is not charged'). It also discloses a behavioral trait no annotation could carry: the mesher refuses infeasible requests with numeric reasons (target too small for sizes or first layer, first layer thinner than curved-wall sag, target too large for memory) and the response leads with 'feasible'.

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 action and the request shape, then refusal behavior, then the read/decide rule, then exclusions and cost. Every sentence carries information, though the middle refusal sentence is long and stacks three clauses that could be separated for scanning.

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 a dry-run over a 10-parameter schema with an output schema present, the description covers the important unknowns: what it does not plan, how refusals surface, and that nothing is charged. The remaining gap is that it never hints which inputs materially change the prediction (e.g. target_cells), leaving the agent to mine the schema.

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 low (30%) across 10 parameters, and the description only pins two things: use octree_prism.controls and omit idempotency_key. That is genuinely useful framing for why this call differs from create_mesh, but it says nothing about target_cells, engine, export_formats or named_surfaces semantics, so it does not compensate for the documentation gap.

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 ('Dry run of an external octree mesh') and immediately grounds it in the concrete request shape ('send the create_mesh request (octree_prism.controls, no idempotency_key)'). It goes further than naming the action by enumerating what the caller sees: domain, sizes, boundary layer, refinement regions, predicted cells, cores and memory — an agent can distinguish this from create_mesh and from plan_geometry_study on the text alone.

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

Usage Guidelines5/5

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

Gives explicit when-not conditions: 'Internal fluid and CHT meshes, and requests with explicit domain and spacings, are not planned.' It also states the downstream action rule — 'tell the user before create_mesh when the prediction is far from target_cells' — which is a decision rule, not just a description of the tool.

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

All Gradient Dynamics: thermal and CFD simulation tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?