Skip to main content
Glama

Gradient Dynamics: thermal and CFD simulation

Get job status

get_job
Idempotent

Read job state, progress, quality/result summary and artifact IDs, including retained diagnostics after failure. For finished geometry, mesh or published simulation results, automatically prepares/reuses one default interactive 3D browser view. Mesh and simulation jobs also return geometry_viewer, the source surface's link: include it in the reply when the geometry was requested. Open its viewer_url when possible and show a labelled link without waiting for another user request, even if snapshots are also supplied; if viewer has operation_id, finish get_operation then show the link. Browser-view failure does not invalidate saved compute. Set prepare_viewer=false for status only or when the user declines a viewer. Do not create unrequested sections or restart a failed/cancelled view automatically. awaiting_decision means compute has finished and nothing is charged unless the mesh is accepted: report result.review and quality, then ask the user or explicitly authorized agent to accept/discard through review_job or authorize a new attempt. Stop polling this state; do not resubmit automatically. Report available residuals, forces and y+ with their qualification; no field export does not imply no metrics. Read events and owned summary artifacts before claiming evidence is missing. Numerical nonconvergence/step limits and publication/integrity failures are different outcomes; never auto-rerun. On failure, explain error.title and error.message, report its evidence and follow error.action. error.stage and ran_for say where and after how long; stage_source=last_observed is not a confirmed failure location. Unknown cause must stay unknown; same_request_may_succeed is advisory, never retry authorization. Tell the user in plain words and agree any new attempt with them. For a finished simulation (converged, diverged or stopped at its iteration limit) it also returns convergence_chart: show its viewer_url as a labelled residual history link every time (see view_convergence_history). If submission_unknown, do not submit a replacement: operator reconciliation is needed. A job's queue.message says why it hasn't started (waiting in the queue, for example one meshing job per person at a time, or waiting for GPU); pass it on to the user and keep polling. Waiting isn't charged. While a native mesh runs, result.stage, running_seconds against estimated_seconds (estimated_seconds_high is the upper bound), and memory_in_use_gb of memory_reserved_gb say what it is doing; report them rather than only that it is running. Poll at least five seconds apart.

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": "get_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYes
prepare_viewerNoPrepare one default browser view automatically after completion. Set false when the user declines visualization or wants status only; saved viewer links may still be returned.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations say readOnlyHint=false and idempotent=true, and the description explains why a 'get' tool is not read-only by disclosing the automatic viewer preparation and reuse. It adds substantial side-effect context: awaiting_decision means nothing is charged until acceptance, queued jobs are not charged, browser-view failure does not invalidate saved compute, and failure diagnostics are retained. It does not describe pagination or response size, but with an output schema present that gap is minor.

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?

The first sentence front-loads the purpose well, but the remainder is a single dense block of roughly 350 words with no paragraphing, bullets or grouping by state (success, awaiting_decision, queued, failure). Several sentences are conversational policy rather than tool semantics ('include it in the reply', 'tell the user in plain words', 'do not create unrequested sections'), which adds bulk that could be trimmed or moved to response-level guidance.

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 high-complexity polling tool with multiple terminal and intermediate states, it covers success, queued-but-not-started, native-mesh progress fields, awaiting_decision, numerical nonconvergence versus publication failure, and unknown submission. An output schema exists, yet the description usefully signals which fields to surface and how to interpret error.stage, stage_source and same_request_may_succeed, leaving no operationally significant state unexplained.

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?

Schema coverage is 50%; prepare_viewer already has a description, and the prose enriches it with concrete decision rules ('status only or when the user declines a viewer') and a note that saved viewer links may still be returned. job_id receives no added meaning beyond being a job identifier, leaving one of two parameters undocumented in the description, which keeps this below a 5.

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?

Opens with a specific verb and resource: read job state, progress, quality/result summary, artifact IDs, plus retained diagnostics after failure, which is far more concrete than the title. It names a few related tools (review_job, get_operation, view_convergence_history) but never distinguishes itself from close siblings like get_job_events or get_simulation_results, which also report job information.

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?

Explicitly states when to set prepare_viewer=false (status only, or user declines), when to stop polling (awaiting_decision), when to route to review_job, and multiple when-not rules (never auto-rerun, never resubmit on submission_unknown, do not restart a failed/cancelled view). It also gives polling cadence (at least five seconds apart) and an ordering rule for get_operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources