Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
search_marketsA

Search open Kalshi or Polymarket markets and return candidates with their best prices.

Start here to find market ids, then call get_quote or get_orderbook for live
prices, or get_market for resolution details. Reads the venues' public APIs,
so no account or API key is needed; Kalshi keyword search scans up to 1,000
open events. Returns {venue, query, count, markets}; each market has
market_id, title, best bid and ask in dollars, volume and closing date.
get_marketA

Get one market's details: title, best bid and ask, volume and closing date.

Kalshi results include the resolution rules (rules_primary, rules_secondary);
Polymarket results include the outcomes, token ids, neg-risk flag and the
market's fee schedule. Read the rules of every leg here before trusting a
relation in check_constraint_live. For prices plus fee terms only, use
get_quote; for depth, use get_orderbook. Public data, no API key.
get_orderbookA

Get the displayed order book for YES and NO as [price, size] levels, best first.

Prices are dollars per contract and sizes are contracts. Use it to see how
much of a basket can fill near the quoted price before paper_order; use
get_quote when only the top of book matters. Kalshi publishes bids only, so
each side's asks are derived from the other side's bids (a YES ask of p is a
NO bid of 1 - p). Public data, no API key.
get_quoteA

Get the best bid and ask on YES and NO, in dollars, plus the market's fee schedule.

Use it to collect prices for check_constraint, or to read the fee terms
(Kalshi multiplier and maker fees, Polymarket taker rate) that trading_fee
takes. check_constraint_live fetches quotes itself, so this is not needed
before calling it. A missing ask is derived from the opposite side's bid.
Returns {venue, market_id, title, yes_bid, yes_ask, no_bid, no_ask,
fee_schedule}. Public data, no API key.
trading_feeA

Compute the venue fee for one fill at a given price and size; a pure calculation with no network calls.

Kalshi charges round_up(0.07 x M x C x P x (1 - P)) on taker fills, and
0.0175 x M x C x P x (1 - P) on maker fills where the series has maker fees;
Polymarket charges takers rate x C x p x (1 - p) and makers nothing. Use it
to price a single leg or a hypothetical fill; take a live market's fee terms
from get_quote, and use check_constraint to price a whole basket. Returns
fee, fee_per_contract, order_type and the schedule used.
check_constraintA

Check offline whether prices you supply violate a no-arbitrage relation, and price the cheapest exploiting basket after fees.

A pure calculation with no network calls: use it for hypothetical or
historical prices, and use check_constraint_live to fetch current quotes
instead. Returns violated, profitable_after_fees, the best basket (legs,
cost, guaranteed payoff, fees, gross and net edge), every candidate basket,
any missing quotes, and the assumptions behind the check (full fills at the
quoted prices, a correctly specified relation).
check_constraint_liveA

Fetch live quotes and fee schedules for related markets, then check whether their prices violate a no-arbitrage relation after fees.

This is the main research call: find related contracts with search_markets,
confirm with get_market that their resolution rules really satisfy the
relation, then pass them here. Read-only: it calls the venues' public APIs
and places no orders. Returns the check_constraint result (violated,
profitable_after_fees, best basket with net edge) plus the quotes it used;
to simulate the trade, call paper_order for each leg of the best basket.
list_relation_typesA

List the relation types the constraint checks support and the probability bound each enforces.

Static reference data with no network or file access, for example
implication: P(A) <= P(B). Use it to choose the relation argument of
check_constraint or check_constraint_live; to see concrete market pairs
saved on this machine, use list_relations instead. Returns
{relations: {name: bound}}.
fair_valueA

Convert a market price into the probability it implies under the Wang transform, and report the premium.

Solves p_mkt = Phi(Phi^-1(p) + lam) for p; a pure calculation with no network
calls. Use it to strip the favourite-longshot premium from a quoted price
before comparing it with your own forecast. The default lam = 0.183 is the
pooled estimate in Yang (2026), SSRN 6468338; it pools real-money and
play-money venues, so treat it as illustrative. Returns market_price,
lambda, implied_probability and premium (price minus implied probability).
list_relationsA

List the market relations saved on this machine by the oracle3 research CLI, optionally filtered.

Reads ~/.oracle3/relations.json with no network calls. Use it to reuse pairs
already discovered or validated offline, then pass a pair to
check_constraint_live. For the abstract relation kinds and their bounds,
call list_relation_types instead. Returns the store path, a count and the
matching relations (markets, type, status and validation details); the list
is empty if the CLI has saved none.
paper_orderA

Simulate buying YES or NO contracts in the local paper ledger, filling against the live order book with venue fees. Never sends an order to a venue.

Walks the displayed asks from the best price up to limit_price and charges
the venue fee on each level. Use it to test the legs of a basket found by
check_constraint_live. Writes ~/.oracle3/mcp_paper_ledger.json (or the path
in ORACLE3_MCP_LEDGER); only buys are supported and positions are held at
cost. Returns status (filled, partially_filled, unfilled, or rejected when
paper cash is short), requested and filled contracts, average price, cost,
fees and the per-level fills.
paper_portfolioA

Show the local paper ledger: cash, open positions and the number of fills.

Reads ~/.oracle3/mcp_paper_ledger.json (or ORACLE3_MCP_LEDGER) with no
network calls. Use it after paper_order to confirm fills and remaining cash.
Starting cash is $10,000; positions are carried at cost, and the ledger does
not mark to market or track resolution. Returns the ledger path,
initial_cash, cash, positions and fills.
paper_resetA

Erase the local paper ledger and restore the $10,000 starting cash.

Deletes all paper positions and fill history; no venue is contacted and real
accounts are never touched. Without confirm=true it returns status
not_reset and changes nothing. Use it to start a fresh paper-trading
session.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 13 tools

Disambiguation4/5

Most tools have clearly distinct purposes and descriptions cross-reference each other, such as offline vs live constraint checks and orderbook depth vs top-of-book quotes. However, get_quote and get_market both return best bid/ask and fee schedule, so an agent could occasionally confuse them despite the resolution-rules guidance.

Naming Consistency4/5

All names use snake_case consistently, with predictable prefixes like get_, check_, list_, and paper_. A few tools are noun phrases such as trading_fee and fair_value rather than verb_noun, but the overall convention is coherent.

Tool Count5/5

The 13 tools are well-scoped for prediction-market research and paper trading, covering discovery, pricing, constraint analysis, and ledger operations without obvious redundancy or padding.

Completeness3/5

The surface covers search, market details, quotes, order books, fees, arbitrage checks, and paper-trade entry, but paper trading only supports buys with no sell, close, or settlement operation. That is a notable lifecycle gap for a trading-oriented server.

Maintenance

ActivityMaintained
ResponsivenessSlow