highnote-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HIGHNOTE_API_KEY | Yes | API key from the Highnote dashboard | |
| HIGHNOTE_CURRENCY | No | Currency for amounts | USD |
| HIGHNOTE_READ_ONLY | No | When `true`, hides every write tool | false |
| HIGHNOTE_ALLOW_LIVE | No | Must be `true` to use the `live` environment | |
| HIGHNOTE_ENVIRONMENT | No | Environment to use: `test` or `live` | test |
| HIGHNOTE_MAX_TRANSACTION_LIMIT | No | Largest per-transaction limit, in minor units (default $500.00) | 50000 |
| HIGHNOTE_MAX_CARD_LIFETIME_DAYS | No | Longest card lifetime in days | 365 |
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_payment_cardB | Look up a payment card: status, last 4, network, form factor and expiration. Never returns the card number. |
| get_financial_accountA | Look up a financial account with its ledger balances and the payment cards issued on it. |
| list_account_activityA | List recent activity on a financial account, newest first: authorizations and clearings with merchant, amount and card. |
| simulate_authorizationA | Simulate a card authorization in the Highnote test environment, e.g. to check that a card's spend rules decline what they should. |
| issue_virtual_cardA | Issue a new active virtual card on a financial account, e.g. one card per agent, workflow or vendor. Pair it with set_transaction_limit and restrict_merchant_categories before using it. |
| set_transaction_limitA | Create an amount-limit spend rule and attach it to a card, so any single authorization above the limit is declined. Limits above 500.00 USD are refused by this server. |
| restrict_merchant_categoriesA | Create a merchant category spend rule (allow list or block list, by Highnote MerchantCategory name or MCC) and attach it to a card. |
| suspend_payment_cardA | Temporarily suspend a card so new authorizations are declined. Reversible. |
| close_payment_cardA | Permanently close a card, e.g. when the agent's workflow is finished. Cannot be undone. |
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 9 tools
Each tool targets a distinct resource+action pair: authorization simulation, card/account lookups, activity listing, issuance, two clearly-scoped spend-rule types, and two distinct card-state operations. The suspend vs close overlap is disambiguated by explicit 'reversible'/'cannot be undone' wording, and the amount-limit vs merchant-category rules are clearly separated.
All nine tools follow a consistent snake_case verb_noun pattern (get_*, list_*, issue_*, set_*, restrict_*, suspend_*, close_*, simulate_*). Verb choices are meaningful and the singular/plural noun usage is coherent.
Nine tools is well-scoped for a card-issuance and spend-control domain, and every tool earns its place by covering a distinct operation. No filler or trivially duplicative tools.
Core lifecycle (issue, look up, limit, simulate, suspend, close) is covered, but suspend is described as reversible with no resume/unsuspend tool, and spend rules can be created but not listed, updated, or removed. These dead ends will block agents that need to reverse or audit their changes.