jami-mcp

List orders

jami_list_orders

Read-onlyIdempotent

List your organization's orders newest first, filter by paid, pending, or failed status, and page through results to total revenue or find a specific buyer.

Instructions

List the organization's orders, newest first, one page at a time.

Args:

status: 'paid' | 'pending' | 'failed' (optional filter).
page: 1-based page (default 1).
limit: 1–100 per page (default 20).

Returns: { orders: [{ order_id, status, amount_minor, amount, product: { id, title }, customer: { id, email, name }, paid_at, created_at, metadata }], total, page, limit, count, has_more, next_page }.

To total revenue or find a specific buyer, page through with next_page until has_more is false. Amounts are integer santim (100 = 1.00 ETB); this is what buyers paid, before any withdrawal fee.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`status`	No
`response_format`	No	'markdown' (default) for a readable summary, 'json' for the full structured payload	markdown

Output Schema

TableJSON Schema

Name	Required	Description
`page`	Yes
`count`	Yes	Records in this page
`limit`	Yes
`total`	Yes	Total matching records
`orders`	Yes
`has_more`	Yes
`next_page`	No	Pass as `page` to fetch the next page

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 16, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds genuinely new behavioral context: newest-first ordering, page-at-a-time retrieval with defaults, and the unit/semantics of amounts ('integer santim, 100 = 1.00 ETB ... before any withdrawal fee'). No rate limits or auth requirements are mentioned, keeping it out of 5 territory.

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 followed by tightly formatted Args/Returns/Notes blocks; each line carries information. The Returns block restates a payload that an output schema already defines, which is mild redundancy, though the accompanying santim/fee note justifies its presence.

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?

Beyond pagination mechanics, it supplies the amount unit convention and the 'before withdrawal fee' caveat, which cannot be inferred from the schema or output schema. Combined with the documented filters and paging contract, an agent has everything needed to call and interpret this tool correctly.

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

Parameters4/5

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

Schema description coverage is only 25%, so the description carries the load and does so for three of four params: status filter values, page being 1-based with default 1, and limit range 1–100 with default 20. It silently omits response_format (markdown vs json), which is the one parameter the schema documents and which materially changes what the agent receives.

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 ('List the organization's orders') plus scope and ordering ('newest first, one page at a time'). It is clearly distinguishable from sibling list tools on other resources (withdrawals, products), but it never names a sibling or an alternative to route against, so it stops short of a 5.

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?

Gives a concrete usage path: 'To total revenue or find a specific buyer, page through with next_page until has_more is false.' That tells the agent how to satisfy a goal, which is real guidance. It does not state when *not* to use this tool or name a preferred alternative, so no exclusions are covered.

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

Deploy Server