Skip to main content
Glama
ONDC-Official

ondc-mcp

Official

Read a recorded payload

record_get_payload
Read-onlyIdempotent

Fetch a session's recorded payload by handle, using JSONPath to extract only needed parts from large catalogs.

Instructions

Fetch a payload this session sent or received, by the handle reported in flow_get_status or flow_await. Payload bodies are held server-side and can be very large — a catalog runs to hundreds of kilobytes — so prefer a jsonpath slice (e.g. $.message.catalog.providers[*].id) over the whole body. The result says whether it was truncated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsonpathNoJSONPath to slice out instead of the whole body, e.g. $.message.catalog.providers[*].id. Use this on large catalogs.
max_bytesNoTruncate the serialised result past this many bytes. Defaults to 20000.
payload_idYesPayload handle, as reported by flow_get_status or flow_await.
session_idYesSession returned by session_create.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ackNoThe ACK/NACK exchanged for this call, when one was recorded.
actionYes
eventsNoWhat has happened in this session since your last call — the participant's callbacks, steps sent automatically, refusals, form submissions. Attached to every session-scoped result and delivered exactly once, so read it here instead of polling. Absent when nothing happened. `more` above zero means call record_get_events for the rest.
payloadYesThe whole body, or — when `jsonpath` was given — the **list of matches** for it. A single match is therefore still wrapped in an array: `$.context.bpp_uri` on a string field reads `["https://…"]`. Read `jsonpath_matches` before concluding the value is itself a list.
directionYes'outbound' if this mock sent it, 'inbound' if the participant did.
timestampYes
truncatedYesTrue when the body was cut short; narrow it with jsonpath.
message_idYes
payload_idYes
size_bytesYesSize of the full stored body.
jsonpath_matchesNoHow many nodes the `jsonpath` matched. Present only when one was given. `payload` is that many elements long, so the outer array is this count and not part of the stored value.
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable context beyond annotations: payloads are held server-side, can be very large, and the result includes a truncation indicator. This helps the agent understand performance and response characteristics, though it doesn't cover exhaustive edge cases.

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?

Three sentences, front-loaded with purpose, followed by practical guidance. No wasted words; every sentence earns its place.

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 presence of an output schema, rich parameter descriptions, and annotations, the description provides sufficient operational context: handle source, large-payload warning, jsonpath recommendation, and truncation notice. It is complete for an agent to select and invoke the tool correctly.

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?

The input schema covers all parameters with descriptions (100% coverage). The description repeats the jsonpath example but does not add new meaning beyond the schema. Per the baseline rule, with high schema coverage a score of 3 is appropriate.

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: 'Fetch a payload this session sent or received, by the handle reported in flow_get_status or flow_await.' It clearly distinguishes the tool from sibling record_* tools by focusing on payloads and specifying the handle source.

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 provides clear context: use this tool to retrieve payloads using handles from flow_get_status or flow_await. It also gives practical advice to prefer jsonpath slicing for large payloads. However, it does not explicitly name alternative tools or state when not to use this tool.

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/ONDC-Official/automation-mcp'

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