PROJECT.md 2.1 KB

exec-mcp project outline

Purpose

exec-mcp is the execution layer for the Trader27 stack. It sits between strategy logic and real exchange APIs, and is responsible for authenticated trading actions and exchange/account metadata.

Proposed architecture

1. Data layer

  • Crypto MCP provides technical market data
  • News MCP provides sentiment and event context

2. Strategy layer

  • Trader client runs the strategy loop
  • Can be a UI-backed controller rather than a pure MCP server
  • Chooses market, strategy, behavior, and risk settings
  • Consumes data from Crypto MCP and News MCP
  • Produces order intents

3. Execution layer

  • Exec MCP owns exchange access tokens
  • Handles account configuration, routing, and exchange-specific metadata
  • Executes orders and maintains order lifecycle state
  • Supports query and cancellation flows

Responsibilities of exec-mcp

  • list_accounts, optionally filtered by exchange
  • get_account_info(account_id)
  • expose commission / fee data through account info
  • expose precision, decimals, minimum size, step size, and other exchange rules through account info
  • keep the public MCP surface read-only for now
  • support multiple exchanges
  • support multiple accounts and subaccounts per exchange
  • keep secrets out of the strategy/UI layers

Desired properties

  • FastMCP-native
  • modular exchange adapters
  • audit-friendly
  • safe around retries and partial fills
  • paper-trading capable
  • restart-safe state handling
  • easy to extend with new exchanges

So far

We have a clear separation of concerns:

  • Crypto MCP = market data and technical insight
  • News MCP = sentiment and context
  • Trader = strategy logic and UI/control surface
  • Exec MCP = account and order execution

The open design question is mostly implementation detail, not architecture viability. This appears sane, feasible, and worth further analysis.

Suggested next build items

  1. define the FastMCP server skeleton
  2. define account metadata models
  3. define order request / response schemas
  4. define exchange adapter interface
  5. add paper-trading / dry-run mode
  6. add logging and audit trail
  7. add tests around routing and order state