Skip to main content
Glama

N9T2 XRPL Agent Gateway

n9t2_xrpl_get_book_offers

Read-onlyIdempotent

Read-only XRPL DEX order-book lookup for a specific trading pair. taker_gets and taker_pays are the required XRPL currency-specification objects that define the two sides of the book; limit optionally caps the number of offers returned. The result provides global book offers and market-depth data without modifying the ledger, and calls are subject to the configured gateway rate limits. Use this for global DEX order-book depth; use n9t2_xrpl_list_account_offers for one account's outstanding offers and n9t2_xrpl_find_path when you need payment-path discovery instead.

Input Schema

NameRequiredDescriptionDefault
limitNoOptional maximum number of DEX order-book offers to return.
taker_getsYesCurrency specification for the asset the taker receives in the XRPL DEX order book.
taker_paysYesCurrency specification for the asset the taker pays in the XRPL DEX order book.

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. Changed3 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"Optional maximum number of DEX order-book offers to return."
    • addedInput schema / properties / taker_gets / description
      Added value: +"Currency specification for the asset the taker receives in the XRPL DEX order book."
    • addedInput schema / properties / taker_pays / description
      Added value: +"Currency specification for the asset the taker pays in the XRPL DEX order book."
  4. Added

TDQS

A4.3/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's 'without modifying the ledger' is largely redundant with that. It does add genuinely new context, though: calls are subject to the configured gateway rate limits, and the result contains global book offers plus market-depth data. Pagination behavior beyond the limit cap is not described.

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?

Three sentences, all front-loaded, with the core purpose first and routing last. Slight redundancy: 'without modifying the ledger' restates what readOnlyHint already covers, which is the only sentence that does not fully earn its place.

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 compensates by stating that the result yields global book offers and market-depth data. Parameter meaning for the required nested currency objects is described at the intent level. What is missing is any hint of result shape or the depth/ordering of returned offers, which matters for a book-depth tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including descriptions for limit, taker_gets, and taker_pays, so the baseline is 3. The description adds mild framing (the two currency-spec objects define the two sides of the book; limit caps offers returned) but no format details or structure for the nested currency objects that the schema leaves as additionalProperties: true.

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 first sentence names a specific verb+resource (read-only order-book lookup) and the scope (a specific trading pair) in one line. It also names two siblings and the condition each covers, so an agent can distinguish it from n9t2_xrpl_list_account_offers and n9t2_xrpl_find_path without opening a 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?

The last sentence is explicit routing: 'Use this for global DEX order-book depth; use n9t2_xrpl_list_account_offers for one account's outstanding offers and n9t2_xrpl_find_path when you need payment-path discovery.' Both when-to-use and alternatives are stated, with no inference required.

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