Skip to main content
Glama

netfluid__bridge_off_ramp_sepa

Creates a blockchain (USDC) to FIAT off-ramp in Europe for SEPA supporting bank accounts. Confirm (yes/no) before executing

Creates a blockchain to FIAT off-ramp in Europe for SEPA supporting bank accounts. @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 account_fk: The account_fk (this is a database ID (int) not an account address (str) and may not be 0) The account_fk that will use the bridge @param account_owner: The owner of the recipient bank account @param iban: The recipient bank account IBAN @param iso3_country: The recipient bank account iso3 country code, examples BEL for Belgium @param iban_bic: The recipient bank account IBAN BIC. @param entity_type: The type of entity, possible values are "individual" or "business" @param address_line: The address of the recipient, street and must include a number @param address_city: The address of the recipient, city @param address_state: The address of the recipient, state @param address_zipcode: The address of the recipient, zip or postal code @param address_iso3_country: The address of the recipient, ISO3 country code @param alias: A descriptive name for this Bridge, can be anything, set by async default if none is provided. @param first_name: If type of entity is and "individual", provide the recipients first name @param last_name: If type of entity is an "individual", provide the recipients last name @param business_name: If type of entity is a "business", provide the business name, if not provided we will use the account_owner @param reference: The payment reference, displayed on the recipients bank statement.

@return: a json object

Input Schema

NameRequiredDescriptionDefault
ibanYes
aliasNo
tokenYes
api_keyYes
iban_bicYes
last_nameNo
referenceNo
wallet_fkYes
account_fkYes
first_nameNo
entity_typeYes
address_cityYes
address_lineYes
iso3_countryYes
account_ownerYes
address_stateYes
business_nameNo
address_zipcodeYes
address_iso3_countryYes

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

B3/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses that a yes/no confirmation precedes execution and that the result is 'a json object', but says nothing about permissions, idempotency, whether the transfer is irreversible, timing/settlement, or failure modes for a money-movement operation.

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, and a long @param block is justified by 19 undocumented parameters. However, the purpose sentence is duplicated verbatim at the top and again before the parameter list, and '@return: a json object' is filler. Functional but with avoidable redundancy.

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

Completeness3/5

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

With 19 parameters, 14 required, no annotations and no output schema, the description covers inputs reasonably well but leaves the outcome thin: no settlement timing, no error/limit behavior, and the return is described only as 'a json object'. An agent could call it, but not confidently predict what happens next.

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 largely does: every parameter is documented with real semantics beyond the schema — account_fk is a database int, not an address, and may not be 0; iso3_country shown as 'BEL'; entity_type values 'individual'/'business'; address_line must include a number; alias has an async default. Only the credential params (api_key, token) are near-restatements.

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 gives a specific verb, resource, corridor and scope: creating a USDC-to-FIAT off-ramp for SEPA/Europe bank accounts. The Europe/SEPA qualifier implicitly separates it from bridge_off_ramp_ach_wire, though the sibling is never named. Clear enough to select correctly, but not maximal.

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

Usage Guidelines2/5

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

Nothing states when to use this versus bridge_off_ramp_ach_wire, bridge_on_ramp, or the other bridge tools, and no prerequisites (KYC, funded wallet) are given. The only procedural note is 'Confirm (yes/no) before executing', which is a confirmation ritual rather than usage guidance.

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