Skip to main content
Seventeen read tools register on every start. Four trading tools register only behind the opt-in below. Every tool returns its payload twice: as structuredContent, typed against the tool’s output schema, and as the same JSON in a text block for clients that read only text.

​
Read tools

​
Identity and discovery

lookup_market takes exactly one of the four identifiers. Supplying none or more than one is rejected before the call leaves your machine.

​
Orders, fills, positions and balances

The two venues carry the same five read tools each, because markets, orders and balances are venue-scoped. The order-list tools return one page and a nextPageToken. Pass it back as pageToken to read the next page. The Polymarket tools filter by tokenId, the Kalshi tools by ticker, and both filter by lifecycle status.
Discovery listings report venue in upper case (POLYMARKET, KALSHI), while the tools are named polymarket_* and kalshi_*. Read the venue off the listing and pick the matching tool.

​
Trading tools

These four tools place and cancel real orders against real money. Every one of them is annotated as destructive so your client can prompt before it runs. Keep a person in front of each order.
They register only when both halves of a gate are satisfied:
1

You opt in

PARLAYX_MCP_ALLOW_TRADING=1 is set in the same env block as your credentials.
2

The key may trade

The key itself carries the trade capability. Call whoami to see what your key carries.
Without both, the tools are not advertised, so nothing can reach them. Both are read before the transport opens, so changing either one takes effect on the next restart rather than mid-session. Each submit tool accepts an optional idempotencyKey. Pass the same value again to make a retry safe. Omit it and every call mints a fresh key, which means a retry is a second order. Order shapes match the REST contract: see the Polymarket and Kalshi references for the field semantics and units.

​
Errors

A failed call comes back as a tool result rather than a protocol error, marked as an error and carrying three fields:
  • code, the stable error category, such as INVALID_REQUEST, NOT_FOUND, INSUFFICIENT_BALANCE or UNAUTHORIZED. See Errors for the full set.
  • status, the HTTP status code.
  • message, an explanation, and for the cases an agent can act on, what to do next.
Response bodies are left out, so nothing large or unexpected lands in the model’s context. Some messages go further than the API’s own. A 403 points at whoami. An idempotency conflict says to read the original result rather than retry. An order that could not be reconciled says to stop and read it back. A rejected signature is diagnosed first: see Troubleshooting.