Skip to main content
Glama

Get Run

get_run
Read-only

Get full details of a specific run including insights. Look up by Converra run ID or by external session ID (e.g. LangSmith/Langfuse session_id).

Input Schema

NameRequiredDescriptionDefault
sessionIdNoExternal session ID (LangSmith/Langfuse session_id or Converra SDK sessionId). Used only when conversationId is not provided.
customerIdNo(Converra superadmin only) Target customer ID to act on behalf of
conversationIdNoThe Converra run ID
includeInsightsNoInclude run insights (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that insights are part of the payload, but that is also stated in the schema for includeInsights, so it contributes little beyond structured fields; return shape and any permission notes are absent.

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?

Two sentences, zero filler, with the core action and payload front-loaded and the lookup mechanism immediately after. Every clause carries information.

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?

For a read-only getter with 100% schema coverage and no output schema, the description covers action, payload, and lookup key. The one soft spot is that no parameter is required, so an agent could call with zero arguments; the 'look up by X or Y' phrasing mitigates this but does not spell out the either/or requirement.

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 description coverage is 100%, so all four parameters are already documented, including the LangSmith/Langfuse example and the conversationId-preferred rule. The description only restates those two lookup modes, adding no syntax or format detail beyond the schema — baseline 3.

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 verb and resource ('Get full details of a specific run') plus the scope of what comes back ('including insights'). It clarifies the two lookup keys, which helps separate it from list_runs and the insight-specific siblings, but it never names an alternative tool 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?

It implies when the tool applies ('Look up by Converra run ID or by external session ID') and effectively tells the agent that one of the two identifiers is needed. However, it gives no guidance on when to prefer this over get_run_insights, get_run_step_diagnosis, or list_runs, and no exclusions.

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