Tools

Thirty read tools register on every start. Nineteen 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

Every venue carries the same five read tools, because markets, orders and balances are venue-scoped. Replace polymarket_ with kalshi_, prophetx_ or limitless_ for the other venues. The order-list tools return one page and a nextPageToken. Pass it back as pageToken to read the next page. Each venue’s tools filter by its own market identifier (tokenId, ticker, strikeId) and by lifecycle status. Three venues add one read tool each: kalshi_list_order_queue_positions, one page of the contracts resting ahead of each of the trader’s resting orders at its price; prophetx_get_ladder, every price ProphetX accepts; and limitless_list_markets, one page of the tradeable Limitless markets, which the discovery surface does not carry.

​

Trading tools

They register only when both halves of a gate are satisfied: 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. A batch submit takes one key for the whole batch and answers per entry: the Polymarket and Kalshi batches return orders in request order, and the ProphetX batch returns succeededOrders and failedOrders. Read those rather than the call’s success. Each prophetx_submit_orders entry takes timeInForce of GTC or FOK, and omitting it sends GTC. A FOK entry cannot also set postOnly, and the tool refuses that batch before anything is sent. GTD is not a batch policy: the API accepts it on a single ProphetX order only. A failed entry is not always a refusal. ORDER_RECONCILIATION_REQUIRED means the outcome is unknown and the order may be live, so read it back by the entry’s orderId; INTERNAL_ERROR with no order id means the outcome is unknown too, so resend the identical batch under the same key. Any other code means the entry was refused and not placed. Polymarket reports success: false in all three cases, so it does not on its own establish that nothing was placed. Never resend a batch under a fresh key, which places its accepted orders a second time. 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.