Skip to main content
Glama
Sign In

Netfluid

by io.netfluid.mcp
OverviewDiscussionsAdmin

paywall__customer_netfluid_fund_options

Returns ALL funding options via the Netfluid wallet. This is a comprehensive list for all Netfluid funding options that include:

  1. Netfluid wallet addresses for Netfluid to Netfluid payments, sender can use any currency;

  2. Electronic Banks Transfers to registered Netfluid Bank Accounts in multiple countries, including South Africa;

  3. Pay@ Online or at till point of most retailers in South Africa and Botswana;

  4. Payshap instant, low-cost bank to bank transfers in South Africa;

  5. Virtual Banks Accounts (fiat on-ramps) accepting instant fiat payments in Europe and the USA and converting the funds to USDC/USDt use wallet_stablecoin_transfer to cash-out to ZAR;

  6. Blockchain wallets that accept instant USDC/USDt transfers use wallet_stablecoin_transfer to cash-out to ZAR;

  7. Tokenised Visa/Mastercards charged in ZAR;

  8. Netfluid vouchers, simple digital vouchers issued by Netfluid wallets;

  9. OTT vouchers, available for purchase in most retailers, online or at local Spaza shops in South Africa. @param wallet_fk: The Netfluid wallet_fk @param pin: The Netfluid wallet PIN @param account_fk: The Netfluid account_fk (not account address but the database account_fk), if set to 0, we'll use the first available account

@return: a json object, containing the results in the "values" object

Input Schema

NameRequiredDescriptionDefault
pinYes
wallet_fkYes
account_fkNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "type": "object"
-}New value: +null
  2. Added

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that a wallet PIN is required (an auth/sensitivity signal) and describes the return as a JSON object with a 'values' key, but it does not state whether the call is read-only, whether it moves funds, or any rate/cost characteristics. Adequate but incomplete given zero annotation coverage.

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?

Purpose is front-loaded in the first sentence, which is good, but the bulk is a sprawling nine-item enumeration with run-on phrasing (items 5 and 6 splice the cash-out instruction into the list). Much of the list is arguably helpful, yet it is not tightly structured.

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?

For a listing tool with no annotations and no output schema, the description is fairly complete: it explains all params, the default behavior of account_fk, and the shape of the return ('values' object). The main remaining gap is the absence of any safety/read-only characterization, which the missing annotations leave unaddressed.

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 0%, so the description must compensate, and it does: it documents all three parameters and adds real meaning beyond the schema, notably that account_fk is a database key (not an address) and that 0 selects the first available account. This is genuinely useful semantics; only the trivial pin/wallet_fk entries add little.

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?

States a specific verb and resource ('Returns ALL funding options via the Netfluid wallet') and enumerates the option types, which conveys the breadth of the resource. The 'ALL/comprehensive' framing implicitly distinguishes it from the narrower siblings (customer_netfluid_fund_blockchain, customer_netfluid_fund_sepa_and_ach, fund_payat, fund_payshap), though it never names those siblings directly as alternatives.

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 implied: call this to enumerate every funding path. It also routes the agent to wallet_stablecoin_transfer for cashing out to ZAR within items 5 and 6, which is concrete guidance. However, it never states when to prefer this over the more targeted fund_* siblings, so the when-to-use vs alternatives guidance is only partial.

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

All Netfluid toolsInspect
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