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

mercury-invoicing-mcp

by klodr
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

mercury_list_treasury_transactions

Read-only

List transactions for a Mercury Treasury account (sweeps, dividend accruals, etc.).

Instructions

List transactions for a Mercury Treasury account (sweeps, dividend accruals, etc.).

USE WHEN: auditing Treasury cash flows, reconciling yield accruals, or building a Treasury-only ledger view.

DO NOT USE: for deposit-account transactions (use mercury_list_transactions). For IO Credit transactions, use mercury_list_credit_transactions.

⚠️ This endpoint has no date filter. Unlike mercury_list_transactions, Treasury accepts only limit, order and cursor — there is no start/end. To audit a period, page through the transactions and filter on canonicalDay (the Treasury row date, YYYY-MM-DD) yourself.

⚠️ Pagination is cursor-based, not offset-based. Pass the top-level cursor of the response as the cursor of the next call, and stop when it is null or absent — a short page is not the end signal. Passing an offset does nothing — Mercury ignores it and you silently re-read page 1.

RETURNS (default detail: "compact"): { transactions: [{ id, type, description, amount, balance, canonicalDay, security, details, ... }], cursor } — null fields omitted. Pass detail: "full" for every Mercury field (accountId, null fields).

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows to return (default 100)
orderNoSort order on the transaction date. Defaults to "desc".
cursorNoPagination cursor: the top-level `cursor` of the previous response
detailNoPayload shape. "compact" (default) keeps the Treasury fields that identify, date and reconcile a row; "full" returns every Mercury field.
accountIdYesTreasury account ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.20.3
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Pagination cursor: the top-level `cursor` of the previous response",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Payload shape. \"compact\" (default) keeps the Treasury fields that identify, date and reconcile a row; \"full\" returns every Mercury field.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / end
      Removed value: -{
-  "description": "Filter before this date (YYYY-MM-DD)",
-  "format": "date",
-  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
-  "type": "string"
-}
    • addedInput schema / properties / limit / description
      Added value: +"Max rows to return (default 100)"
    • changedInput schema / properties / limit / maximum
      Previous value: -500New value: +1000
    • removedInput schema / properties / offset
      Removed value: -{
-  "maximum": 9007199254740991,
-  "minimum": 0,
-  "type": "integer"
-}
    • addedInput schema / properties / order
      Added value: +{
+  "description": "Sort order on the transaction date. Defaults to \"desc\".",
+  "enum": [
+    "asc",
+    "desc"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / start
      Removed value: -{
-  "description": "Filter after this date (YYYY-MM-DD)",
-  "format": "date",
-  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
-  "type": "string"
-}
  2. Addedv0.15.6
  3. Removedv0.15.5
  4. Addedv0.15.4
  5. Removedv0.15.2
  6. Changed1 schema field changedv0.12.0
    • addedInput schema / additionalProperties
      Added value: +false
  7. First observedv0.9.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only readOnlyHint/openWorldHint; the description adds non-obvious behavior the agent could not otherwise know: no start/end date filter exists, so period audits require client-side filtering on canonicalDay, and cursor pagination must be followed until null rather than inferred from a short page. It even warns that an offset argument is silently ignored and causes page-1 re-reads — precisely the kind of failure mode that prevents wrong calls.

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?

Well front-loaded with labeled blocks (USE WHEN / DO NOT USE / warnings / RETURNS), and every section carries load-bearing information. Slightly verbose where the DO NOT USE routing and the 'use mercury_list_transactions instead' warning restate the same contrast, but nothing is filler.

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 with an explicit RETURNS block naming the shape, the compact-vs-full distinction, and null-field omission. Combined with the date-filter and pagination caveats, an agent has everything needed to call and page 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 coverage is 100%, so the baseline is 3; the description still adds real semantics beyond the schema by specifying the pagination termination condition and the practical consequence of the missing date parameters. It stops short of 5 because it does not elaborate on `limit`/`order` or the `detail: "full"` field set beyond a one-liner.

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?

Opens with a specific verb+resource ('List transactions for a Mercury Treasury account') and names the row types (sweeps, dividend accruals) so the agent knows exactly what is returned. It also explicitly separates itself from mercury_list_transactions and mercury_list_credit_transactions.

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?

Provides an explicit USE WHEN block (auditing cash flows, reconciling yield accruals, Treasury-only ledger) and a DO NOT USE block that routes to the two competing siblings by name. The routing decision is fully determined without opening any other schema.

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