Skip to main content
Glama
Sign In
mercury-invoicing-mcp

mercury-invoicing-mcp

by klodr
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

mercury_list_credit_transactions

Read-only

List transactions on a Mercury IO Credit card account, including pending (not-yet-settled) card authorisations.

Instructions

List transactions on a Mercury IO Credit card account, including pending (not-yet-settled) card authorisations.

USE WHEN: auditing IO Credit card spend, reconciling a statement, or building a card-level transaction view. Wraps GET /account/{id}/transactions — same path Mercury exposes for deposit-account transactions; both this tool and mercury_list_transactions hit it. Supports the same filters.

DO NOT USE: for deposit-account transactions (use mercury_list_transactions). For posted transactions only, filter by status: "sent".

⚠️ Omitting start does NOT mean "all history". Mercury silently returns only a recent window — roughly the last statement period — with nothing in the response to say it truncated. Observed on a real IO Credit account: 68 transactions without start, 532 for the same card with start set. Always pass start when auditing a period, and page with offset until a call returns fewer than limit rows.

RETURNS (default detail: "compact"): { transactions: [{ id, amount, status, kind, postedAt, counterpartyName, categoryName, hasAttachment, ... }] }. pending items are card authorisations that may still be reversed. hasAttachment is always present, true or false — it answers "which card charges are still missing a receipt". Receipt URLs are never returned here; get one deliberately via mercury_get_transaction_attachment. Pass detail: "full" for every Mercury field.

Input Schema

NameRequiredDescriptionDefault
endNoFilter posted on/before this date (YYYY-MM-DD)
limitNoMax results to return (1-500). Default: 500
startNoFilter posted on/after this date (YYYY-MM-DD)
detailNoPayload shape. "compact" (default) projects to identifying fields and reports receipts as a boolean. "full" returns every Mercury field — attachment URLs are stripped in both modes.
offsetNoPagination offset
searchNoSearch query (counterparty name, memo, etc.)
statusNoFilter by transaction status. `pending` = card auth not yet settled.
accountIdYesThe Mercury IO Credit account ID (from mercury_list_credit_accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.3
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Payload shape. \"compact\" (default) projects to identifying fields and reports receipts as a boolean. \"full\" returns every Mercury field — attachment URLs are stripped in both modes.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. Addedv0.15.6
  3. Removedv0.15.5
  4. Addedv0.15.4
  5. Removedv0.15.2
  6. Addedv0.12.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries the real burden and does: it discloses Mercury's silent truncation when `start` is omitted, with a quantified observation (68 vs 532 rows) to make the risk credible, and prescribes offset paging until fewer than `limit` rows return. It also flags that receipt URLs are stripped and must be fetched via `mercury_get_transaction_attachment`. Slight deduction for not stating rate limits or the truncation window's exact boundary.

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?

Front-loaded purpose, then uppercase USE WHEN / DO NOT USE headers, then a clearly marked warning, then RETURNS. Long but every block is functional — the anecdotal row counts exist to justify the truncation warning rather than pad the text.

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?

No output schema exists, and the description compensates by sketching the returns envelope, explaining that `pending` items are reversible authorisations, and noting `hasAttachment` is always present as a receipt-gap signal. For an 8-parameter, single-required-param read tool with annotations, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so baseline is 3, and the description still adds value the schema cannot: the semantics of omitting `start`, how `offset` should be used with `limit`, and what `detail: "compact"` vs `"full"` actually yields. It does not restate or clarify `search`, `end`, or `accountId` beyond schema text.

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 (list transactions on a Mercury IO Credit card account) plus the distinguishing scope detail that it includes pending, not-yet-settled authorisations. It names the confusable sibling `mercury_list_transactions` and explains that both hit the same endpoint, so an agent can separate the two without reading 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?

Has an explicit USE WHEN block (auditing card spend, reconciling a statement, building a card-level view) and an explicit DO NOT USE block routing deposit-account work to `mercury_list_transactions`. It also gives a concrete downstream filter recipe (`status: "sent"` for posted-only), leaving nothing to inference.

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

Deploy Server

Other Tools