stellar-pulse-mcp

SDEX order book

stellar_orderbook

Read-onlyIdempotent

Fetch the Stellar DEX order book for an asset pair to view best bid/ask, mid price, spread, and resting depth within 1% and 5%.

Instructions

Order book of a pair on the Stellar DEX: best bid/ask, mid price, spread and resting depth within 1% and 5%, plus the top levels. Assets can be XLM, a code like USDC (most traded issuer is used and disclosed) or CODE-ISSUER.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "base": "<base>",
      "counter": "<counter>"
    },
    "name": "stellar_orderbook"
  }
}

Input Schema

Name	Required	Description
`base`	Yes	Asset being priced, e.g. XLM
`levels`	No	How many price levels per side to return
`counter`	Yes	Asset it is priced in, e.g. USDC

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, yet the description adds substantive context beyond them: what the response contains (spread, depth buckets at 1% and 5%) and the non-obvious resolution rule that a bare code like USDC maps to the most traded issuer, which is disclosed. That issuer-disclosure behavior is not derivable from any structured field and materially affects interpretation of results.

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?

Two sentences, front-loaded with the resource, and every clause carries information (metrics list, depth buckets, asset notations). The first sentence is a dense run-on enumeration but nothing is padding.

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?

No output schema exists, so the description must carry the return-value burden, and it does by naming the bid/ask, mid, spread, depth and level fields. Gaps are minor: no error behavior for unknown pairs and no note on what happens if a code has no traded issuer.

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, but the description genuinely extends the schema: it explains the three asset notations (XLM, bare code with issuer inference, CODE-ISSUER), while the schema only offers 'e.g. XLM'/'e.g. USDC'. The levels parameter is only loosely gestured at via 'top levels', so not full marks.

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?

States a specific verb+resource: 'Order book of a pair on the Stellar DEX', and enumerates the returned fields (best bid/ask, mid, spread, depth, top levels). The resource is plainly distinct from siblings like stellar_asset and stellar_top_assets, though the description never names them to sharpen the distinction.

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

Usage Guidelines3/5

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

Usage is implied by the resource ('give me the book for this pair'), and the description explains accepted asset formats, but it never states when to prefer this over stellar_asset or stellar_top_assets, nor any preconditions. An agent can infer the use case but is given no explicit routing guidance.

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

Deploy Server