Architecture

Layers

Layer Role
Tray Desktop control plane: API key, Cursor dir, optional MCP lifecycle, constitution .mdc under .cursor/rules/, tray status tied to RC-API health in modern builds.
Cursor MCP client; launches the MCP process defined in mcp.json.
MCP (server_workflow) Stdio server exposing recloud tool; loads catalog from GET /tools/list-all; routes each subcommand via ToolDispatcher (local handlers vs POST /tools/execute on RC-API).
RC-API Workflow engine, catalog (*.public.mdc / *.private.mdc), auth middleware, model calls as configured.

Request path (tools)

sequenceDiagram
  participant C as Cursor
  participant M as MCP server
  participant A as RC-API

  C->>M: tools/call recloud(subcommand, parameters)
  M->>M: ToolDispatcher.dispatch
  alt execution_target remote (typical)
    M->>A: POST /tools/execute (Bearer RC_API_KEY)
    A-->>M: workflow result
  else local / hybrid / graph
    M->>M: local handler or graph engine
  end
  M-->>C: MCP result

Tray is not in the hot path for each tool call; it prepares config on disk and reflects status.

Catalog source of truth

  • Tool list and execution_target come from RC-API (75 *.public.mdc entries in the reference tree; numbers change as you add/remove tools).
  • MCP registers one IDE tool; subcommand enum follows that catalog.

Constitution / rules

  • Tray writes assembled rules into <cursor-user-dir>/rules/recloud-behavior.mdc using fragments fetched from RC-API /rules/... endpoints.
  • MCP may additionally apply runtime constitution behavior depending on build; the file-based path is the operator-visible contract.

Related

Slopbook® Engine - powered by Slopman