Skip to main content
Glama

get_body

Fetch the complete body for a plan, step, or turn by ID. Supports secret redaction, length limits, and model reasoning inclusion.

Instructions

Return the on-demand body for an event / plan id.

For a plan_event id: the full plan text and/or Codex steps (bodies are deliberately kept off the event stream so callers pay for them only when needed). For a user_turn / assistant_turn id: the turn text.

shallow=True (plans only) returns just the final plan of the id's task, dropping the bodies of superseded draft revisions — the S6 case where a subagent receives one plan without the draft noise (dropped_drafts lists the ids that were elided).

max_chars bounds the returned body/text (default 500_000, generous enough that ordinary bodies are never cut; pass 0 to disable). When it trips, the field is sliced with a …[truncated] marker and body_truncated: true is set.

redact=True (default) masks secrets in the emitted text/body/title/steps as [REDACTED_<TYPE>] and adds a redactions type→count dict when any replacement happened; redact=False returns the raw content.

include_thinking=True (turn ids only): attach the model's reasoning (message.thinking) as a separate thinking field on the returned body, re-read from the hosting message. Default False leaves the body byte-identical to the historical shape (no thinking key). Fail-soft: a turn without reasoning never carries the key.

Returns the body dict, or {"error": ..., "message": ...} on a bad id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
redactNo
shallowNo
max_charsNo
include_thinkingNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description carries full behavioral disclosure. It covers return format, truncation behavior with markers, redaction semantics and defaults, the fail-soft behavior of include_thinking, and error responses—all beyond what annotations would typically convey.

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?

Though long, the description is densely informative and well-structured: main purpose first, then parameter explanations, then return behavior. Every sentence adds operational value, and the examples (S6 case, fail-soft) clarify edge cases without redundancy.

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?

The tool has 5 parameters, a complex combination of behaviors, and no annotations. The description covers all parameter semantics, edge cases, defaults, and error handling. The presence of an output schema means return-value details are not required, but the description still states the return shape, making it complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must explain all parameters. It does so thoroughly: id type and meaning, shallow's draft-skipping behavior, max_chars truncation with 0 to disable, redact's masking behavior, and include_thinking's conditional field. This fully compensates for the absent schema descriptions.

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 uses a specific verb ('Return') and identifies the exact resource ('on-demand body for an event / plan id'). It distinguishes between plan_event and user_turn/assistant_turn id types, making the tool's scope clear and differentiating it from sibling tools that handle sessions or audits.

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?

The description explains when to use the tool (for on-demand body retrieval, deliberately off the event stream) and provides detailed guidance on which id types apply. It does not explicitly name alternatives among sibling tools, but the contextual cues ('bodies are deliberately kept off the event stream') imply when this tool is appropriate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pro-target/ai-r'

If you have feedback or need assistance with the MCP directory API, please join our Discord server