Kellian

Get a stateless exact-input trade quote

kellian_get_quote

Read-onlyIdempotent

Get a stateless trade quote. Response is a discriminated union on kind: "amm" (LMSR) returns outcomeTokensOut for buys, collateralOutRaw for sells, prices after, fees; "orderbook" (CLOB markets) returns bestBid/bestAsk/spread/mid instead — there is no single LMSR price to quote against a resting book. /trade/quote is stateless exact-input pricing only. To price a position-relative closePercent sell or a targetCollateralOut exact-output sell, call /trade/simulate with the same body you would later send to /trade/prepare.

Examples: Quote buying outcome 1 with PM collateral; Quote an order-book (CLOB) market — returns book state, not an LMSR price

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": {
      "marketAddress": "<marketAddress>",
      "side": "<side>",
      "action": "<action>",
      "amount": "<amount>"
    },
    "name": "kellian_get_quote"
  }
}

Input Schema

Name	Required	Description
`side`	Yes	`side` = which OUTCOME (0-indexed: 0=outcome1,1=outcome2,2=outcome3), NOT buy/sell. Buy/sell is the direction field (`type`/`tradeType`/`action`/`direction`). Encoded here as the outcome label string ('outcome1'\|'outcome2'\|'outcome3'), not the 0-indexed TradeSide int used on REST /trade/* bodies.
`action`	Yes	Trade DIRECTION (buy/sell). Note: this same concept is named `kind` (0=buy/1=sell int) on /orderbook/* and `side`/`action`/`tradeType`/`type`/`direction` on other trade endpoints — see skill.md field-map.
`amount`	Yes	Exact-input size. BUY: collateral spent. SELL: outcome tokens sold. Outcome tokens carry the market collateral's own denomination — one outcome token redeems for one collateral unit — so every outcome-token quantity uses that single unit: positions.outcome1Shares/outcome2Shares/outcome3Shares, SELL amount, 409 available/requested, and outcomeTokensOut/minOutcomeTokensOut. It is also the unit the signed intent carries, so nothing is converted between the wire, the engine and the calldata. /trade/quote is stateless exact-input pricing only. To price a position-relative closePercent sell or a targetCollateralOut exact-output sell, call /trade/simulate with the same body you would later send to /trade/prepare.
`chainId`	No
`marketAddress`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds real behavioral context: the response is a discriminated union on `kind`, with different field sets per branch, and it explains the domain reason an order-book quote returns bestBid/bestAsk/spread/mid rather than a single LMSR price. It does not mention auth requirements, rate limits, or failure behavior, which keeps it below the top score.

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 purpose and the response-shape breakdown are front-loaded and information-dense. The closing "Examples:" lines are just restated intents with no parameter values or call shapes, and the simulate-redirect sentence is duplicated verbatim in the `amount` schema description, so there is minor waste.

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?

An output schema exists, so return values need not be enumerated, yet the description usefully explains the union discriminant and both branches. Combined with the explicit stateless/exact-input boundary and the redirect for unsupported sell modes, an agent has what it needs to call this correctly; only auth/chain context and error behavior are absent.

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 60%, and the schema itself already carries the important disambiguation (side = outcome, not direction; action = buy/sell; amount units). The description text adds little on its own beyond restating the exact-input constraint and the simulate redirect, and `chainId` and `marketAddress` remain undescribed in both places.

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 ("Get a stateless trade quote") and immediately narrows the scope to exact-input pricing only. It further splits the answer by market type ("amm" LMSR vs "orderbook" CLOB), which lets an agent distinguish it from kellian_simulate_trade and kellian_estimate_market_order 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 Guidelines4/5

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

Explicitly states when NOT to use it: position-relative closePercent sells and targetCollateralOut exact-output sells belong on /trade/simulate with the prepare body. That is genuine exclusion guidance with a named alternative, though the alternative is referenced by REST path rather than the sibling tool name kellian_simulate_trade, so a mapping step remains.

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

All Kellian 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.

Resources

Need Help?