Gradient Dynamics: thermal and CFD simulation

Review mesh result

review_job

Idempotent

Accept or discard an existing verified mesh awaiting_decision because its achieved cell count missed the requested range. Report actual count, requested range and quality first; act only on the user's decision or explicit bounded authority delegated to the orchestrating agent. Accepting permits downstream simulation without remeshing; discarding retains saved artifacts. Neither action starts compute or relaxes hard quality checks or the 20-million-cell ceiling. To authorize a different attempt, use create_mesh with reviewed_job_id, the reviewed settings and a fresh idempotency key; do not resubmit an uncertain/running job.

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": {
      "action": "<action>",
      "reason": "<reason>",
      "job_id": "<job_id>"
    },
    "name": "review_job"
  }
}

Input Schema

Name	Required	Description
`action`	Yes
`job_id`	Yes
`reason`	Yes	Why the authenticated user or authorized agent accepts the cell-count deviation or discards this candidate.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description explains the consequences of each action: accepting enables downstream simulation without remeshing, while discarding retains saved artifacts. It also clarifies that neither action starts compute or relaxes hard quality checks or the 20-million-cell ceiling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded, moving from purpose to required reporting and authority, then consequences, constraints, and the alternative path. Every sentence contributes operational detail, and there is no redundant restatement of the title or schema.

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 stateful review decision with an output schema, the description supplies the complete operational context: preconditions, authority requirements, action effects, hard constraints, and the correct alternative tool. It leaves return-value details to the output schema and does not omit any behavior needed to invoke the tool safely.

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?

With only 33% schema description coverage, the description adds substantial meaning for action by explaining accept versus discard effects and for job_id by framing it as an existing verified mesh awaiting_decision. The reason parameter is already documented in the schema, and the job_id UUID format is left to the 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?

The description states a precise verb pair and resource: accept or discard an existing verified mesh that is awaiting_decision because its cell count missed the requested range. It clearly distinguishes this lifecycle decision from create_mesh and from resubmitting an uncertain or running job.

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 gives explicit when-to-use guidance: act only on the user's decision or explicit bounded authority, and only for a verified mesh awaiting_decision. It also names the alternative for a different attempt (create_mesh with reviewed_job_id) and explicitly excludes resubmitting an uncertain or running job.

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?