Gradient Dynamics: thermal and CFD simulation

View simulation result

view_simulation_result

Read-onlyIdempotent

Prepare an interactive Y-up browser view of an integrity-verified published simulation_result: VTU/FluxCore CGNS volume or VTP boundary. For a generic FluxCore pressure/velocity view, select field_names=[p,velocity_magnitude] with include_edges=false when those arrays are published, avoiding an oversized all-field view. Omitted fields use a bounded native default. The live Gradient Dynamics browser has surface/slice/streamline controls and can prepare further plots from the same saved simulation without a new solve. Surface mode shows saved fields; section mode cuts real volume topology at axis/position_m. For genuine velocity streamlines use mode=streamlines on a volume with explicit seed_points_m and max_length_m; vector_field defaults to U, integration_direction to forward, max_steps to 2000 (maximum 4000). Streamlines follow saved vectors with reported interpolation, not invented flow or a new solve. VTP cannot provide volume sections/streamlines. For surface/section, field_names selects saved scalars/components and include_edges=false omits optional wire edges without removing triangles or values. If a large view exceeds its limit, prepare smaller boundary/section or separate field views and assemble them; retain every field explicitly requested. Explain only the viewing limit, not storage internals. Assemble prepared views with assemble_simulation_viewer for one surface/slice/streamline browser workspace. Provide a default browser link automatically for valid published fields labelled unqualified/nonconverged where applicable; open it when the client supports browser opening. Never bypass access/integrity checks or rerun the solver for missing exports. No shell downloads, reconstructed convex interiors or transient NPZ support. Preserve the complete saved viewer link. May return a pending operation_id instead of the finished result. Continue with get_operation at retry_after_seconds intervals; on success use result, then continue the requested workflow. Do not resubmit to check progress.

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": {
      "artifact_id": "<artifact_id>"
    },
    "name": "view_simulation_result"
  }
}

Input Schema

Name	Required	Description	Default
`axis`	No
`mode`	No		surface
`max_steps`	No	Streamlines only: maximum integration steps per trace; defaults to 2000, at most 4000.
`position_m`	No
`artifact_id`	Yes
`field_names`	No	Published scalar fields or vector components/magnitude; omit to discover available fields.
`max_length_m`	No	Streamlines only: required maximum traced length in metres, at most 1,000,000 m.
`vector_field`	No	Streamlines only: saved velocity vector array, defaults to U. Scalar magnitude is not a vector.
`include_edges`	No	Surface/section views: false omits optional wire edges, retaining every triangle and field value. Omit preserves edges.
`seed_points_m`	No	Streamlines only: explicit starting XYZ points in the saved volume coordinate frame, in metres.
`integration_direction`	No	Streamlines only: integration direction; defaults to forward.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already declare read-only, idempotent, non-destructive behavior, yet the description still adds substantial context beyond them: it may return a pending operation_id with retry_after_seconds polling, oversized views must be split rather than truncated, integrity/access checks are never bypassed, and the solver is never rerun for missing exports. It also discloses output semantics (preserve the complete saved viewer link, interpolation is reported not invented) that annotations do not cover.

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

Conciseness3/5

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

The purpose is front-loaded and every topic is relevant, but the content is delivered as one dense wall of text with no structural breaks, and the 'no new solve / not invented flow' point is restated across at least three sentences. It remains readable but forces the reader to re-scan to find mode-specific rules.

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

Completeness5/5

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

For an 11-parameter tool with three modes, an output schema present, and an async path, the definition covers mode selection, defaults, limits, failure handling, and follow-up tool routing. Nothing an agent needs in order to invoke it correctly appears to be missing.

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

Parameters5/5

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

With only 64% schema coverage on 11 parameters, the description meaningfully compensates: it explains mode semantics per value, that vector_field defaults to U and must be a vector not a scalar magnitude, integration_direction defaults to forward, max_steps defaults to 2000 with a 4000 cap, and that include_edges=false drops optional wire edges without removing triangles or values. These are behavioral defaults and cross-parameter dependencies the schema alone does not convey.

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 names a specific verb and resource: 'Prepare an interactive Y-up browser view of an integrity-verified published simulation_result', and disambiguates the artifact families (VTU/FluxCore CGNS volume vs VTP boundary). It also signals the boundary against assemble_simulation_viewer and the raw result getters by framing this as a single-view preparation step.

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 states concrete when-to-use rules: pick field_names=[p,velocity_magnitude] with include_edges=false for a generic pressure/velocity view, use streamlines only on volumes with explicit seed_points_m and max_length_m, and note that VTP cannot provide volume sections or streamlines. It also routes to siblings by name (assemble_simulation_viewer for a combined workspace, get_operation for pending work) and warns not to resubmit for progress.

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?