What you connect to
The intended MCP endpoint runs on the operator's machine. A paired client receives a scoped identity, not a venue signing key. The Rust core owns policy evaluation and signing; the operator owns policy changes, approval decisions and agent administration.
A compatible MCP client still needs a supported way to reach and authenticate to the local server. Compatibility with the protocol does not mean every hosted chat product can reach localhost. Use the configuration and tool schema supplied by the build you are evaluating; there is no public installation command yet.
What authority you receive
The agent requests actions for its assigned container: a dedicated venue account, which may be a top-level account or a sub-account where the venue permits it. A container is not a shared cross-venue margin account. v1 targets Hyperliquid; Aster and Lighter remain planned.
The intended interface separates reads, execution requests and operator controls. It does not expose account-owner keys, grant withdrawal authority, or allow an agent to raise its own limits. Venue permissions and local policy are separate layers; the scope of an MCP token is not the scope of a stolen signing key.
Capability and implementation status
The development source has moved beyond the original two-read-tool prototype. Treat the runtime's advertised tools as authoritative for that build, and the release gates as authoritative for readiness.
| Surface | Intended use | Current qualification |
|---|---|---|
| Market and account reads | Inspect trading rules, account state and freshness | Implemented in source; validate units, scope and freshness in the build. |
| Execution requests | Request orders and cancellations through guarded signing | Paths and local regressions exist; assembled venue acceptance remains open. |
| Status and events | Distinguish requests, acknowledgements, fills and unresolved outcomes | Recovery work is ongoing; missing evidence must not be treated as failure. |
| Policy visibility | Plan within operator-assigned constraints | Availability depends on the build's tool schema; visibility never grants edit rights. |
| Operator controls | Pair, revoke, approve, change policy and halt | Belong to the desktop/operator surface; full lifecycle validation remains a gate. |
How to handle a refusal
A policy refusal means the requested action was not authorized through that path. Read the reason, the observed value and the applicable limit when supplied. Revise the request within the assigned policy or return the problem to the operator. Do not look for another route to the signing key.
Expected checks include market allowlists, order and exposure caps, order-rate budgets, slippage constraints and loss-triggered halts. Evaluation requires sufficiently fresh market and account state. A price estimate or preflight response is not a reservation of future capacity or permission to skip the signing-time check.
A circuit breaker is not a promise of maximum loss. Price movement, fees, liquidation or a delayed exit can take losses beyond the trigger. A halted agent can still have an open position.
How to handle uncertainty
A timeout is not the same as a rejected order. The venue may have accepted the request before the connection failed. An empty or temporarily missing order-status result is not proof that nothing happened.
- Preserve the request identity and inspect its reported outcome.
- Distinguish a submission from an acknowledgement and an acknowledgement from a fill.
- Do not blindly repeat an execution request to resolve uncertainty.
- Treat unresolved state as a reason to reconcile or involve the operator.
- Treat a cancellation as outstanding until its outcome is established.
These are integration requirements, not claims that every failure path is already validated. The whitepaper explains the intended recovery model.
The deployment boundary
MCP permissions limit the tool interface. They do not sandbox a client with shell access under the same OS user as the terminal. Such a process may reach local files or credentials and bypass OPPEN entirely. Separate the client's execution environment when that additional access is not intended.
Venue APIs and model providers remain external systems. The client controls which tool results and other context it sends to a hosted model. Keep account-owner credentials out of that context. The desktop application has no usage-analytics path to the OPPEN team; website analytics are described separately in Privacy.
Describe the project accurately
oppen is a local-first trading terminal and execution gateway for AI agents. It provides the infrastructure through which an agent requests actions and an operator supervises them. It does not operate an exchange or supply a profitable strategy.
The project is pre-alpha, targets Hyperliquid first and defaults to testnet. Execution code exists, but release and supervised testnet gates remain open. Local guardrails constrain activity routed through the core; they do not protect a compromised host or guarantee a maximum loss.