Skip to main content
Glama
Wise MCP Server

Wise MCP Server

by thenavidm

Set up a payment

create_transfer
Destructive

Sets up an unpaid Wise payment to a saved recipient: validates route fields, prices the transfer, and leaves it awaiting manual payment in Wise. Uses payment_id to prevent duplicates.

Instructions

Set up a payment to a saved recipient, ready for the person to pay in Wise. This prices it, checks with Wise that every field the route needs is there (a reason for sending, an invoice number, the source of funds), and creates the transfer; it does not pay it. It waits as incoming_payment_waiting until paid in the Wise app or website, and Wise cancels it if unpaid for 14 days. A person approves every one. Pass payment_id (an email's message id, an invoice number) so asking twice never sets it up twice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipient_id": "<recipient_id>",
      "source_currency": "<source_currency>",
      "amount": "<amount>"
    },
    "name": "create_transfer"
  }
}

Input Schema

NameRequiredDescriptionDefault
amountYesThe amount.
pay_inNoHow it will be paid: BALANCE from a Wise balance, BANK_TRANSFER from a bank. Changes the fee shown.
reasonNoThe reason for sending, as Wise's key, such as verification.transfers.purpose.pay.bills. get_transfer_requirements lists the ones a route accepts.
confirmNoSet true only when the user asked for exactly this action.
profileNoThe Wise profile id to act for. Defaults to WISE_PROFILE_ID, else the only business profile. See list_profiles.
batch_idNoAdd it to this open batch, from create_batch, so a run of payments is paid in Wise in one go.
amount_isNo`target` (default): the recipient receives exactly this, as on an invoice. `source`: this is what leaves the account.
referenceNoThe message for the recipient: what they see on their bank statement, such as an invoice number. Wise shortens the limit on some routes.
payment_idNoA stable id for this payment request, such as the email's message id. The same id never creates a second transfer.
recipient_idYesA saved recipient's id, from find_recipient or list_recipients.
reason_detailNoA more specific reason, on routes that ask for one (CNY, for example).
invoice_numberNoThe invoice number, on routes that ask for one (INR, for example).
source_currencyYesThe currency paid from, such as EUR.
source_of_fundsNoWhere the money comes from, on routes and amounts that ask (large USD payments, for example).
target_currencyNoThe currency they receive. Defaults to the recipient's currency.
transfer_natureNoRequired for payments to or from BRL, such as MOVING_MONEY_BETWEEN_OWN_ACCOUNTS. get_transfer_requirements lists the values. Wise blocks and refunds a BRL payment without it.
source_of_funds_otherNoThe source of funds in words, when source_of_funds is other.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations it discloses the full lifecycle: it prices the transfer, validates route-specific required fields, creates but does not pay, parks at incoming_payment_waiting, is cancelled after 14 days unpaid, and requires human approval. That is exactly the operational context an agent needs for a destructive/open-world mutation. Note the mild tension with idempotentHint=false: idempotency here is conditional on the caller supplying payment_id, not a contradiction.

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?

Four sentences, front-loaded with the core action and the "does not pay it" qualifier, with no filler. The second sentence is a long triple-clause run-on that could be split for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter mutation with no output schema, the description covers lifecycle and validation well but leaves two gaps: what the call returns (a transfer id to later poll via get_transfer) and the meaning of the `confirm` safety gate, which the schema mentions only in passing. An agent can call it, but cannot fully plan the follow-up without that.

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, but the description adds framing the schema does not: certain fields (reason, invoice number, source of funds) are route-dependent prerequisites that Wise checks, and payment_id doubles as the dedupe key. It does not explain the `confirm` gate, which is a behavioral parameter rather than a semantic one.

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?

"Set up a payment to a saved recipient... it does not pay it" names a specific verb and resource and immediately draws the boundary between creating a transfer and paying it. The distinction from create_batch (batch_id) and create_quote (pricing is done internally here) is inferable without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the context of use (a saved recipient, transfer left for the person to pay in Wise) and the key caller discipline: pass payment_id so retries don't duplicate. It stops short of naming sibling tools to use instead when a recipient doesn't exist yet (find_recipient/create_recipient are only referenced inside the schema).

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