Skip to main content
Glama
Sign In

Netfluid

by io.netfluid.mcp
OverviewDiscussionsAdmin

netfluid__payment_wallet_signup

Creates a payment wallet. Payment wallets are a form of sub-wallet of which the sponsor controls access to the Secret,PIN and recovery keywords. A payment wallet cannot login to the portal and is therefore only accessible to the sponsor via the api or this mcp. In order for this wallet to exists, it needs to be created by a human KYCed wallet. Once created this wallet will be fully enabled to perform any transaction any other wallet is capable of. Including access to virtual bank accounts in Europe and the USA as a funding source. The wallet is automatically minted with a Solana Blockchain wallet. The sponsor would typically only need to save the wallet_fk and PIN of the new wallet in their storage in order to make use of it later. The secret is optional purely to maintain backward compatibility, if not provided the system will generate default values. We suggest you use the mobile and email of the sponsor where available, in order to get access to recovery methods. The human accepts all legal responsibility for this payment wallet. Process can take up to 30 seconds. @param secret: A secret, minimum 8 characters, must be unique system-wide. This is typically the username, but private. Suggestion: Generate 3 natural language words, concatenated, or prompt the human for 3 words. @param pin: The 5 digit PIN associated with the new wallet. Can be any random 5 numbers. @param email: The agents email address, if not available use a blank string. @param mobile: The human's mobile phone number, in e164 format, e.g. 27821234567 (no +). if not available use a blank string. @param currency_fk: The currency of the first account, use 7 (ZAR) for everyone else use 3 (USD) @param sponsor_wallet_fk: The sponsor's wallet_fk, this wallet_fk must be KYCed if not the new wallet will also not be KYCed @param sponsor_wallet_pin: The sponsor's 5-digit PIN

@return: a json object

Input Schema

NameRequiredDescriptionDefault
pinYes
emailNo27012345678@netfluid.ltd
mobileNo27012345678
secretNo9e85cf58-8c45-4cc4-b1e8-aea6054d6ee4
currency_fkNo
sponsor_wallet_fkYes
sponsor_wallet_pinYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • changedInput schema / properties / secret / default
      Previous value: -"0611bcc5-fc8c-4d2b-a823-bc4c3c34a241"New value: +"9e85cf58-8c45-4cc4-b1e8-aea6054d6ee4"
  3. Changed1 schema field changed
    • changedInput schema / properties / secret / default
      Previous value: -"81fc6380-782c-4bde-8d0e-4c26eebca55b"New value: +"0611bcc5-fc8c-4d2b-a823-bc4c3c34a241"
  4. Changed1 schema field changed
    • changedInput schema / properties / secret / default
      Previous value: -"56a6d06e-4448-4c11-8eef-805be38d5a50"New value: +"81fc6380-782c-4bde-8d0e-4c26eebca55b"
  5. Added

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does it well: it discloses a ~30 second processing time, automatic Solana wallet minting, the KYC propagation behavior of the sponsor wallet, and that the human sponsor accepts legal responsibility. The main gap is the vague '@return: a json object' with no indication of what the response contains.

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 first line is front-loaded, but the body sprawls across many sentences, several of which are conceptual filler (portal-login behavior, backward-compatibility rationale, legal-responsibility statement). The @param/@return structure helps, yet the same ideas could be conveyed in noticeably less text.

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 7-parameter, no-output-schema, no-annotation mutation tool, the definition covers prerequisites, side effects, timing, and per-parameter guidance well. It falls short on the return value (only 'a json object') and on error/failure behavior, which an agent invoking a signup with KYC dependencies would benefit from knowing.

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% across 7 parameters, and the @param block compensates thoroughly: e164 format for mobile (no '+'), 5-digit PIN constraint, secret uniqueness/min-length with a concrete generation suggestion, and specific currency_fk values (7 for ZAR, 3 for USD). Minor inconsistency: it says to use a blank string for email/mobile, while the schema defaults are populated non-blank values.

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?

'Creates a payment wallet' states a specific verb and resource, then explains exactly what that artifact is (a sponsor-controlled sub-wallet, auto-minted with a Solana wallet, no portal login). The purpose is unmistakable and clearly distinct from operational siblings like payment_wallet_set, even though no sibling is named 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?

It gives a real prerequisite ('needs to be created by a human KYCed wallet', and the sponsor_wallet_fk must be KYCed or the result won't be), which is useful context. But it never states when to choose this tool versus alternatives such as payment_wallet_set, nor any when-not-to-use condition, so usage is only implied.

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