Gradient Dynamics: thermal and CFD simulation

Plan cold-plate designs

plan_cold_plate

Read-onlyIdempotent

Plan liquid cold-plate designs that cool a GPU or IGBT within its temperature and pressure-drop limits. Planning only: no compute and no charge. Derive a GPU/IGBT template prototype from a saved brief and validate up to 16 explicit parameter variants against its numeric manufacturing constraints. Inspect defaults, device layout, power allocation, conflicts and export limitations. Submit eligible geometry requests using create_geometry and returned stable keys. No geometry, simulation or optimisation compute is launched by planning.

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": {
      "project_id": "<project_id>",
      "brief_id": "<brief_id>"
    },
    "name": "plan_cold_plate"
  }
}

Input Schema

Name	Required	Description
`vary`	No	Explicit grid of up to 16 candidates; use evaluated best parameters as the next baseline
`brief_id`	Yes
`parameters`	No
`project_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered; the description adds genuinely new traits — no compute launched, no charge incurred, validation capped at 16 variants against numeric manufacturing constraints. Repetition of the 'no compute' message in the closing sentence is slightly wasteful but reinforces a key cost expectation.

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?

Front-loaded with purpose and the planning-only constraint, and the workflow sentences are ordered sensibly. But the 'no compute and no charge' point is made twice (opening and closing sentences), and the middle clause cramming defaults, layout, power allocation, conflicts and export limitations reads as a checklist.

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?

An output schema exists and the description notes stable keys are returned, so return-value detail is unnecessary. For a tool with nested objects and a 16-variant grid, the description conveys enough scope, constraints and handoff path to call it correctly, though the undocumented project_id is a minor gap.

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 25%, so the description must carry weight; it partly does by tying 'saved brief' to brief_id and 'up to 16 explicit parameter variants' to vary. However project_id and the general parameters object get no explanation, leaving meaning for half the parameters to the bare schema.

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?

States a specific verb+resource (plan liquid cold-plate designs) plus the operating envelope (GPU or IGBT within temperature and pressure-drop limits), and immediately scopes it as planning-only. This clearly separates it from siblings such as prepare_cold_plate_simulation and compare_cold_plate_candidates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Explains the workflow role: derive a template prototype from a saved brief, validate up to 16 variants, and hand off eligible requests to create_geometry using returned stable keys. It lacks explicit exclusions against nearby siblings (e.g., when to compare candidates instead), so a small inference remains.

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?