Wise MCP Server

What a payment needs

get_transfer_requirements

Read-onlyIdempotent

Lists the fields and accepted reasons Wise requires to set up a payment, then prices it without sending money. Use it to check requirements before creating a transfer.

Instructions

What Wise needs to set up a particular payment beyond the amount: the message for the recipient, a reason for sending, an invoice number, the source of funds. Lists each field, whether this payment requires it, and the reasons Wise accepts. Prices the payment to ask, which sends nothing.

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": "get_transfer_requirements"
  }
}

Input Schema

Name	Required	Description
`amount`	Yes	The amount.
`reason`	No	The reason for sending, as Wise's key, such as verification.transfers.purpose.pay.bills. get_transfer_requirements lists the ones a route accepts.
`profile`	No	The Wise profile id to act for. Defaults to WISE_PROFILE_ID, else the only business profile. See list_profiles.
`amount_is`	No	`target` (default): the recipient receives exactly this, as on an invoice. `source`: this is what leaves the account.
`reference`	No	The message for the recipient: what they see on their bank statement, such as an invoice number. Wise shortens the limit on some routes.
`recipient_id`	Yes	A saved recipient's id.
`reason_detail`	No	A more specific reason, on routes that ask for one (CNY, for example).
`invoice_number`	No	The invoice number, on routes that ask for one (INR, for example).
`source_currency`	Yes	The currency paid from.
`source_of_funds`	No	Where the money comes from, on routes and amounts that ask (large USD payments, for example).
`target_currency`	No	The currency they receive. Defaults to the recipient's currency.
`transfer_nature`	No	Required 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_other`	No	The source of funds in words, when source_of_funds is other.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Nov 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description's 'which sends nothing' reinforces rather than adds. It does add genuinely new behavioral context by describing the response shape ('lists each field, whether this payment requires it, and the reasons Wise accepts'), which annotations cannot convey, but says nothing about rate limits, caching, or whether the quote expires.

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?

Two sentences with no filler, and the core purpose is front-loaded. The closing clause 'Prices the payment to ask, which sends nothing' is slightly compressed/awkward and could be stated more plainly, but overall it earns its space.

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

Completeness4/5

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

A 13-parameter tool with no output schema, so the description carries some return-value burden, and it does describe the response as a per-field list with requirements and accepted reasons. Missing is any mention that the result depends on recipient/currency/amount combination and may need re-checking when those change.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every one of the 13 parameters in detail, including which are route-conditional. The description's field list (message, reason, invoice number, source of funds) merely restates schema content in plain language and covers neither amount_is nor the currency parameters. Baseline 3 is the right level.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb ('lists') and resource ('what a payment needs') with a concrete enumeration of the fields involved (recipient message, reason, invoice number, source of funds). It implicitly separates itself from create_transfer via 'which sends nothing', but never mentions its close sibling get_recipient_requirements, so the boundary with that tool is left for the agent to infer.

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

Usage Guidelines3/5

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

'Prices the payment to ask, which sends nothing' implies this is a pre-flight check to run before create_transfer, but the description never states that ordering explicitly and gives no exclusions or alternatives. The agent must infer when this is the right tool versus create_quote or get_recipient_requirements.

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