Skip to main content
Glama
Sign In

Kellian

by app.kellian
OverviewDiscussionsAdmin

Preview a market-order sweep without reserving liquidity — estimated fill, avg/worst price, partial-fill flag. Buys size by total spend, or by pre-fee notional

kellian_estimate_market_order
Read-onlyIdempotent

Price a market order before placing it: estimated shares/amount, amount-weighted average price, worst-leg price, and a partial-fill flag, from the exact matching math a live order will meet. Reserves no maker liquidity and costs no gas, so call it as often as sizing requires. Read-only; no wallet proof required. SIZING A BUY — a bare amount is a ceiling on the TOTAL debited (base + taker fee together fit inside it), which is NOT what the same field means at Polymarket; pass amountMode "notional" for their meaning (pre-fee notional, fee charged on top), or maxSpend to state the ceiling explicitly. The response echoes amountMode, so read it rather than assuming. MINIMUMS — ONE floor. The venue's trading minimum is FLAT: one number, the same at every price, on either outcome, on every orderbook market, binding the amount you sent in the mode you sent it; a size under it answers 400 AMOUNT_BELOW_MINIMUM with minAmountWei, and the book snapshot publishes it as effectiveMinBuyAmount so you can size before asking. Each market still reports a minBuyAmount on that snapshot, but it is DEPRECATED AND UNENFORCED: settlement asserted it per settlement leg — the counterparty's leg of a complementary mint included, which made the felt minimum rise with the price — until the 2026-08-31 beacon upgrade removed the assertion across the whole catalog. Do not size against it and do not treat it as a floor. A market order is an immediate-or-cancel order — place it with kellian_place_limit_order using timeInForce IOC and a price beyond the worst level this sweep touches. When this MCP session has a bound wallet, that address is excluded for self-trade prevention (matching REST sweep-estimate); with no wallet bound the estimate uses the zero address and may include your own resting orders, so treat it as optimistic.

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

Input Schema

NameRequiredDescriptionDefault
kindNo0=buy/bid, 1=sell/ask
sideYes0=outcome 1, 1=outcome 2
amountNoExact-input raw size in the market collateral's denomination. BUY: read as a TOTAL-SPEND CEILING by default — base + taker fee together land at or under this, so a typed 10 debits 10.000000 and never 10.03. Send amountMode "notional" to read it Polymarket-style instead: pre-fee notional, with the fee charged ON TOP (total debited = amount + fee). The venue's flat trading minimum binds THIS number as sent, in whichever mode you sent it, and is the same figure either way. SELL: collateral-denominated outcome-token units to sell; neither mode applies. Mutually exclusive with maxSpend — provide exactly one.
chainIdNoChain id for the market address. Required when the same market address exists on multiple chains.
maxSpendNoBUY only. Cap the TOTAL debited — base plus taker fee — at this raw collateral amount; the sweep sizes down so the complete cost fits. Identical in meaning to a bare `amount`, spelled out: send this when the cap is the point and you want the request to say so rather than rely on a default. Mutually exclusive with `amount`, and refused together with amountMode "notional" (which asks for the opposite).
amountModeNoBUY only. How to read the size. "total" (DEFAULT, and what every caller has always got) treats it as a ceiling on the total debited: base + taker fee ≤ amount. "notional" is Polymarket's `amount` meaning: buy this much of base and charge the fee on top, so the total debited is amount + fee and exceeds what you sent. The venue's flat trading minimum is the SAME NUMBER in both modes and binds the amount as sent — ten means ten debited under "total" and ten of pre-fee base under "notional" — so a wallet holding exactly the minimum can always send it. It is the only sizing floor: the market's stored minBuyAmount was retired as a settlement precondition in the 2026-08-31 beacon upgrade and refuses nothing. Any refusal bound comes back in the mode you sent, tagged with it. Refused on a sell, and refused alongside maxSpend.
limitPriceNoWorst requested-side executable price: BUY maximum, SELL minimum.
marketAddressYesOrderbook market address

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: discloses that it matches the REST sweep-estimate math, excludes the bound wallet address for self-trade prevention, and warns that with no wallet bound the estimate uses the zero address and may include the caller's own resting orders (i.e., optimistic). It also surfaces the concrete failure mode (400 AMOUNT_BELOW_MINIMUM with minAmountWei) and that the response echoes amountMode.

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

Conciseness3/5

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

Front-loading is excellent — the first sentence delivers the full purpose and outputs. But the body runs long, with a multi-sentence historical digression on the 2026-08-31 beacon upgrade and deprecated minBuyAmount (repeated again in two schema parameters) that consumes space disproportionate to its decision value.

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 an 8-parameter pricing tool with an output schema (so return values need no prose), the description covers everything an agent needs to call it safely: the single flat minimum and how it binds the amount as sent, the deprecated field it must not size against, error code, chainId-adjacent context, and the self-trade caveat. Nothing material is missing.

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% and the schema already spells out the total-vs-notional ceiling, maxSpend mutual exclusion, and amountMode defaults in nearly the same words, so the description largely restates structured data. Its one genuine addition over the schema is the cross-venue warning that a bare amount is a total-debit ceiling unlike Polymarket's meaning, plus the instruction to read back the echoed amountMode — useful, but partial.

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?

"Price a market order before placing it" names a specific verb (price/preview) and resource (market order), then enumerates the returns: estimated shares/amount, amount-weighted average price, worst-leg price, and partial-fill flag. The definition also contrasts implicitly with the write path by naming kellian_place_limit_order for actual execution, so an agent can separate it from placement 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?

Strong context: "call it as often as sizing requires" (no gas, no liquidity reserved, no wallet proof) tells the agent this is a free pre-check, and it explicitly routes execution to kellian_place_limit_order with timeInForce IOC at a price beyond the worst touched level. It never contrasts itself with the similarly-shaped siblings (kellian_simulate_trade, kellian_plan_pm_order, kellian_get_market_depth), so the agent must infer which pre-trade estimator to choose.

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

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