JW3 MCP Server

Read live CEX datum

read_live_datum

Read-only

READ-ONLY: fetch ONE specific live datum on demand (open positions, account balances, or a market quote) instead of waiting for the context snapshot. Never moves funds, never places an order, never widens the context on its own — ask for exactly the datum you need. Returns numbers WITH the venue and a fetch timestamp; report them as 'observed at on '. If the result has no fetched number, say the value is unavailable — NEVER invent a placeholder. Present positions/balances/order reads as an inline markdown table in your reply text (never 'shown above'); when empty, say 'No open positions' explicitly. Not for writing anything; use a propose_* tool when the user wants an action.

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": {
      "kind": "<kind>"
    },
    "name": "read_live_datum"
  }
}

Input Schema

Name	Required	Description
`tag`	No	Optional tag pill to filter kind=predictions scope=markets: politics\|crypto\|sports\|economy\|ai\|tech (Polymarket tag_slug; Opinion matches its category labels best-effort). Omit for the most liquid open markets overall.
`kind`	Yes	Which datum to read. positions = open derivatives positions with mark/liq/leverage (rows also carry their resting venue-native exit legs as exits[] with TP/SL triggers across all CEX venues, or exitsUnknown:true when the stops book could not be read — quote those, never invent exits). balances = per-connection account balances. open_orders = resting OPEN orders across connections (optional connectionId/exchange narrow, optional symbol pair filter + category spot\|linear; empty list means no resting orders, never a flat position). market = a live quote for one symbol. screener = top-by-volume 24h movers on one CEX (pass symbol=<exchange slug>, e.g. binance). onchain = wallet balances across the user's server-resolved wallets (addresses only, never keys; optional chains=<csv> filter, e.g. ethereum,solana). order = ONE order's status by venue order id (open\|filled\|unknown with observedAt; needs connectionId + orderId, optional symbol + category spot\|linear). predictions = prediction-market reads across Polymarket + Opinion (default scope=markets: the most liquid open markets with yes/no prices, volume, liquidity, endDate, conditionId; scope=positions\|orders reads the user's wallet-scoped positions and resting orders on both venues; scope=quote returns a live quote for one market/token: Polymarket orderbook + tick-size + taker-delay, Opinion latest price + quote tokens). The first leg of any prediction hunt is scope=markets; price before proposing from scope=quote.
`scope`	No	Prediction read scope for kind=predictions (default markets). markets = liquid open markets scan; positions = the user's open prediction positions (wallet-scoped, needs connected creds or wallets=); orders = resting prediction orders; quote = live quote for one market (needs market_id and/or token_id).
`venue`	No	Prediction venue for kind=predictions: polymarket\|opinion\|all. Scan (scope=markets) defaults to polymarket; positions\|orders read both venues unless narrowed; quote defaults to polymarket unless the token/market id is Opinion-shaped.
`chains`	No	Optional comma list to filter kind=onchain, e.g. ethereum,solana.
`status`	No	Optional position-status filter for kind=predictions scope=positions: OPEN\|REDEEMABLE\|REDEEMABLE_LOST\|CLOSED\|MERGEABLE (default OPEN, Polymarket; Opinion returns its open positions).
`symbol`	No	Required for kind=market (e.g. BTC/USDT). Optional pair filter for kind=open_orders (e.g. BTC/USDT narrows the resting book).
`orderId`	No	Venue order id for kind=order (e.g. the orderId a placeOrder/YOLO fill returned).
`wallets`	No	Optional csv of 0x wallet addresses for kind=predictions scope=positions (merged with the stored Polymarket funder; capped at 10). Omit to read the connected wallets only.
`category`	No	Optional market scope for kind=order\|open_orders: spot\|linear. Omit to search both on perp venues.
`exchange`	No	Venue slug for kind=market (e.g. binance). For positions\|balances\|open_orders, narrows to one venue; omit to read every connection.
`token_id`	No	Outcome token id for kind=predictions scope=quote: Polymarket CTF clobTokenId (orderbook + tick-size + taker-delay) or Opinion token id (latest price).
`market_id`	No	Prediction market selector for kind=predictions scope=orders\|quote (and to narrow positions): Polymarket conditionId (0x…), slug, or numeric id; Opinion market id.
`withExits`	No	Accepted for backward compatibility (older CLI versions send it): positions reads always carry their resting venue-native exit legs as exits[] with TP/SL triggers across all CEX venues, or exitsUnknown:true when the stops book could not be read. Other venues ignore it.
`connectionId`	No	CEX connection id for positions\|balances\|open_orders (see list_connections). Omit to read every active connection. REQUIRED for kind=order (an order id is connection-scoped).
`max_age_seconds`	No	Optional freshness bound. The executor prefers its already-fetched value when it is younger than this; otherwise it reads again.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

With readOnlyHint and openWorldHint already supplied, the description reinforces safety in concrete terms ('never moves funds, never places an order, never widens the context on its own') and discloses the return shape's provenance (venue + fetch timestamp). It adds a data-integrity rule worth having: if no fetched number is present, report unavailable rather than inventing a placeholder. Auth/credential prerequisites and rate limits are left to the schema.

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 operative scope ('READ-ONLY: fetch ONE specific live datum') is front-loaded, and the exclusion sentence is placed last where it belongs. Some later sentences are response-formatting directives (markdown table, 'No open positions') that read as prompt instructions rather than tool description, adding length without improving invocation decisions.

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 16-parameter, multi-kind dispatch tool with no output schema, the description covers the three things an agent actually needs before calling: what it does, what it will never do, and how to report the returned numbers with venue and timestamp. The kind-by-kind parameter detail is fully documented in a 100%-covered schema, so the description does not need to repeat it.

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 coverage is 100% across 16 parameters, so the schema already carries the per-kind semantics; the description adds only the sample datum list and the 'exactly what you need' framing. Baseline 3 is appropriate — the description does not need to compensate, and it contributes little parameter-specific meaning beyond what is structured.

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?

Opens with a specific verb+resource: 'fetch ONE specific live datum on demand', and names the contrast case (instead of waiting for the context snapshot). It also explicitly disclaims the write sibling class ('use a propose_* tool when the user wants an action'). However, it enumerates only three of the eight datum kinds (positions, balances, market quote), so kinds like onchain, screener, order and predictions are discoverable only from 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 Guidelines4/5

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

Gives a clear selection rule against the implicit alternative — pull a datum on demand rather than wait for the snapshot ('ask for exactly the datum you need') — and a firm exclusion: 'Not for writing anything; use a propose_* tool.' It does not name read-side siblings such as list_open_orders or read_onchain_balances, so an agent must infer which read tool wins for overlapping data.

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

All JW3 MCP Server tools Inspect

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.