Kellian

Inverse quote — size a buy or sell to reach a target outcome price

kellian_quote_to_price

Read-onlyIdempotent

Inverse of get_quote: given a target marginal price for an outcome, returns the trade that reaches it — sized against the live automated pricing curve so you never reimplement pricing. Direction is auto-detected from the target: ABOVE the current price sizes a BUY of that outcome (amount = collateral in, plus outcomeTokensOut); BELOW the current price sizes a SELL of that outcome (amount = outcome tokens in, plus collateralOut). Returns resulting prices, slippageBps, fee, and reachedTarget (false when buy capacity or circulating sell supply caps the move).

Examples: Size a buy of outcome 1 to reach price 0.60 (above current → buy); Size a sell of outcome 1 to reach price 0.40 (below current → sell)

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>",
      "targetPrice": "<targetPrice>"
    },
    "name": "kellian_quote_to_price"
  }
}

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.
`chainId`	No
`targetPrice`	Yes
`marketAddress`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context beyond them: it explains that the call returns reachedTarget=false when buy capacity or circulating sell supply caps the move, and it clarifies that it sizes against the live curve rather than requiring the caller to model pricing. It stops short of noting rate limits, staleness of the quoted curve, or what happens if the target equals the current price.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core inverse-pricing claim is front-loaded in the first clause, the direction rule immediately follows, and the return contract closes it out. The two examples are short and disambiguate the non-obvious above/below behavior rather than restating the prose.

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?

An output schema exists, so return fields need not be enumerated in full, yet the description still flags the one return value an agent must act on (reachedTarget). Direction derivation, sizing semantics, and the capacity-cap edge case are all covered, which is everything needed to invoke this correctly.

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 only 25%, but the description compensates on the parameter that matters: it defines targetPrice as a marginal price for an outcome and derives buy/sell semantics from its position relative to the current price. The remaining params (marketAddress, chainId) get no description treatment, leaving some gap against the low coverage baseline.

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+resource (sizes the trade that reaches a target marginal price) and explicitly positions itself against the sibling kellian_get_quote as its inverse. The auto-detection rule (above current = buy, below current = sell) makes the tool's identity unmistakable.

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?

The 'inverse of get_quote' framing plus concrete examples clearly signal when to reach for this rather than the forward quoter. However, it never addresses the other adjacent tools an agent would weigh it against (simulate_trade, prepare_trade, estimate_market_order), so routing beyond the get_quote pair is left to inference.

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?