Gradient Dynamics: thermal and CFD simulation

Inspect geometry for meshing

inspect_mesh_geometry

Read-onlyIdempotent

Inspect owned geometry without a mesh job or preview download; reuses saved results. Use detail=bounds for unstructured setup dimensions; a completed geometry export can provide STEP bounds without importing the assembly again. This does not assess closure or component identities. Use the default detail=components when selecting structured components. Normally omit input_unit: declared/CAD units remain authoritative; STL auto uses measured bounds with supplied engineering_context or expected_length_mm. If ambiguous, return unit candidates and ask one physical-dimension clarification; never invent a scale. Resolved bounds are in mm and an eligible STL viewer link is returned automatically. A configured CAD preparation service also assesses actual component IDs and closure. On an octree-only host STL inspection returns bounds only: closure and component IDs are unassessed, not guessed, and STEP inspection needs CAD preparation; use check_geometry there for closure, size and STEP solids. Use inspected bounds for structured or unstructured domains. meshing_ready describes assessed structured component closure only; open named patches are not an automatic unstructured rejection. Prefer configured octree_prism for generic external unstructured flow, preserving native quality gates. Structured internal-fluid/solid IDs must be assessed, never inferred from design output names. Read design.json with read_artifact_summary. If unavailable, explain the specific missing engineering evidence; do not switch flow region to bypass it. 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": "inspect_mesh_geometry"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	Use bounds for unstructured setup dimensions; verified geometry-export bounds can be reused without reimporting CAD. Components requests assessed identities for structured selection. Bounds never establish mesh readiness.	components
`input_unit`	No	Normally omitted or auto: retain declared/embedded units, otherwise infer from measured STL bounds and engineering context. Supply explicit units only when known.
`artifact_id`	Yes
`expected_length_mm`	No	Known approximate longest physical dimension in millimetres; do not invent one.
`engineering_context`	No	Supplied engineering context for automatic STL units, e.g. a full-size passenger car. Do not infer it from a filename.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses unit-resolution policy ('declared/CAD units remain authoritative', 'never invent a scale'), that resolved bounds are in mm with an STL viewer link returned automatically, host-capability-dependent degradation ('closure and component IDs are unassessed, not guessed'), and that it 'may return a pending operation_id' with a retry protocol via get_operation. That is substantial behavioral context not available in the structured fields.

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 core purpose is front-loaded, but the body is a dense run of one-sentence directives covering units, async polling, host capability, mesh-readiness interpretation, workflow escalation, and artifact reading. Several points (unit omission, bounds-vs-components) duplicate the schema, so trimming would improve scanability without losing information.

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 a read-only inspection tool with five parameters, full annotations, and an output schema, the description covers the remaining agent-facing gaps: unit ambiguity handling with a clarification policy, async operation_id behavior, host-dependent assessment limits, and how meshing_ready should be interpreted. Nothing essential to correct invocation appears missing.

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 80% and the enum parameter already documents bounds vs components, so the baseline is 3. The description reinforces the input_unit omission default and the STL auto path, but adds little meaning beyond what the schema descriptions already state, and does not clarify expected_length_mm or engineering_context interaction.

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?

Opens with a specific verb+resource and scope: 'Inspect owned geometry without a mesh job or preview download; reuses saved results,' which separates it from check_geometry and view_geometry. However, 'This does not assess closure or component identities' sits awkwardly against the later 'A configured CAD preparation service also assesses actual component IDs and closure' and the schema note that detail=components 'requests assessed identities,' leaving a small ambiguity about what the tool actually returns depending on host configuration.

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 routing: detail=bounds for unstructured setup dimensions, default detail=components for structured selection, and 'use check_geometry there for closure, size and STEP solids' on octree-only hosts. It also names read_artifact_summary for design.json and warns against switching flow region to bypass missing evidence, which is exactly the when/when-not guidance an agent needs.

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?