Skip to main content
Glama

Get checkout status

jami_get_checkout_status
Read-onlyIdempotent

Retrieve the current status of a checkout session by ID once, reconciling with the payment provider so late webhooks don't delay resolution.

Instructions

Check a checkout session once. The server reconciles with the payment provider on every call, so this resolves even when webhooks are late.

Args:

  • session_id: from jami_create_checkout.

Returns: { session_id, status: 'open' | 'completed' | 'expired', order_id, order_status, amount_minor, amount, expires_at, failure }. When status is 'expired', failure.code explains why: payment_rejected · payment_failed · payment_canceled · payment_timed_out · initiate_failed · session_expired.

Use jami_wait_for_checkout instead if you want to block until the buyer finishes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesCheckout session id returned by jami_create_checkout, e.g. "6710c2e8b1a2f0012ab34cd9"
response_formatNo'markdown' (default) for a readable summary, 'json' for the full structured payloadmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesHuman-readable amount, e.g. "150.00 ETB"
statusYes
failureYesWhy the session ended without an order; null unless status is "expired"
order_idYes
expires_atYes
session_idYes
amount_minorYesInteger santim (100 = 1.00 ETB)
order_statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

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

Goes well beyond the annotations (readOnlyHint/idempotentHint/openWorldHint) by disclosing server-side reconciliation on every call and enumerating the failure.code values that explain an expired session. It does duplicate the return-value enumeration that the output schema already carries, which caps this slightly below a 5.

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 purpose sentence, then clearly labeled Args/Returns blocks, then the alternative-tool line. Nearly every sentence earns its place; the only drag is the return-value enumeration repeating what the output schema provides.

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 polling tool it covers semantics, error decoding, and the sibling choice. Since an output schema exists, the description is not required to describe return values, so the remaining 'gap' is minor rather than material.

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% and the schema already documents both parameters, including that session_id comes from jami_create_checkout, so the Args line is largely redundant. response_format is not mentioned in the description at all. Baseline 3 applies.

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 and resource ('Check a checkout session once') and immediately names the sibling it is not ('Use jami_wait_for_checkout instead if you want to block'). An agent can pick between the two checkout tools without opening either 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?

Explicit routing rule with the selecting condition: poll with this tool, block with jami_wait_for_checkout. It also gives the operational reason to prefer it ('server reconciles with the payment provider on every call, so this resolves even when webhooks are late'), which is exactly the when-to-use context needed.

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