Skip to main content
Glama

Bernuvia

by com.bernuvia
OverviewDiscussionsAdmin

submit_signed_deposit

GASLESS DEPOSIT (phase 6): send back the quote and your EIP-3009 signature (ReceiveWithAuthorization) from deposit_data({ ordenId, una_sola_firma: true }) and Bernuvia sends fundFor to the escrow contract paying the gas. Before sending it verifies on the server that the quote is the one in force and was signed by Bernuvia, that your signature is from your linked wallet and that this wallet is the buyer, that the amount is exact, that validBefore is exactly the quote's expiry and that the order still has no deposit. Your wallet cannot have code. Sponsored gas limits per wallet and per day ([GAS_AGOTADO], [DEMASIADOS_FALLOS]). If somebody else sends that same authorization of yours first, it answers fondeada_por_otro. Prefixes: [FONDEO_APAGADO], [FONDEO_POR_TERCERO_NO_DISPONIBLE], [COTIZACION_INVALIDA], [AUTORIZACION_INVALIDA], [WALLET_DISTINTA], [IMPORTE_DISTINTO], [VENTANA_INVALIDA], [COTIZACION_CADUCADA], [AUTORIZACION_USADA], [COMPRADOR_CONTRATO], [RELAYER_OCUPADO], [NO_DIFUNDIDA], [REVERTIDA].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
firmaNoDEPRECATED alias of `signature`: it still works, but use `signature` (it will be removed in a future round, no date yet). Your EIP-712 signature (signTypedData) of autorizacion.typedData, made with your linked wallet: 0x + 130 hex. Wallets with code (contracts, EIP-7702) are not accepted on this route.
quoteNoThe `cotizacion` object returned by deposit_data({ ordenId, una_sola_firma: true }), AS IS (with issuedAt and signature). Bernuvia verifies it field by field and by its signature.
ordenIdNoDEPRECATED alias of `orderId`: it still works, but use `orderId` (it will be removed in a future round, no date yet). The ordenId (uuid) of the order, the same one from deposit_data.
orderIdNoThe ordenId (uuid) of the order, the same one from deposit_data.
signatureNoYour EIP-712 signature (signTypedData) of autorizacion.typedData, made with your linked wallet: 0x + 130 hex. Wallets with code (contracts, EIP-7702) are not accepted on this route.
cotizacionNoDEPRECATED alias of `quote`: it still works, but use `quote` (it will be removed in a future round, no date yet). The `cotizacion` object returned by deposit_data({ ordenId, una_sola_firma: true }), AS IS (with issuedAt and signature). Bernuvia verifies it field by field and by its signature.
validAfterYesautorizacion.typedData.message.validAfter, unchanged (epoch seconds).
validBeforeYesautorizacion.typedData.message.validBefore, unchanged: it is exactly the expiry of the quote.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
estadoYes"fondeada" (mined successfully), "enviada" (broadcast, receipt still pending), "fondeada_por_otro" (it was already on the chain) or "fondeada_por_otro_sin_finalizar" (seen but not finalized yet).
txHashNoHash of the transaction sent by Bernuvia. Absent if nothing was broadcast.
ordenIdYesThe uuid of the order in Bernuvia.
compraIdNoThe on-chain identifier (bytes32) of the purchase. Only when the send was made by Bernuvia.
siguientePasoYesWhat to do now, in one sentence.
gasPatrocinadoNoOnly when Bernuvia sent it: true, the gas was paid by Bernuvia (you do not spend POL).
enviadoPorBernuviaYestrue if the transaction was broadcast by Bernuvia; false if another send had already placed the deposit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changed
    • changedInput schema / properties / cotizacion / description
      Previous value: -"ALIAS RETIRADO de `quote`: sigue funcionando, pero usa `quote` (se quitará en una tanda futura, aún sin fecha). / DEPRECATED alias of `quote`. El objeto `cotizacion` que devolvió deposit_data({ ordenId, una_sola_firma: true }), TAL CUAL (con issuedAt y signature). Bernuvia lo verifica campo a campo y por su firma."New value: +"DEPRECATED alias of `quote`: it still works, but use `quote` (it will be removed in a future round, no date yet). The `cotizacion` object returned by deposit_data({ ordenId, una_sola_firma: true }), AS IS (with issuedAt and signature). Bernuvia verifies it field by field and by its signature."
    • changedInput schema / properties / firma / description
      Previous value: -"ALIAS RETIRADO de `signature`: sigue funcionando, pero usa `signature` (se quitará en una tanda futura, aún sin fecha). / DEPRECATED alias of `signature`. Tu firma EIP-712 (signTypedData) de autorizacion.typedData, hecha con tu wallet vinculada: 0x + 130 hex. Las wallets con código (contratos, EIP-7702) no se admiten en esta vía."New value: +"DEPRECATED alias of `signature`: it still works, but use `signature` (it will be removed in a future round, no date yet). Your EIP-712 signature (signTypedData) of autorizacion.typedData, made with your linked wallet: 0x + 130 hex. Wallets with code (contracts, EIP-7702) are not accepted on this route."
    • changedInput schema / properties / ordenId / description
      Previous value: -"ALIAS RETIRADO de `orderId`: sigue funcionando, pero usa `orderId` (se quitará en una tanda futura, aún sin fecha). / DEPRECATED alias of `orderId`. El ordenId (uuid) de la orden, el mismo de deposit_data."New value: +"DEPRECATED alias of `orderId`: it still works, but use `orderId` (it will be removed in a future round, no date yet). The ordenId (uuid) of the order, the same one from deposit_data."
    • changedInput schema / properties / orderId / description
      Previous value: -"El ordenId (uuid) de la orden, el mismo de deposit_data."New value: +"The ordenId (uuid) of the order, the same one from deposit_data."
    • changedInput schema / properties / quote / description
      Previous value: -"El objeto `cotizacion` que devolvió deposit_data({ ordenId, una_sola_firma: true }), TAL CUAL (con issuedAt y signature). Bernuvia lo verifica campo a campo y por su firma."New value: +"The `cotizacion` object returned by deposit_data({ ordenId, una_sola_firma: true }), AS IS (with issuedAt and signature). Bernuvia verifies it field by field and by its signature."
    • changedInput schema / properties / signature / description
      Previous value: -"Tu firma EIP-712 (signTypedData) de autorizacion.typedData, hecha con tu wallet vinculada: 0x + 130 hex. Las wallets con código (contratos, EIP-7702) no se admiten en esta vía."New value: +"Your EIP-712 signature (signTypedData) of autorizacion.typedData, made with your linked wallet: 0x + 130 hex. Wallets with code (contracts, EIP-7702) are not accepted on this route."
    • changedInput schema / properties / validAfter / description
      Previous value: -"autorizacion.typedData.message.validAfter, sin cambiarlo (segundos epoch)."New value: +"autorizacion.typedData.message.validAfter, unchanged (epoch seconds)."
    • changedInput schema / properties / validBefore / description
      Previous value: -"autorizacion.typedData.message.validBefore, sin cambiarlo: es exactamente el vencimiento de la cotización."New value: +"autorizacion.typedData.message.validBefore, unchanged: it is exactly the expiry of the quote."
    • changedOutput schema / properties / compraId / description
      Previous value: -"El identificador on-chain (bytes32) de la compra. Solo cuando el envío lo hizo Bernuvia."New value: +"The on-chain identifier (bytes32) of the purchase. Only when the send was made by Bernuvia."
    • changedOutput schema / properties / enviadoPorBernuvia / description
      Previous value: -"true si la transacción la difundió Bernuvia; false si el depósito ya lo había puesto otro envío."New value: +"true if the transaction was broadcast by Bernuvia; false if another send had already placed the deposit."
    • changedOutput schema / properties / estado / description
      Previous value: -"\"fondeada\" (minada con éxito), \"enviada\" (difundida, aún sin recibo), \"fondeada_por_otro\" (ya estaba en la cadena) o \"fondeada_por_otro_sin_finalizar\" (vista pero aún no finalizada)."New value: +"\"fondeada\" (mined successfully), \"enviada\" (broadcast, receipt still pending), \"fondeada_por_otro\" (it was already on the chain) or \"fondeada_por_otro_sin_finalizar\" (seen but not finalized yet)."
    • changedOutput schema / properties / gasPatrocinado / description
      Previous value: -"Solo cuando envió Bernuvia: true, el gas lo pagó ella (tú no gastas POL)."New value: +"Only when Bernuvia sent it: true, the gas was paid by Bernuvia (you do not spend POL)."
    • changedOutput schema / properties / ordenId / description
      Previous value: -"El uuid de la orden en Bernuvia."New value: +"The uuid of the order in Bernuvia."
    • changedOutput schema / properties / siguientePaso / description
      Previous value: -"Qué hacer ahora, en una frase."New value: +"What to do now, in one sentence."
    • changedOutput schema / properties / txHash / description
      Previous value: -"Hash de la transacción enviada por Bernuvia. Ausente si no se difundió nada."New value: +"Hash of the transaction sent by Bernuvia. Absent if nothing was broadcast."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden and does so admirably. It discloses the core side effect (Bernuvia sends fundFor to escrow paying gas), server-side checks (quote valid and signed by Bernuvia, signature from linked wallet, wallet is buyer, amount exact, validBefore equals quote expiry, order has no deposit), restrictions (wallet cannot have code), gas limits, and race-condition behavior (fondeada_por_otro). It also lists all error prefixes, providing complete failure-mode visibility.

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?

The description is long but information-dense; every sentence contributes operational detail. It is front-loaded with the core purpose ('GASLESS DEPOSIT (phase 6):') before diving into verification steps and error codes. The single-paragraph structure is slightly overwhelming due to the exhaustive prefix list, but this is acceptable given the tool's complexity.

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?

The description is complete for an agent to invoke the tool correctly: it explains the required inputs (quote and signature from deposit_data), the server-side validation that gates success, the gas sponsorship limits, the race-condition outcome, and all possible failure codes. Since an output schema exists (context signal), the description does not need to detail return values. No important behavioral aspect is left unstated.

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 100% and parameter descriptions already detail provenance and constraints (e.g., quote AS IS from deposit_data, validBefore exactly quote expiry). The description adds value by framing these parameters in the integrated workflow and highlighting verification rules such as 'validBefore is exactly the quote's expiry' and 'your signature is from your linked wallet and that this wallet is the buyer.' It also introduces EIP-3009 terminology, which the schema does not explicitly mention.

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 description opens with a specific verb and resource: 'GASLESS DEPOSIT (phase 6): send back the quote and your EIP-3009 signature... and Bernuvia sends fundFor to the escrow contract paying the gas.' This clearly distinguishes it from siblings like deposit_data (which prepares data) and cancel_deposit_authorization (which cancels). It names the exact workflow step and the resource acted upon.

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?

The description explicitly references the prerequisite: 'from deposit_data({ ordenId, una_sola_firma: true })', implying this tool is used after obtaining quote and signature from deposit_data. It also lists server-side verifications that must hold for success, giving contextual usage. However, it does not explicitly name alternatives or state when not to use it (e.g., 'use check_before_submit first'), though these are partially implied by the error prefixes.

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

All Bernuvia 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