Skip to main content
Glama
Sign In

Netfluid

by io.netfluid.mcp
OverviewDiscussionsAdmin

paywall__customer_link_wallet_account

Links a customer_id with a netfluid wallet_fk and account_fk. This tool will overwrite the system Netfluid wallet and PIN auto-created for each subscription client. Always confirm before execution. This wallet will be used to pay for subscriptions. @param customer_id: The customer's database id @param wallet_fk: The Netfluid wallet_fk to link @param account_fk: The Netfluid account_fk to link @param encrypted_wallet_pin: For internal use, submit as a blank string @return: a json object, in the "values" object

Input Schema

NameRequiredDescriptionDefault
wallet_fkYes
account_fkYes
customer_idYes
encrypted_wallet_pinNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "type": "object"
-}New value: +null
  2. Changed4 schema fields changed
    • addedInput schema / properties / encrypted_wallet_pin / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / encrypted_wallet_pin / default
      Added value: +""
    • removedInput schema / properties / encrypted_wallet_pin / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "customer_id",
-  "wallet_fk",
-  "account_fk",
-  "encrypted_wallet_pin"
-]New value: +[
+  "customer_id",
+  "wallet_fk",
+  "account_fk"
+]
  3. Changed2 schema fields changed
    • addedInput schema / properties / encrypted_wallet_pin
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "customer_id",
-  "wallet_fk",
-  "account_fk"
-]New value: +[
+  "customer_id",
+  "wallet_fk",
+  "account_fk",
+  "encrypted_wallet_pin"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / account_fk / type
      Previous value: -"string"New value: +"integer"
  5. Added

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden and does disclose the key destructive trait: it overwrites the auto-created Netfluid wallet and PIN, and it demands confirmation before execution. It stops short of stating permission/auth requirements, reversibility, or what happens to the pre-existing PIN.

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?

Purpose and the overwrite warning are front-loaded in the first two sentences, which is exactly the right order for a destructive operation. The trailing JSDoc-style @param/@return block is boilerplate and mildly redundant, but each line still carries some information.

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?

No output schema exists, and the description at least signals the return shape ('a json object, in the "values" object'), though vaguely. For a 4-parameter, unannotated mutation tool it covers the essential risk (data overwrite + confirmation) but omits failure behavior and permission requirements.

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 documents all four parameters including the non-obvious one ('encrypted_wallet_pin: For internal use, submit as a blank string'). The remaining three are near-restatements of the field names, which limits added meaning but still covers the set.

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 ('Links a customer_id with a netfluid wallet_fk and account_fk') and immediately explains the consequence ('overwrite the system Netfluid wallet and PIN auto-created for each subscription client'). It does not name the read counterpart (paywall__customer_get_linked_wallet_account) or any alternative, so sibling differentiation is left to inference.

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?

Provides one operational guideline ('Always confirm before execution') and implies the context of use ('This wallet will be used to pay for subscriptions'), but never states when to choose this tool over alternatives such as payment_wallet_set or the wallet-creation flows. Usage is implied rather than prescribed.

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