Mishmar
OfficialRelated Servers
Alternatives to Mishmar
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to trade Hyperliquid perpetuals and Polymarket prediction markets and earn yield (HYPE staking, HLP, USDC lending) from self-custodial wallets, with server-enforced limits, signed operations outside the MCP boundary, and a kill switch.MIT
- AlicenseAqualityBmaintenanceEnables AI agents to place and manage Hyperliquid trades through MCP with position, leverage, daily-loss, market, and stop-loss limits enforced outside the model, plus paper trading and an auditable decision log.9109 npmMIT
- AlicenseAqualityBmaintenanceOrder limits, human approval (terminal or Telegram), a kill switch and a hash-chained audit log in front of any broker or exchange MCP server. Verified profiles for Alpaca MCP and CCXT MCP.9412 npmMIT
- AlicenseAqualityBmaintenanceAn MCP server that lets AI agents read Hyperliquid perpetual futures market data and their own account state, then place and cancel orders, adjust leverage, move USDC from spot to perp, and convert stablecoins to USDC. It holds no credentials and never contacts the exchange, routing every request through a runtime that enforces caps and signs server-side.9Apache 2.0
- AlicenseNot gradedqualityAmaintenanceLocal, advisory-only pre-trade risk gate for AI trading agents. 12 deterministic fail-closed rules return PASS/WARN/BLOCK with reasons and a local hash-chained audit log. Never places orders and needs no broker credentials. Early-stage open source (MIT).MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI trading agents to trade safely through any broker MCP server by recording every tool call and reasoning in a local blackbox, while enforing configurable guardrails such as symbol whitelists, order size caps, rate limits, and daily-loss circuit breakers before orders reach the exchange.MIT
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.