MCP Authentication

Overview

The DMTR MCP server authenticates to the DMTR API on behalf of the user. The user provides credentials (API key or OAuth token) when configuring the MCP client; the server uses these for all DMTR API calls. There is no separate MCP-level auth—the server is a pass-through that forwards requests with the user's credentials.

Authentication

Authentication is via DMTR API key. Set DMTR_API_KEY in the environment or in the MCP server config. The server includes the key in the Authorization header for every DMTR API request. For OAuth flows, the server can use a refresh token; the client must supply the token (or path to it) at startup. Sandbox and production use different keys.

Authorization

Authorization is enforced by the DMTR API. The API key is scoped to an organization and optional workspace. The MCP server does not add its own authorization layer; it forwards requests and returns whatever the API allows. If the API returns 403, the MCP server surfaces that error to the client.

Scoping

API keys can be scoped to specific permissions (e.g., read-only vs. read-write). MCP tools that perform writes (e.g., express-intent) require write scopes. The server does not restrict tool availability based on scopes; it relies on the API to reject unauthorized calls. Use least-privilege keys for MCP to limit blast radius.

Token management

API keys are long-lived; store them securely (env vars, secret manager, or encrypted config). Do not log keys. For OAuth, the server may cache refresh tokens in memory; they are not persisted to disk. Rotate keys periodically and revoke compromised keys in the DMTR dashboard.

@dmtr/mcp energy server posture

The energy MCP server (@dmtr/mcp) ships with a deliberately narrow auth posture for v0.5.0.1's staging-only lane:

• Stdio transport only. The MCP client (Claude Desktop, Cursor, custom agent) spawns the server as a local subprocess and communicates over stdin/stdout. The server is local-and-trusted by definition; no MCP-level Bearer token attached.
• HTTP / SSE transport intentionally not exposed. When HTTP transport is added in a focused follow-on, that mode MUST add a Bearer-JWT auth layer matching the existing /v1 REST API. Until then, do not expose the MCP server over the network.
• API forwarding. Reads against the underlying DMTR REST API (DMTR_API_URL, default http://localhost:3100/v1) are unauthenticated in the sandbox lane — matching the v0.5.0.1 staging posture. Production HTTP exposure adds the Bearer layer end-to-end.
• Mutation surface is minimal. Of the ten energy tools in this version, only submit_demand mutates server state. Adding tools that advance stage gates, decompose slots, sign contracts, or issue dispatch notices is feasible but deferred until HTTP + per-session auth lands.