Gradient Dynamics: thermal and CFD simulation

View residual history

view_convergence_history

Idempotent

Show a finished simulation's residual history in the browser: residuals per equation against iteration on a log scale, and drag, lift and any named force coefficients against iteration, with the saved convergence window and verdict when there is one. Do this at the end of every simulation, whether it converged, diverged or stopped at its iteration limit; get_job does it automatically and returns convergence_chart. Show viewer_url as a labelled link in your reply with the outcome and final residuals, preserving the complete URL including its fragment. Judge convergence from the history, not only from whether residuals reached a tolerance such as 1e-6: report result.convergence_assessment when present and point the user to its window on the chart; steady force coefficients with flat residuals can be a usable result short of the tolerance, while residuals still falling steeply, rising, or forces still drifting mean more iterations would change the answer. Report what the chart shows and let the user decide on a longer run; never rerun automatically. Uses only the job's saved result: no compute and no charge. Requires jobs:read and artifacts:read.

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": {
      "job_id": "<job_id>"
    },
    "name": "view_convergence_history"
  }
}

Input Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: no compute and no charge, reads only the job's saved result, requires jobs:read and artifacts:read, and the returned viewer_url must be shown as a labelled link with the full fragment. The readOnlyHint=false annotation is consistent with producing a browser viewer rather than being contradicted by the 'no compute' claim.

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 is front-loaded and the alternative routing follows immediately, which is the right order. The convergence-judgement and linking instructions are valuable but make the text long and dense for a single-parameter view tool; a small amount could be tightened.

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?

With one parameter, an output schema, and existing annotations, the description fills the remaining gaps an agent needs: permissions, zero cost, no automatic rerun, how to present viewer_url, and how to interpret the plotted history rather than relying on a bare tolerance threshold.

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?

Only one parameter, and the schema supplies its type and uuid format while it carries no description. The description adds the meaningful constraint that the job must be a finished simulation with a saved result, but never refers to the parameter explicitly or explains failure behavior for a running or failed job.

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?

Specific verb and resource: 'Show a finished simulation's residual history in the browser', with the exact contents enumerated (residuals per equation vs iteration on a log scale, drag/lift/force coefficients vs iteration, saved convergence window and verdict). It also distinguishes itself from the sibling that duplicates the capability, noting get_job does it automatically and returns convergence_chart.

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 when-to-use ('at the end of every simulation, whether it converged, diverged or stopped at its iteration limit') and an explicit alternative already covering the case ('get_job does it automatically and returns convergence_chart'). It also states a when-not-to-act rule ('never rerun automatically') and how to hand the decision back to the user.

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?