Skip to main content
Glama

mcg_get_run

Read-only

Fetch a run's state, event timeline and LLM spend. The payload leads with a derived summary (state, current_stage, billing {quoted_tokens, charged_tokens, hold, policy}, fault, refusal, next, last event, campaign) for cheap polling, then app_url (the run page, for the human), study and headline. events holds the newest events that fit about 12 KB plus the last complete or fail event; events_omitted counts the others. In a payload over 2 KB, each value over 256 chars becomes {omitted_bytes, see}, where see names the route that returns the full event. A report body_md over 6,000 chars becomes the same stub; a brief body_md is cut at 6,000 chars and ends in an ellipsis; llm_spend.calls holds the newest 10 calls, and calls_omitted counts the rest. A done, node-addressed run also carries record (its OpenMaterials SimulationRecord), openmaterials_url (the datasheet link) and openmaterials_label: null, or the commons' note when the record cites a model, configuration or code that is not in the public registry (record.unregistered lists each model and configuration), so its values cannot be checked against the commons. A campaign parent's summary.campaign holds its round, step, ceiling_tokens, committed_tokens, measured_tokens, finish, counts (children per state), children (every open child and the newest 8 settled ones, each with run_id) and children_omitted; GET /api/runs/:id lists every child. Its children are charged in the parent's one capture, so a child shows charged_tokens 0 and hold parent.

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": {
      "run_id": "<run_id>"
    },
    "name": "mcg_get_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run id from mcg_run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries the behavioral burden and does so extensively: it discloses truncation thresholds, stub structures, event omission counts, report body limits, LLM call limits, campaign child accounting, and record availability. This is far beyond what the annotations provide.

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?

The description is front-loaded with the core purpose and follows with detailed payload behavior, so the most important information comes first. It is dense and long, but nearly every sentence conveys operational detail needed to interpret the response correctly.

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?

Given the complex return payload, absence of an output schema, and single-parameter input, the description is complete enough for an agent to call and interpret the tool. It explains response structure, truncation behavior, and special campaign and record cases.

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 coverage is 100% and there is only one required parameter, run_id, whose meaning is already documented in the schema. The description does not add meaningful semantics beyond the schema baseline.

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 opens with a specific verb and resource: fetching a run's state, event timeline, and LLM spend. It clearly distinguishes the payload's summary, events, and spend sections, letting an agent understand exactly what mcg_get_run returns.

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?

It gives clear usage context, notably that the derived summary is for cheap polling and app_url is for the human. It also points to GET /api/runs/:id when every child is needed, though it does not explicitly compare against sibling tools like mcg_list_runs.

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