Deployment Capabilities
How an MCP client determines the tools and venue request formats available on the connected Pakt server.
An MCP client should discover capabilities from the connected server rather than from product copy or a remembered configuration.
Discover Capabilities at Runtime
Read tools/list for available tools and get_execution_context for the
account's usable roots and venue formats. Do not infer readiness from
documentation or cached state.
Server Tool Surface
MCP tools/list is authoritative for available operations. The hosted Pakt
catalogue groups its tools into:
- pure authoring;
- passkey-backed Pakt authority;
- root-first action authorization.
Account Execution Surface
Call get_execution_context before constructing an action. Its active Pakt
rows are fully revalidated and name their supported venue request formats and
allowlists. The hosted action schemas include:
- one exact unsigned Hyperliquid immediate-or-cancel (IOC) order; and
- a complete Ethereum BOB Gateway plan whose finite approval and order phases are proved and signed separately.
The server derives account identity, environment, wallet identifiers, quotes, fees, authenticated state, and trusted venue evidence.
Sign-Only Boundary
propose_execution starts proof-gated authorization. A successful terminal
result returns a submission-ready signed request, but Pakt does not submit it.
The existing venue client remains responsible for unchanged submission and for
recording the venue outcome.
If a connected deployment returns NOT_INTEGRATED or
execution_not_integrated, it has failed closed before producing the requested
authorization. That is a current capability result from that server, not a
policy refusal.