Gradient Dynamics: thermal and CFD simulation

Run simulation

run_simulation

Idempotent

Run a CFD, heat-transfer or conjugate thermal (CHT) simulation to predict temperatures, pressure drop, flow and forces on a meshed design. Uses GPU compute: usually 1–15 credits and 5–60 minutes for up to 20M cells; call estimate_cost first and check the budget. Not for quick what-ifs (use predict_physics or a design preview) or for checking inputs (use validate_simulation). Submit a new durable RANS/URANS/CHT simulation for an owned validated mesh. Use a fresh key for a newly requested run, even with identical inputs; keep the original key only for retries/resuming that run. Reuse completed results only when requested or accepted. Read get_request_schema(simulation), inspect actual mesh patches/zones, clarify the objective, flow/thermal conditions and consequential controls. Honor explicit choices; use disclosed best judgment for delegated choices and record assumptions in decision_context. Returns immediately with a job ID. Numerical acceptance is distinct from completion and publication. After any terminal outcome inspect get_job, get_job_events and owned summaries; report available residuals/forces/y+ with qualification. Provide the default browser viewer link automatically for valid published fields, with unqualified/nonconverged labels where applicable; do not auto-rerun. May incur GPU charges.

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": {
      "mesh_artifact_id": "<mesh_artifact_id>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "run_simulation"
  }
}

Input Schema

Name	Required	Description
`gpu`	No	GPU type: B200 (default) or H100.
`config`	No
`gpu_count`	No	GPUs for the solve (default 1). CHT and Krylov runs use one.
`notify_url`	No	Optional public HTTPS URL that receives a signed notification when the job finishes, so you need not poll.
`project_id`	No
`idempotency_key`	Yes	Use a fresh unique key for each newly requested job, even with identical inputs or a matching completed job. Reuse unchanged only for retries/resuming that same intended job. Never replace it to retry an uncertain submission.
`decision_context`	No
`mesh_artifact_id`	Yes
`restart_artifact_id`	No
`convergence_criteria`	No	How to judge this run converged when it finishes; omit for the standard test (every residual at or below 1e-3, none rising).
`mesh_unit_conversion`	No

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), the description discloses concrete behavior: GPU compute at 1–15 credits and 5–60 minutes for up to 20M cells, immediate return with a job ID, and that numerical acceptance is distinct from completion and publication. It also explains the browser viewer-link behavior and the requirement to qualify nonconverged results, which the annotations cannot convey.

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?

The purpose and the cost/time envelope are front-loaded, which is the right priority for an expensive job, and nearly every sentence carries operational meaning. It is nonetheless dense and sprawling at roughly a dozen sentences, with minor redundancy such as 'May incur GPU charges' restating the credits/minutes sentence.

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 high-complexity, asynchronous, cost-bearing tool it covers the critical ring: cost estimation, submission semantics, idempotency, post-terminal inspection workflow, and a handoff to get_request_schema for the full request shape. Gaps remain around GPU/model selection and restart/mesh-unit-conversion parameters, though an output schema exists so return-value detail is not required.

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 description coverage is only 45% across 11 parameters, and the description elaborates meaningfully only on idempotency_key (fresh key for new runs, reuse only for retries) and decision_context/assumptions. It largely delegates the rest to get_request_schema(simulation) rather than explaining config, gpu/gpu_count, restart_artifact_id, mesh_unit_conversion or convergence_criteria, and much of the idempotency wording duplicates the schema's own description.

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?

The opening sentence gives a specific verb (run) plus the resource and physics covered (CFD, heat-transfer, CHT) and the outputs predicted (temperatures, pressure drop, flow, forces). A later sentence explicitly states what this is not ('Not for quick what-ifs... use predict_physics... or for checking inputs... use validate_simulation'), which clearly separates it from sibling tools such as validate_simulation, predict_physics and get_request_schema.

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?

It names concrete preconditions and alternatives: call estimate_cost first and check budget, use predict_physics or a design preview for quick what-ifs, validate_simulation for input checking, get_request_schema(simulation) before submitting. It also gives when-to-reuse rules ('Reuse completed results only when requested or accepted') and post-run steps (inspect get_job, get_job_events, do not auto-rerun).

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?