Skip to main content
Glama
Zesty0wl

Starling Bank MCP

Settled transactions by settlement time

list_settled_transactions
Read-onlyIdempotent

Retrieve settled account transactions by settlement date range to reconcile card payments that post days after purchase. Filter all categories between two timestamps, max one year.

Instructions

Lists settled transactions across the whole account (all categories) whose SETTLEMENT time falls between two timestamps (max 1 year). Useful for reconciliation, since card payments settle days after the purchase.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesSettlement time to (a plain date means end of that day) (ISO-8601, e.g. 2026-01-31 or 2026-01-31T18:00:00Z)
fromYesSettlement time from (ISO-8601, e.g. 2026-01-31 or 2026-01-31T18:00:00Z)
detailNocompact (default): trimmed rows with formatted amounts; full: every field Starling returns
accountUidNoAccount UID. Optional: defaults to STARLING_DEFAULT_ACCOUNT_UID, the only account, or the PRIMARY account

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and read-only safety. The description adds the settlement-time distinction and the 1-year max window, which is useful context. But it doesn't describe ordering, pagination, or result limits beyond what annotations provide.

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?

Two sentences, front-loaded with the main action and scope, followed by a single justificatory clause. No filler, no repetition.

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 list tool with a rich schema and full annotations, the description covers the key differentiator (settlement time) and a usage note. No output schema exists, so return shape is not explained, but for this tool type that is acceptable. Missing only explicit alternative-tool routing.

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 coverage is 100%, so parameters are fully documented in the schema (including the 'detail' enum and accountUid default behavior). The description adds the max 1-year constraint, which is not in the schema. That is a small but meaningful addition; baseline would be 3, and the constraint nudges it within that range.

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 (Lists), resource (settled transactions), and scope (whole account, all categories, settlement time window). Distinguishes from siblings like list_transactions by clarifying the settlement-time basis versus transaction time.

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?

Mentions 'useful for reconciliation' and explains why (card payments settle days after purchase), which implies when to use it. However, it does not name the alternative (list_transactions) or state when to prefer this tool over that one.

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