Gradient Dynamics: thermal and CFD simulation

Prepare CAD or STL upload

prepare_surface_upload

Reuse an already verified STL with this checksum, size, filename and units in the same project, or open its authenticated file picker. Existing clients may keep these arguments. If artifact.state is ready, continue with that artifact; no upload is needed. Otherwise show the upload panel or labelled Upload STL link and wait for get_artifact to report ready. Never perform client-side S3 uploads, retry previous transfer URLs or run shell/network commands. For a fresh interactive upload, prefer open_surface_upload without computing a hash.

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>",
      "size_bytes": "<size_bytes>",
      "sha256": "<sha256>"
    },
    "name": "prepare_surface_upload"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No		surface
`sha256`	Yes
`filename`	Yes
`media_type`	No		model/stl
`project_id`	No
`request_id`	No
`size_bytes`	Yes
`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.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses the idempotent-reuse behavior on duplicate checksums, the polling handoff to get_artifact, and hard security constraints against client-side S3 transfers and shell/network execution. This is the kind of operational context annotations cannot express.

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?

Purpose and the ready-state branch are front-loaded, and each sentence carries an instruction or a constraint. Some phrasing is awkward and internal-facing ('Existing clients may keep these arguments', 'open its authenticated file picker'), and the UI instructions sit at the same weight as the core routing logic.

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 10-parameter, multi-step workflow tool with an output schema, the description covers the decision path, the wait condition, and prohibited actions. The remaining gap is parameter-level: an agent still cannot tell what request_id is for or when media_type matters, and there is no mention of failure behavior when the checksum matches but units differ.

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 30% across 10 params, so the description carries real burden. It does usefully define the reuse identity tuple (checksum, size, filename, units) and the same-project scoping, but says nothing about kind, media_type, request_id, or how project_id interacts with the tuple. Partial compensation, not full.

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?

The description names a concrete resource and action: reuse an already-verified STL keyed by checksum/size/filename/units in the same project, or open its authenticated file picker. It explicitly contrasts with the sibling open_surface_upload for fresh interactive uploads, so an agent can route between them. It is slightly muddled about whether the primary action is 'reuse' or 'open picker', which keeps it off a 5.

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 branching: if artifact.state is ready, continue with that artifact and skip upload; otherwise show the upload panel and wait for get_artifact to report ready. It names the alternative (open_surface_upload without computing a hash) and states the condition selecting it. It also gives explicit negative guidance — never client-side S3 uploads, never retry old transfer URLs, never run shell/network commands.

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?