Mercury Enhanced MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MERCURY_API_TOKEN | Yes | Your Mercury personal API token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_accountsA | Retrieve a paginated list of all Mercury accounts for the organization. Returns accountNumber, availableBalance, currentBalance, name, nickname, routingNumber, status (active/deleted/pending/archived), and type (mercury/external/recipient). Supports cursor-based pagination with start_after and end_before. |
| get_accountA | Retrieve details of a specific Mercury account by its account ID. Returns accountNumber, availableBalance, currentBalance, dashboardLink, legalBusinessName, name, nickname, routingNumber, status, and type. |
| get_account_cardsA | Retrieve all debit and credit cards associated with a specific Mercury account. Returns card details including card type, status, and cardholder information. |
| get_account_statementsA | Retrieve monthly statements for a specific Mercury account. Returns statement list with downloadUrl, startDate, endDate, endingBalance, accountNumber, and EIN. Note: treasury and credit accounts are NOT supported — use get_treasury_statements instead. Maximum date range via start/end parameters is 3 months. |
| get_transactionA | Retrieve details of a single Mercury transaction by its transaction ID. Returns id, accountId, amount, counterpartyName, createdAt, postedAt, status, kind, mercuryCategory, note, externalMemo, bankDescription, dashboardLink, and trackingNumber. |
| list_account_transactionsB | Retrieve a paginated list of transactions for a specific Mercury account. Supports filtering by date range, status, search term, and merchant category. Returns trimmed transaction objects: id, amount, counterpartyName, createdAt, postedAt, status, kind, mercuryCategory, note, externalMemo, bankDescription, dashboardLink. |
| list_transactionsB | Retrieve transactions across all accounts with advanced filtering. Supports createdAt date range (start/end), postedAt date range (postedStart/postedEnd), comma-separated status list, search term, comma-separated accountId list, mercuryCategory, and cursor-based pagination. Returns trimmed transaction objects. |
| get_organizationA | Retrieve information about the Mercury organization. Returns EIN, legal business name, list of DBAs (Doing Business As names with default flag), organization kind (personal/business), and organization UUID. |
| get_recipientsB | Retrieve a paginated list of all payment recipients. Returns recipient name, emails, defaultPaymentMethod (ach/check/domesticWire/internationalWire/realTimePayment), status (active/deleted), dateLastPaid, isBusiness, and routing information. |
| get_recipientB | Retrieve full details of a specific payment recipient by their ID. Returns name, nickname, emails, defaultPaymentMethod, status, dateLastPaid, isBusiness, and all routing details (ACH, domestic wire, international wire, RTP). |
| list_categoriesA | Retrieve all available custom expense categories for the organization. These are custom categories distinct from Mercury's built-in mercuryCategory classifications. Returns category IDs and names that can be used to filter transactions via the categoryId parameter. |
| list_creditA | Retrieve all credit accounts for the organization. Returns credit account details including available credit, balances, and account status. |
| get_treasury_accountsC | Retrieve all Mercury treasury accounts for the organization. Returns availableBalance, currentBalance, status (active/deleted/pending/archived), and monthly netReturns breakdown (dividends by security, Mercury fees, net return amount). |
| get_treasury_transactionsA | Retrieve paginated transactions for a specific Mercury treasury account. Returns amount, balance, canonicalDay, description, and transaction type (depositComplete, withdrawalPosted, interestPosted, dividendPosted, mercuryFeePosted, sweepInPosted, etc.). Note: uses integer cursor pagination, not UUID-based like other endpoints. |
| get_treasury_statementsA | Retrieve statements for a specific Mercury treasury account. Returns downloadUrl, periodStart, periodEnd, documentType, description, and creationDate. Filter by documentType: MonthlyStatement, TradeConfirmation, 1099, 1099R, 1042S, 5498, 5498ESA, 1099Q, FMV, SDIRA. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have distinct purposes, but list_transactions and list_account_transactions overlap significantly: both retrieve transactions, with list_transactions supporting accountId filtering that can achieve the same result as list_account_transactions. This could cause misselection when an agent wants transactions for a single account.
Names follow a consistent verb_noun pattern (e.g., get_, list_). Minor inconsistency: get_accounts exists alongside get_account, which is acceptable, but 'get_accounts' is a list operation while 'list_account_transactions' also lists, and some tools use 'get_' where 'list_' might be expected (e.g., get_recipients vs list_recipients would be more consistent).
15 tools is well-suited for a financial API covering accounts, transactions, recipients, treasury, and cards. Each tool appears to serve a distinct resource or operation without excessive redundancy.
The tool set covers key read operations across accounts, transactions, recipients, and treasury, including statements and cards. However, it lacks any write operations (e.g., create recipient, initiate payment), which may be intentional but leaves the surface incomplete for a full payment API.