Skip to main content
Glama

Settlement list cycles

settlement_list_cycles
Read-onlyIdempotent

List the buyer's settlement cycles (the tab): each cycle's status (open, closed, capturing, captured, settled, …), exposure limit, authorised, accrued and captured amounts in minor units, and capture_due_at, the end of the review window. funding is card_hold or prepaid; a prepaid cycle's remaining_pence is its unspent balance. Filter by status or currency; paginate with cursor. Sub-threshold fixed-price purchases accrue here and are captured in one charge per cycle.

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": {
      "page_size": "<page_size>"
    },
    "name": "settlement_list_cycles"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNoThe next_cursor from the previous page.
statusNoOnly cycles in this status.
currencyNoOnly cycles in this currency.
page_sizeYesCycles per page, 1 to 100 (default 20).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, closed-world and non-destructive, so the safety bar is largely covered. The description adds real domain behavior beyond that: the settlement lifecycle statuses, the card_hold vs prepaid funding model, what capture_due_at means (end of the review window), and the accrual-then-capture model for sub-threshold fixed-price purchases.

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 resource and its fields, and every clause carries information about the domain rather than padding. It is dense — several semicolon-joined ideas in one long sentence — but nothing is genuinely disposable.

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?

There is no output schema, and the description compensates by describing the shape of each returned cycle in detail, including units (minor units) and special-case fields (remaining_pence for prepaid cycles). Paired with annotations covering safety and a fully documented input schema, an agent has everything needed to call and interpret this.

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%, so the baseline is 3. The description's 'filter by status or currency; paginate with cursor' largely restates the schema without adding format, default, or edge-case detail, though the surrounding domain context helps interpret what a status filter actually means.

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?

Names a specific verb and resource ('List the buyer's settlement cycles') and immediately scopes it to the buyer's own cycles, plus enumerates the substantive fields each cycle carries. An agent knows exactly what this returns without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: 'Filter by status or currency; paginate with cursor' tells the agent what the filters do but not when to reach for this tool versus a single-cycle or dispute-oriented sibling. No explicit when-not or alternatives are offered.

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.