Skip to main content
Glama

N9T2 XRPL Agent Gateway

by com.n9t2
OverviewDiscussionsAdmin

n9t2_xrpl_submit_transaction

Destructive

Submit one already-signed XRPL transaction to the network. tx_blob must be the complete signed transaction encoded as hexadecimal; obtain it from the caller's local signing step, normally after n9t2_xrpl_prepare_transaction. This action mutates ledger state when the transaction is accepted into the XRPL network and must never receive private keys, seeds, or wallet secrets. fail_hard forwards rippled's option and defaults to false; when true, a transaction that fails locally is not retried or relayed. The result preserves the raw submit response, including engine_result and engine_result_message and, when returned, accepted, queued, validated, and transaction data. Submission is tentative; use n9t2_xrpl_get_transaction with the returned transaction hash to confirm validated-ledger inclusion. Invalid hexadecimal or XRPL-rejected blobs return an error.

Input Schema

NameRequiredDescriptionDefault
tx_blobYesComplete signed XRPL transaction encoded as hexadecimal. The caller must sign locally before sending it to N9T2.
fail_hardNoForward rippled's fail_hard option. When true, a transaction that fails locally is not retried or relayed to other servers. Defaults to false.

Output Schema

NameRequiredDescriptionDefault
resultYes
serviceYes
operationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / fail_hard / description
      Previous value: -"Whether the XRPL submission should use fail_hard=true."New value: +"Forward rippled's fail_hard option. When true, a transaction that fails locally is not retried or relayed to other servers. Defaults to false."
    • changedInput schema / properties / tx_blob / description
      Previous value: -"Already-signed XRPL transaction blob encoded as hexadecimal. The caller signs locally before submission."New value: +"Complete signed XRPL transaction encoded as hexadecimal. The caller must sign locally before sending it to N9T2."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$defs": {
+    "_XRPLSubmitResult": {
+      "properties": {
+        "custody": {
+          "description": "Non-custodial confirmation. N9T2 never receives, stores, or uses the caller's private keys, seeds, or wallet secrets.",
+          "title": "Custody",
+          "type": "string"
+        },
+        "signed_blob_submitted": {
+          "description": "True when the validated hexadecimal tx_blob was forwarded to the XRPL submit method.",
+          "title": "Signed Blob Submitted",
+          "type": "boolean"
+        },
+        "submission": {
+          "additionalProperties": true,
+          "description": "Raw XRPL rippled submit response. Inspect engine_result and engine_result_message for the tentative submission outcome; the response may also include accepted, queued, validated, tx_json, and other XRPL submission fields.",
+          "title": "Submission",
+          "type": "object"
+        }
+      },
+      "required": [
+        "submission",
+        "custody",
+        "signed_blob_submitted"
+      ],
+      "title": "_XRPLSubmitResult",
+      "type": "object"
+    }
+  },
+  "properties": {
+    "operation": {
+      "title": "Operation",
+      "type": "string"
+    },
+    "result": {
+      "$ref": "#/$defs/_XRPLSubmitResult"
+    },
+    "service": {
+      "title": "Service",
+      "type": "string"
+    }
+  },
+  "required": [
+    "service",
+    "operation",
+    "result"
+  ],
+  "title": "_XRPLSubmitOutput",
+  "type": "object"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / fail_hard / description
      Added value: +"Whether the XRPL submission should use fail_hard=true."
    • addedInput schema / properties / tx_blob / description
      Added value: +"Already-signed XRPL transaction blob encoded as hexadecimal. The caller signs locally before submission."
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real context: it mutates ledger state only when accepted, submission is tentative, secrets must never be passed, and invalid/rejected blobs error. It does not cover rate limits or whether retries are safe for the caller, which keeps it short of a 5.

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?

Dense but front-loaded, opening with the core action before prerequisites, safety, parameter notes, and confirmation flow. Every sentence carries information, though the result-field enumeration is somewhat long for prose that an output schema also covers.

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 destructive, open-world submission tool it covers prerequisites (local signing), the mutation semantics, safety constraints, parameter behavior, tentative-result caveats, error behavior, and the follow-up verification step. Nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3; the description goes beyond it by explaining what tx_blob must be (complete signed transaction in hex, produced by local signing) and by expanding fail_hard's effect (no local retry or relay). The tx_blob wording largely mirrors the schema, so it is not a full 5.

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?

States a specific verb and resource ('Submit one already-signed XRPL transaction') and pins the scope to already-signed blobs, distinguishing it from prepare_transaction (signing pipeline) and get_transaction (confirmation). An agent can select it without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: obtain the blob from the local signing step 'normally after n9t2_xrpl_prepare_transaction', and confirm inclusion with n9t2_xrpl_get_transaction using the returned hash. Names both the predecessor and successor tools and the condition for each.

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

All N9T2 XRPL Agent Gateway 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