Skip to main content
Glama

netfluid__fund_card_link

Mints a single-use hosted card-payment link (CARD_PAY). The wallet token never appears in any customer-facing URL.

Mints a single-use payment link for a wallet account and returns it in values.link (https://cards.netfluid.app/{session_id}). Hand the link to the payer: it serves the hosted payment page, takes new-card payments (3D Secure) and, with saved='1', saved-card payments, and becomes invalid once the payment completes. POST only — the API refuses GET (405) so the wallet token can never land in access logs; this tool posts a JSON body. The account must be a ZAR account and the wallet must be KYC verified. Idempotency: a non-empty reference maps to one open payment — retrying the same reference returns the same live link (values.reused=1); once the payment is terminal (paid/failed/expired) the reference frees for a new payment. values.expires_at is the unix time the link dies (24h default). @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 @param account_fk: The account_fk (this is a database ID (int) not an account address (str) and may not be 0) The account_fk provided by /wallet/accounts_list (ZAR accounts only) @param amount: The fixed charge amount in the account currency (ZAR), between 10 and 100000. On top of this amount a fee with be charged equal to 3.5% for fees and insurance plus South African VAT of 15% (only on the fee portion). @param saved: '1' = owner-payer mode: the wallet's saved cards are offered on the page (tokenised recharge). Default '0' = link-payer mode: new card with 3D Secure. @param description: Shown to the payer on the hosted page (max 100 characters) @param reference: The caller's own reference; doubles as the idempotency key (max 100 characters) @param keep_card: '1' keeps a newly tokenised card after the payment. Default '0' — anonymous cards are removed after a successful charge. @param return_url: http/https URL the payer is returned to after the payment (max 500 characters, validated) @param webhook_url: https URL on a public host that receives a signed webhook when the payment completes (max 500 characters, validated) @param webhook_secret: HMAC-SHA256 signing secret for the webhook; generated when omitted (max 64 characters) @param ttl_s: Link lifetime in seconds, default 86400, clamped to 300-86400

@return: a json object

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": {
      "api_key": "<api_key>",
      "token": "<token>",
      "wallet_fk": "<wallet_fk>",
      "account_fk": "<account_fk>",
      "amount": "<amount>"
    },
    "name": "netfluid__fund_card_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
savedNo
tokenYes
ttl_sNo
amountYes
api_keyYes
keep_cardNo
referenceNo
wallet_fkYes
account_fkYes
return_urlNo
descriptionNo
webhook_urlNo
webhook_secretNo

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

A4.7/5.0
Behavior5/5

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

With no annotations supplied, the description carries the whole burden and does so: POST-only with the API returning 405 on GET, the wallet token never appearing in customer-facing URLs or access logs, the link becoming invalid once the payment completes, the 24h default lifetime with ttl_s clamped to 300-86400, and the 3.5% + 15% VAT fee added on top of amount. Idempotency semantics (values.reused=1 on retry, reference freed on terminal state) are spelled out.

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?

It is long, but the critical constraints (single-use, POST-only, ZAR/KYC preconditions, idempotency) are front-loaded ahead of the @param block. Minor redundancy remains: the first paragraph and the following paragraph both restate that the link is single-use and hosted.

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

Completeness5/5

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

For a 13-parameter mutation tool with no annotations and no output schema, nothing material is missing. The @return block names values.link, values.reused, and values.expires_at, so the caller knows what comes back and how to hand the link to the payer.

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

Parameters5/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: every one of the 13 parameters is documented with type, range, default, or format. Notably account_fk is flagged as a database int, not an account address and not 0, amount is bounded 10-100000, return_url/webhook_url must be validated http(s), webhook_secret is HMAC-SHA256 and generated when omitted, and the *_url/description/reference length caps are given.

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?

The opening sentence names a specific verb and artifact: mints a single-use hosted card-payment link (CARD_PAY) returned at https://cards.netfluid.app/{session_id}. That is clearly distinguishable from the quote/recharge siblings and from paywall__payment_card_link, and no schema needs to be opened to know what it produces.

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

Usage Guidelines4/5

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

It states the preconditions (account must be ZAR, wallet must be KYC verified) and explains the two operating modes: saved='1' offers saved cards, default '0' takes a new 3D Secure card. It also explains when to reuse a reference versus when the reference frees up. It never names an alternative tool or an explicit when-not-to-use, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources