Self-Hosted / Local Development

If you're running the gateway and MCP server locally — local development on this repo, or a fully self-hosted deployment — you don't need a terminal key at all for the MCP connection itself. The stdio transport talks to your local gateway directly.

Configure

{
  "mcpServers": {
    "mtcontext": {
      "command": "node",
      "args": [
        "--env-file=/absolute/path/to/mt_mcp/.env",
        "/absolute/path/to/mt_mcp/packages/server/mcp/src/index.ts"
      ],
      "env": {
        "MTMCP_GATEWAY_URL": "http://127.0.0.1:8081",
        "MTMCP_MCP_TRANSPORT": "stdio"
      }
    }
  }
}

Prerequisites

Bring the local stack up first — the gateway, Postgres, and Redis all need to be running:

pnpm install
docker-compose -f infra/docker/docker-compose.dev.yml up
pnpm dev:gateway

If you also need the MCP server running separately during local tests, start it in another shell:

pnpm dev:mcp

For local development, bind the gateway to loopback (127.0.0.1) and don't put it behind a public-facing endpoint without adding auth — the stdio transport described here assumes no authentication, which is only appropriate for local, trusted use.

Verify

Once the gateway is up and your MCP client is configured, ask for something that requires live data. If you don't have a real terminal connected yet, get_tick and similar tools will return a connection error until an EA is actually attached — that's expected; it confirms the MCP-to-gateway leg of the pipe is working even before a terminal is connected.

Troubleshooting

• Process starts then exits immediately: confirm node --env-file path points to a real .env.
• MCP client cannot spawn server: use absolute paths for both node args and repo files.
• Gateway connection refused: verify MTMCP_GATEWAY_URL and gateway process status.
• Tools register but all calls fail: terminal is not connected yet, or dispatch/auth config is mismatched for your local mode.