Gradient Dynamics: thermal and CFD simulation

Build geometry

create_geometry

Idempotent

Build CAD (STL, and exact STEP where supported) for a cooling or flow design from a template or design document. CPU job, not charged: usually under a minute for a part, several minutes for a detailed assembly. To test parameter changes, run one design study through call_design_operation, not a build per variation. Not for editing an uploaded CAD file (use reconstruct_cad and edit_reconstructed_cad). Submit a durable geometry job from exactly one template_id or self-contained gd.design/v1 document, including complex feature graphs returned by design edits. Document assets/imported CAD references are currently unsupported; never discard them. STL/design defaults; exact STEP only when supported by every exported feature. For meshing implicit multizone geometry, set purpose=meshing, method=auto and explicit output_names to permit checked named faceted STEP volumes. Heatmaps and boundary patches are not volume regions; artifact metadata records exact versus faceted geometry. Returns job ID and immutable artifact lineage for viewing, meshing and simulation; does not approve the design or edit Studio projects. May incur compute 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": {
      "idempotency_key": "<idempotency_key>"
    },
    "name": "create_geometry"
  }
}

Input Schema

Name	Required	Description	Default
`method`	No	Exact STEP by default. For purpose=meshing, auto permits checked faceted STEP for implicit volumes; artifacts record the actual representation.	exact
`outputs`	No
`purpose`	No	Meshing requires explicit volume output_names; heatmaps, boundary patches and display helpers are rejected by the geometry engine.	export
`bounds_m`	No
`document`	No	Self-contained gd.design/v1 feature graph, up to 1 MiB. Use native design catalogue/edit operations to compose it. Mutually exclusive with template_id; assets/external references are not supported. Native validity, manufacturing and exact export are checked by the worker.
`named_stl`	No	Also export each selected document body as a separate named STL, alongside the combined surface, for mesh wall patches.
`notify_url`	No	Optional public HTTPS URL that receives a signed notification when the job finishes, so you need not poll.
`parameters`	No
`project_id`	No
`resolution`	No
`template_id`	No	Registered template; mutually exclusive with document
`output_names`	No
`deflection_mm`	No
`workflow_name`	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.
`design_brief_artifact_id`	No	Immutable owned design brief used to derive this candidate; retained in job lineage

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

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses duration expectations (under a minute for a part, minutes for an assembly), that document assets/imported CAD references are unsupported and must not be discarded, that artifact metadata records exact vs faceted geometry, and that the tool does not approve designs or edit Studio projects. The only blemish is internal inconsistency about billing: 'CPU job, not charged' followed at the end by 'May incur compute charges.'

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 cost, then constraints and routing rules; nearly every sentence carries a distinct fact. It is dense and somewhat run-on, and the final 'May incur compute charges' partially undoes the earlier 'not charged' claim, which is wasted/confusing text.

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 16-parameter job-submission tool with an output schema, it covers the load-bearing concerns: input-mode exclusivity, representation selection, meshing prerequisites, async lineage, and what it does not do. The remaining gap is that several numeric knobs (resolution, deflection_mm, bounds_m) are neither described here nor in the schema beyond type and range.

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?

At 50% schema coverage the description must compensate, and it does explain the highest-risk parameters: template_id/document mutual exclusivity, purpose=meshing with method=auto and explicit output_names to get checked named faceted STEP volumes, and the rejection of heatmaps/boundary patches as volume regions. It still leaves resolution, deflection_mm, bounds_m, outputs, named_stl and parameters undocumented in prose, so the compensation is partial.

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 description names a specific verb and resource ('Build CAD (STL, and exact STEP where supported) for a cooling or flow design') and explicitly states the two input modes (template or design document). It also differentiates from siblings by naming reconstruct_cad/edit_reconstructed_cad for editing and call_design_operation for parameter sweeps.

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 contains explicit when-to-use guidance ('from exactly one template_id or self-contained gd.design/v1 document', including feature graphs from design edits), explicit when-not ('Not for editing an uploaded CAD file'), the named alternatives, and a routing rule to run one design study via call_design_operation instead of a build per variation.

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?