Gradient Dynamics: thermal and CFD simulation

Import attached CAD or STL

import_surface_attachment

Import an already attached STL/STEP/STP/3MF using the actual file reference supplied by the chat host. Prefer this over asking the user to select that file again. The API fetches and verifies its bytes and returns a ready artifact; continue view_geometry for STL, inspect_mesh_geometry and requested meshing/sections. Reuse known ready artifacts first. Never invent a download URL/file ID, use a client path or expose the temporary URL. If the host cannot hand off the attachment, use create_upload when you can run commands where the file is, otherwise open_surface_upload once. Normally omit coordinate_units (auto). Supply engineering_context from the request and expected_length_mm only if known. Inspect measured STL bounds to infer units; ask only when scale remains ambiguous. STEP/3MF use embedded units normalized to mm. Use reconstruct_cad for 3MF before downstream geometry or meshing. Does not start engineering compute. 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": {
      "filename": "<filename>",
      "file": "<file>"
    },
    "name": "import_surface_attachment"
  }
}

Input Schema

Name	Required	Description	Default
`file`	Yes
`sha256`	No
`filename`	Yes
`project_id`	No
`request_id`	No
`size_bytes`	No
`coordinate_units`	No	Normally auto. STEP/STP/3MF use embedded units normalized to mm. STL units are resolved from measured bounds and supplied engineering context; ambiguous scale requires one clarification.	auto
`expected_length_mm`	No	Optional known approximate longest overall dimension in millimetres. Supply only when known from the user or source evidence, not an invented guess.
`engineering_context`	No	Brief supplied engineering context, e.g. a full-size passenger car or a GPU cold plate. Do not infer context from a filename alone.

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?

Goes well beyond the annotations: the API fetches and verifies bytes and returns a ready artifact, it does not start engineering compute, and it may return a pending operation_id with retry_after_seconds rather than a result. The warning never to invent URLs/file IDs or expose the temporary URL adds safety context the annotations don't carry.

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 purpose and the preferred-over alternative, then fallbacks, then async handling. It is long and some unit guidance repeats the schema's coordinate_units description, but nearly every sentence carries actionable constraint.

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 9-parameter import tool with an output schema, it covers the full lifecycle: host handoff, verification, artifact reuse, downstream continuation via view_geometry/inspect_mesh_geometry, and pending-operation polling via get_operation with the explicit no-resubmit rule.

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

Parameters4/5

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

Schema coverage is only 33%, and the description compensates by explaining coordinate_units (normally auto; STEP/3MF use embedded units, STL resolved from measured bounds), expected_length_mm (only when known, not invented), and engineering_context (not inferred from filename). It says nothing about sha256, size_bytes, request_id, or project_id, leaving a 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?

Names a specific verb and resource: import an already attached STL/STEP/STP/3MF via the host-supplied file reference. It immediately distinguishes itself from the ask-the-user-again path and from create_upload/open_surface_upload, so an agent can pick it 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 Guidelines5/5

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

Explicit routing: prefer this over re-asking the user; fall back to create_upload when commands can run where the file is, otherwise open_surface_upload once; use reconstruct_cad for 3MF before downstream geometry. It also says when to omit coordinate_units and when to ask about scale.

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?