Skip to main content
Glama

Get a run's report

get_report
Read-only

Retrieve a run’s full markdown report with measured figures, what changed and why, and recommended next steps.

Instructions

The run's full report as markdown: the measured figures, what was changed and why, and what to do next. Available on every plan, including the trial.

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

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the output is markdown and it is available on all plans including the trial. It does not say whether a report exists before the run completes, or whether it is truncated or paginated.

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?

Two short sentences, front-loaded with what the report contains, with no filler. Slightly more compact phrasing could tighten the second sentence, but nothing is wasted.

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?

With no output schema, the description does the necessary work of describing the return value (markdown report with figures, rationale, and next steps). The remaining gap is behavioral: it doesn't clarify availability relative to run state, which matters for a per-run artifact tool.

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?

There is a single parameter (run_id) and schema description coverage is 100%, so the schema carries the documentation burden. The description adds nothing about run_id format or where to obtain one. Baseline 3 is appropriate given high coverage with no compensating detail in prose.

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?

States a specific resource (the run's full report) and enumerates its contents: measured figures, what was changed and why, and next steps. That is far more concrete than the sibling run_status or download, though it never names or contrasts them explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is the tool for retrieving the complete narrative report for a finished run. The only explicit guidance is a plan-availability note ('every plan, including the trial'), which is about access, not about when to choose this over run_status or wait_for_run.

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