Mishmar
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MISHMAR_BIN | No | The path to the mishmar binary, used by the npx/uvx wrappers to locate the binary (default is PATH or ~/.mishmar/bin). | |
| MISHMAR_AGENT_CONFIG | No | The path to the agent config file (default is ~/.mishmar/agent.json). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Mishmar guards a trading agent: every order you propose is checked by the engine against the account's risk rules before anything reaches the venue, and signed by two parties, neither of which is you. A decision is one of allow (sent to the venue; the venue's acknowledgement is on it), require_approval (parked for a person; use wait_for_decision to follow it, or carry on and read it later) or block (the breached rule and the observed and limit values are on it). Sizes and prices are decimal strings as the venue quotes them (symbol BTC on Hyperliquid, BTCUSDT on Binance). A market order is priced at the engine's mark. A cancel names the resting order's clientOrderId, which its decision carries. Read the trading account and its venue rules first when you do not know the symbols, tick sizes or minimums.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| propose_orderA | Propose an order on a trading account. The engine checks it against the account's rules and, when allowed, signs and sends it to the venue; the decision says what happened. A limit order needs a price; a market order is priced at the engine's mark. Sizes and prices are decimal strings. |
| cancel_orderA | Cancel a resting order this agent placed, by the clientOrderId its decision carries. No rule runs on a cancel and a stopped account still lets it through. |
| get_decisionA | Read one decision of this agent: its verdict, every rule's evaluation, the signing outcome, the venue's acknowledgement and, if it was parked, the approval's state. |
| wait_for_decisionA | Follow a decision parked for a person until it is approved, rejected or expired, or until the timeout; returns the decision as it then stands. |
| list_decisionsC | This agent's recent decisions, newest first. |
| list_positionsA | This agent's open positions, with the mark price and unrealised PnL as the engine last saw them. |
| get_pnlB | This agent's daily PnL (realised, unrealised, fees, funding), by day. |
| list_approvalsC | This agent's proposals that wait for a person, or were decided by one. |
| get_trading_accountC | A trading account this agent may trade on: its venue, kind, status and setup, without any secret. |
| get_venue_rulesA | What the trading account's venue accepts per symbol: tick size, step size, minimums, as the engine last read them. Use it to size and price orders. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool maps to a distinct resource+action: rules, propose, cancel, decision read, decision wait, decision list, positions, PnL, approvals, account. The only mild overlap is between get_decision, wait_for_decision and list_decisions, but the descriptions clearly separate single-read, parked-follow and recent-list semantics. get_venue_rules vs get_trading_account is also differentiated (per-symbol constraints vs account metadata).
All names are snake_case verb_noun with a small, predictable verb set (get_, list_, propose_, cancel_, wait_for_), and the noun always names the resource. No camelCase or style mixing.
Ten tools is well within the sweet spot and each covers a distinct concern (rules, order placement/cancel, decision inspection, approvals, positions, PnL, account). Nothing looks redundant or padded.
The order lifecycle is partially covered (propose, cancel, decision inspection), but there is no list_open_orders or get_order to discover resting orders and their clientOrderIds, so cancellation depends on remembering IDs from decisions. There is also no fills/trade-history tool, which limits reconciliation of the PnL and position data that is exposed.