Skip to main content
Glama
Sign In

N9T2 XRPL Agent Gateway

by com.n9t2
OverviewDiscussionsAdmin

n9t2_xrpl_list_nft_offers

Read-onlyIdempotent

Read-only XRPL NFT marketplace-offer lookup for one NFTokenID. offer_type=buy retrieves native nft_buy_offers, sell retrieves nft_sell_offers, and both retrieves both sides; buy_marker and sell_marker paginate the two sides independently. Use ledger_hash or ledger_index to pin the lookup to a ledger, and limit to bound returned offers. Use this for marketplace offers on a specific NFT; use n9t2_xrpl_list_account_nfts for owned-NFT inventory and n9t2_xrpl_list_account_objects with object_type='nft_offer' when raw NFTokenOffer ledger entries are required.

Input Schema

NameRequiredDescriptionDefault
limitNoOptional maximum number of NFT offers to return.
nft_idYesCanonical NFTokenID identifying the NFT whose marketplace offers should be retrieved.
buy_markerNoPagination marker for the NFT buy-offer side.
offer_typeNoNFT marketplace offer side to retrieve: buy, sell, or both. Default is both.both
ledger_hashNoOptional ledger hash used to pin the NFT-offer lookup.
sell_markerNoPagination marker for the NFT sell-offer side.
ledger_indexNoOptional validated ledger index or selector.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "operation": {
-      "title": "Operation",
-      "type": "string"
-    },
-    "result": {
-      "additionalProperties": true,
-      "title": "Result",
-      "type": "object"
-    },
-    "service": {
-      "title": "Service",
-      "type": "string"
-    }
-  },
-  "required": [
-    "service",
-    "operation",
-    "result"
-  ],
-  "title": "_XRPLServiceOutput",
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "operation": {
+      "title": "Operation",
+      "type": "string"
+    },
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    },
+    "service": {
+      "title": "Service",
+      "type": "string"
+    }
+  },
+  "required": [
+    "service",
+    "operation",
+    "result"
+  ],
+  "title": "_XRPLServiceOutput",
+  "type": "object"
+}
  3. Changed7 schema fields changed
    • addedInput schema / properties / buy_marker / description
      Added value: +"Pagination marker for the NFT buy-offer side."
    • addedInput schema / properties / ledger_hash / description
      Added value: +"Optional ledger hash used to pin the NFT-offer lookup."
    • addedInput schema / properties / ledger_index / description
      Added value: +"Optional validated ledger index or selector."
    • addedInput schema / properties / limit / description
      Added value: +"Optional maximum number of NFT offers to return."
    • addedInput schema / properties / nft_id / description
      Added value: +"Canonical NFTokenID identifying the NFT whose marketplace offers should be retrieved."
    • addedInput schema / properties / offer_type / description
      Added value: +"NFT marketplace offer side to retrieve: buy, sell, or both. Default is both."
    • addedInput schema / properties / sell_marker / description
      Added value: +"Pagination marker for the NFT sell-offer side."
  4. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: offer_type maps to distinct native structures (nft_buy_offers vs nft_sell_offers), and buy_marker/sell_marker paginate the two sides independently, which is non-obvious. It stops short of describing return shape, so not 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?

The core purpose and the offer_type branching are front-loaded, and the sibling routing comes last where it belongs. It is dense and slightly long, but each sentence carries distinct information; no filler.

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?

With no output schema, the description should carry the full burden, and it covers lookup scope, side selection, pagination, and ledger pinning. It omits return-value shape and marker semantics for continuing pagination, which are minor gaps for a read-only listing tool.

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 baseline is 3, but the description adds meaning the schema does not: it explains that buy/sell markers paginate independently, that ledger_hash/ledger_index pin the lookup to a ledger, and that limit bounds returned offers. This is genuine semantic value on top of the structured fields.

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 states a specific verb and resource ('Read-only XRPL NFT marketplace-offer lookup for one NFTokenID') and immediately scopes it to a single NFT. It explicitly distinguishes itself from n9t2_xrpl_list_account_nfts and n9t2_xrpl_list_account_objects, so an agent can separate it from siblings without opening any 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?

It gives explicit when-to-use routing: use this for marketplace offers on a specific NFT, use list_account_nfts for owned inventory, and use list_account_objects with object_type='nft_offer' when raw ledger entries are needed. Both alternatives and the selecting condition are named.

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