Skip to main content
Glama

Rendreal

List this session's orders

order_list
Read-onlyIdempotent

List the orders created in this session, each with its live status.

Scoped to this session's own Order Records: an order placed in another session, or by another caller, is not listed here — it is reached through order_lookup with the customer's reference + email. Whenever you tell the customer that only this conversation's orders can be shown, also tell them they can see any other order of theirs by giving its order reference and the email they used at checkout. last is false when the session has more orders than one call shows (only the most recent are returned); total_elements is the session's true order count, so a false last means older orders exist beyond the list.

Returns a job — poll until SUCCEEDED. On failure the job error is RendrealNotConfiguredError (no client) or a Rendreal*Error — the latter only when every listed order's status read fails (a systemic outage); one failed read degrades that row to a null status and the job still succeeds. An order deleted upstream is omitted from the list entirely (and from total_elements), never shown as a pickable row.

The widget's picker commits an ordinal reference with the order's status attached for disambiguation (e.g. "Nr 2 - Complete, please.") rather than an id — 1-indexed against this same call's orders list, in order. Map the number back to that list position's order_id before calling order_get (these are this session's own orders, so no email is needed); don't match on status alone (several orders can share one).

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": {
      "session_id": "<session_id>"
    },
    "name": "order_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Adds substantial behavior beyond the annotations: job-based async execution with polling, named failure modes (`RendrealNotConfiguredError`, `Rendreal*Error` only on systemic outage), per-row null degradation on a single failed read, and omission of upstream-deleted orders from both the list and `total_elements`. However it never reconciles this job-creation behavior with the `idempotentHint`/`readOnlyHint`/`openWorldHint: false` annotations (a partially failing status read is arguably world-dependent), and gives no rate-limit or cost guidance for repeated polling.

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?

Front-loaded with the core statement and the scoping rule, and every paragraph carries distinct operational value (scoping, pagination, job semantics, ordinal-reference mapping). It is long and could be tightened — the customer-message instruction and the widget/ordinal mapping could be more compactly stated — but there is little pure filler.

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?

Since an output schema exists, return-value documentation is not owed, yet the description explains `last`/`total_elements` pagination and the `orders[].order_id` mapping needed to call `order_get`, which is genuinely necessary context. The remaining gap is the undocumented `session_id` parameter and no explicit statement of what happens if the session id is invalid or empty.

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 0% on the single `session_id` parameter, so the description is the only place meaning could be added — it repeatedly frames results as "this session's own" orders, which implicitly ties the parameter to the current session, but never states where `session_id` comes from or its format. The implicit link is helpful but not a substitute for real parameter documentation.

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?

States a specific verb+resource ("List the orders created in this session") plus the scope boundary, and explicitly names the sibling that handles the out-of-scope case (`order_lookup`). An agent can distinguish it from order_get/order_lookup without opening any schema.

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

Usage Guidelines5/5

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

Explicitly says when to use this tool (this session's own orders) and when not to (another session's or another caller's order → `order_lookup` with reference + email), and even prescribes the customer-facing message to accompany that limitation. It also tells the agent how to chain into `order_get` and warns against matching on status alone.

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