Wise MCP Server

Everything, in one currency

get_total_funds

Read-onlyIdempotent

Calculates total funds across Wise balances in a chosen currency, including total worth, available cash, and overdraft, so you can assess overall liquidity.

Instructions

Every balance added up in one currency: total worth, available, cash, and any overdraft.

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": {
      "currency": "<currency>"
    },
    "name": "get_total_funds"
  }
}

Input Schema

Name	Required	Description	Default
`profile`	No	The Wise profile id to act for. Defaults to WISE_PROFILE_ID, else the only business profile. See list_profiles.
`currency`	Yes	The currency to total in, such as EUR.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Nov 7, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds real value by enumerating the returned figures, which matters since there is no output schema, but it is silent on conversion mechanics — which FX rate is applied, whether pending items or fees are counted — the main behavioral unknown for an aggregation across currencies.

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?

A single front-loaded sentence with zero filler that leads with the aggregate scope and then the returned fields. It is appropriately short for a two-parameter read tool.

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?

With no output schema, listing the components (total worth, available, cash, overdraft) is the right move and largely fills the gap. What remains missing for a cross-currency total is how conversion is handled and whether the figure reflects only settled funds — enough of a gap to cap the score at 3.

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% for both parameters, including the profile defaulting rules and the three-letter currency pattern, so the schema does the heavy lifting. The description only reinforces 'in one currency' and says nothing about the profile parameter beyond what the schema already provides; baseline 3 applies.

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?

The description states a specific verb-like operation ('Every balance added up in one currency') plus the resulting metrics (total worth, available, cash, overdraft). This clearly separates it from the per-balance siblings get_balance/list_balances, though it never names them explicitly.

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?

Usage is only implied: an agent can infer this is the aggregate view versus the per-balance tools, but there is no explicit 'use this when you need a single-currency net position; use list_balances for per-account detail'. No prerequisites or exclusions are stated.

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