Netfluid

netfluid__wallet_rba

Saves a Recipient Bank Account (RBA) for use on future withdrawals. Confirm (yes/no) before executing

Saves a Recipient Bank Account (RBA) for use on future withdrawals. @param api_key: The api key allocated to your application @param token: The wallet_api_token provided by /access/login @param wallet_fk: The wallet_fk provided by /access/login @param beneficiary: The beneficiary name @param bank: The bank's name @param iban: The account's IBAN/Account number @param swift: The account's swift routing code or branch code which ever is applicable @param email: The recipient's email address @param note: The note or recipient reference on the bank transfer @param address_street: The street address of the bank @param address_city: The city in which the bank is located @param address_zip: The postal code of the location of the bank, zip code or "None" @param countryISO2: The 2-digit ISO code of the country in which the bank is located, must match the content of the swift code

@return: a json object

Input Schema

Name	Required	Description	Default
`bank`	Yes
`iban`	Yes
`note`	No
`email`	Yes
`swift`	Yes
`token`	Yes
`api_key`	Yes
`wallet_fk`	Yes
`address_zip`	No
`beneficiary`	Yes
`countryISO2`	No
`address_city`	No
`address_street`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026
- changedOutput schema / (root)
```
Previous value: -{
-  "type": "object"
-}New value: +null
```
AddedJul 8, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It does add one real trait – the confirmation gate before execution – and clarifies the saved artifact persists for future withdrawals. However, it omits permissions, duplicate-handling, failure modes, and the fact that api_key/token must be valid before the call succeeds.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is duplicated verbatim at the top, and the description is written as JSDoc-style @param/@return tags rather than agent-facing prose. The parameter lines each earn their place, but the duplication and leaked doc-comment formatting hurt front-loading.

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?

Given no output schema, no annotations, and 13 parameters, the description is fairly complete – it covers purpose, the persistence intent, every parameter, and the confirmation requirement. It stops short of any error/permission context, which an agent calling a write tool would benefit from.

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 description coverage is 0%, so the description must compensate, and it does: all 13 parameters get meaningful semantics beyond type, notably IBAN format, swift as 'routing code or branch code', and the non-obvious constraint that countryISO2 'must match the content of the swift code'. It omits which fields are required vs. optional, which the schema supplies.

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 opening sentence states a clear verb+resource ('Saves a Recipient Bank Account (RBA)') plus the downstream purpose ('for use on future withdrawals'). It distinguishes the tool from siblings like netfluid__beneficiary_add and netfluid__wallet_rba_list by naming the RBA concept and persistence intent, though it never explicitly contrasts with those siblings.

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: 'for use on future withdrawals' and 'Confirm (yes/no) before executing' give a sense of context and a required confirmation step. There is no explicit when-to-use vs. when-not guidance and no named alternative for adding recipient accounts.

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

All Netfluid tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?