For the complete documentation index, see llms.txt. This page is also available as Markdown.

MCP server

Local-first Model Context Protocol server for reading Chamber vault state from an AI client.

The Chamber MCP server is a local-first Model Context Protocol server that lets an AI client (Claude Desktop, Cursor, Windsurf, Cline, VS Code, Gemini CLI, ChatGPT Desktop) read Chamber vault state: composition, holdings, NAV, open positions, and trade estimates. Use it to monitor and analyze a vault in natural language.

It's a read-and-analysis surface, not an automation path. To automate trading (rebalancing on a schedule or a signal), build on the SDK or call the contracts directly. Many teams pair the SDK with an LLM to help write and maintain that automation.

Package: @dhedge/chamber-mcp on npm. Model: local-first. There is no hosted server, no user account, no API key. Any keys used are AES-256 encrypted on your machine in ~/.chamber/vaults.json and never leave it.

Package name and tool names remain dhedge/chamber-prefixed in code until those surfaces themselves rename. Prose rebrands; code identifiers don't.

What it reads

  • Vault composition, holdings, metadata, NAV, and total value.

  • Open Toros and Hyperliquid positions and orders.

  • A dry-run estimate of a proposed trade (expected output and gas) without signing anything.

Supported chains

Polygon, Optimism, Arbitrum, Base, Ethereum, Plasma, Hyperliquid. See the deployment matrix for the full network picture.

# Link a vault
npx @dhedge/chamber-mcp vault link --address 0xYourVault --network arbitrum

# List linked vaults
npx @dhedge/chamber-mcp vault list

# Remove a vault
npx @dhedge/chamber-mcp vault unlink --address 0xYourVault --network arbitrum

Configure your MCP client

Add the server to your MCP client config. For Claude Desktop:

Launched as mcp with no -s flag, the server is read-only. The tools below are all it exposes. Cursor, Windsurf, Cline, VS Code, Gemini CLI, and ChatGPT Desktop accept the same command in their MCP settings.

Prerequisites: an MCP client (e.g. Claude Desktop) and Node 18+ (node --version).

Using nvm? Some clients launch npx without your shell environment, so it may not find npx or may resolve an old Node. Point command at the absolute npx path and pin PATH:

Find the path with nvm which current, then restart the client. Its tools indicator confirms the server loaded.

Read-only tools

Tool
Purpose

chamber_list_linked_vaults

Vaults linked on this machine

chamber_get_vault_info

Name, manager, total value

chamber_get_composition

Current holdings and balances

chamber_estimate_trade

Dry-run a trade (gas and expected output)

chamber_get_toros_products

Browse Toros leveraged token products

chamber_get_toros_deposit_assets

Valid deposit assets for a Toros pool

chamber_toros_get_limit_order

Read active limit order

chamber_toros_has_limit_order

Check if a limit order exists

chamber_get_nft_manager_address

NFT manager address for LP protocols

chamber_price_to_tick

Convert price range to ticks for CL pools

chamber_hyperliquid_get_positions

Perp + spot positions and PnL

chamber_hyperliquid_get_open_orders

Unfilled Hyperliquid orders

Beyond read-only

The package also ships trade-execution tools behind opt-in -s scopes (-s trade through -s all, see the package README for the full flag list). They sign with a delegated trader wallet and are bounded by the Guard System. The server can never do anything a human trader couldn't. Two things keep this a secondary path rather than the automation story:

  • Execution depends on the client. The scope only exposes the tools; whether a trade actually runs is up to the client's assistant, and many decline to execute crypto trades, so in practice they stay read-only regardless of scope. A client or model that will sign can drive the full trade surface.

  • For reliable automation, use the SDK. A headless bot executes deterministically; a chat assistant does not, and the trade tools wrap the same SDK, so anything a scope enables you can also do directly in code.

Enable a trade scope only with a client you trust to transact on your vault's behalf.

Configuration

Everything lives under ~/.chamber/:

File
Purpose

.env

RPC URLs and aggregator API keys (loaded on startup)

.key

Machine-local AES-256 encryption key (auto-generated)

vaults.json

Encrypted keys for any linked vault

Common env vars:

Variable
Description

ARBITRUM_RPC_URL, BASE_RPC_URL, POLYGON_RPC_URL, OPTIMISM_RPC_URL, ETHEREUM_RPC_URL, HYPERLIQUID_RPC_URL

Private RPCs per chain. Public RPCs are used as fallback.

ODOS_API_KEY

Improves trade-estimate routing. Get one at odos.xyz.

Safety model

  • Read-only default. Launched with mcp and no -s flag, the server exposes only the read tools above. It cannot move funds.

  • Local key storage. Any keys are AES-256 encrypted with a machine-local key in ~/.chamber/ and never transit the agent, the network, or a hosted service.

  • Guard System. Any execution tools are bounded by the Guard System. The server can't do anything a human trader couldn't.

  • CLI-only linking. Keys are entered at the terminal, never typed into the agent chat.

See also

  • SDK: the automation and execution path (the layer MCP wraps)

  • Trader delegation: how the manager/trader permission split works

  • Guard system: the rules every call is subject to

Last updated