Skip to main content

Canonical tool surface

This page reflects the current canonical MCP surface asserted by the server smoke test on main. The server is organized around a smaller set of wrapper-style entry points:
  • list_markets selects listing shape and retrieval mode with view and mode
  • market data is exposed through pluralized batch tools like get_order_books and get_prices
  • auth flows are centered on ensure_api_key, prepare_order, place_order, cancel_orders, get_rewards, and get_rewards_market_details
  • transaction building is unified under build_transactions
  • relayer execution is unified under relayer_execute

1) Public market discovery

These tools work without credentials.

list_markets

list_markets is the canonical listing entry point. It accepts:
  • view to choose payload shape
  • mode to choose listing mode
  • next_cursor for pagination
Example:

2) Batched market data

Use these tools when you already have one or more token_id values and want consistent batch responses. Example:
items[].side is required for side-aware tools like get_prices. Including side in other batched calls is still useful for a uniform workflow shape.

3) Authenticated trading and account wrappers

These tools require configured Polymarket credentials.

prepare_order

prepare_order prepares or signs an order locally without posting it.
  • kind: "limit" expects price and size
  • kind: "market" expects amount

place_order

place_order is the canonical order-posting wrapper. It uses source to select the posting path:
  • source: "draft" for create-and-post from a draft order
  • source: "signed" for posting one pre-signed order
  • source: "signed_batch" for posting a batch of pre-signed orders
confirm: true is required.

cancel_orders

cancel_orders is the canonical cancellation wrapper. It uses:
  • mode: "ids"
  • mode: "all"
  • mode: "market"
confirm: true is required.

get_rewards

get_rewards uses a scope selector:
  • day
  • total_day
  • current
  • percentages
  • user_market_config
Use get_rewards_market_details when you need market-specific reward details for a condition_id.

4) Bridge and transaction building

Bridge tools

  • bridge_supported_assets
  • bridge_create_deposit_addresses
  • bridge_get_transaction_status

build_transactions

build_transactions is the canonical transaction-builder wrapper. Pass an items array where each item declares a kind plus its required fields. Representative kind values include:
  • erc20_approval, erc1155_approval, erc20_transfer, eth_transfer
  • withdraw_on_matic
  • split_positions, merge_positions, redeem_positions
  • buy_market_outcome, sell_market_outcome
  • add_funding, remove_funding
  • neg_risk_convert_positions, neg_risk_redeem_positions
  • proxy_wallet_address, index_set, market_index
Example:

5) Relayer and builder-relayer

Use these when transaction lifecycle tracking matters.

Relayer tools

  • relayer_get_relay_address
  • relayer_get_nonce
  • relayer_get_relay_payload
  • relayer_get_transactions
  • relayer_execute
  • relayer_deploy_safe
  • relayer_poll_until_state
relayer_execute is the canonical relayer execution wrapper. It accepts:
  • execution_type: "proxy" | "safe" | "manual"
  • transactions
  • optional metadata
  • optional gas_limit / gas_price for manual mode
  • confirm: true

Builder-relayer tools

  • builder_relayer_get_nonce
  • builder_relayer_get_relay_payload
  • builder_relayer_get_transactions
  • builder_relayer_execute
  • builder_relayer_deploy
  • builder_relayer_get_deployed
  • builder_relayer_poll_until_state

6) Prompts and resources

Prompts

Resources

Resource template