Connect any MCP client

Prerequisites

• The CodeMonster desktop app, signed in with your organization license. It shows the exact server URL and the token for your session. Desktop builds are being finalized for launch — request access and we send the installer link the day the build for your operating system ships.
• An MCP-compatible agent on the plan you already pay for, able to connect over HTTP+SSE and attach an Authorization header. CodeMonster does not meter it, mark it up or resell it.
• If your client can only spawn local servers over stdio, use the command the desktop app shows instead of the URL; the operations and the guardrails are identical on both transports.

Configuration

{
  "mcpServers": {
    "codemonster": {
      "type": "sse",
      "url": "<server URL shown in the desktop app>",
      "headers": {
        "Authorization": "Bearer <token shown in the desktop app>"
      }
    }
  }
}

The block above is the common shape; your client’s config file may name the keys differently, so map them: a server URL, and a bearer token in the Authorization header. Both values are placeholders — take the real ones from the desktop app after sign-in.

Every request carries the token. The one unauthenticated endpoint is /health, which returns {"ok":true} and nothing more, so use it to confirm the server is reachable before you debug authentication.

About the token: it carries your identity and nothing more — the platform authorizes every call with your own permissions, so it can never do more than you can. It belongs to your signed-in desktop-app session, not to the machine, and signing out ends it. Keep it out of prompts, tickets and repositories; lifetime, rotation and admin-side revocation controls are being finalized for launch.

First calls

Ask the agent to run them in that order. ping proves the connection and whoami confirms the account; list-tenants and then use-tenant set the tenant context, and no data write goes through without it.

get-domain-knowledge hands the agent the platform’s conventions — build order, object prefixes, groups first, publish to land. list-solutions shows what exists; create-solution starts something new.

Verify it worked

• ping answers, and whoami returns your email and your account. A 401 here means the token is wrong; see below.
• list-tenants returns at least one tenant, and use-tenant echoes the one you chose.
• A data write attempted before use-tenant fails fast with Tenant context required. That failure is the guardrail working.
• After get-domain-knowledge, the agent’s next plan uses the platform’s own vocabulary: objects, forms, screens, groups.

Troubleshooting

• No tools listed, or a connection that never opens — the transport is wrong for your client. If it cannot hold an SSE stream, use the stdio command the desktop app shows instead of the URL.
• 401 — the header is missing, the token is expired or revoked, or the Bearer prefix was lost. The server returns nothing else: no tool list, no schema, no server info. If /health answers but tools do not, the problem is the token. Copy it again from the desktop app.
• Tenant, transaction and freeze errors — Tenant context required, concurrent_mutation_blocked, staged edits vanishing after 60 idle seconds, and 403 on a solution frozen against AI edits (allowMcpEdits off, set per solution on the platform side) behave the same on every client. Each one, and what to do about it, is documented once on the control surface.

Next

• Build something real: the field-service inspection blueprint is a starter prompt plus the primitives map.
• Read the control surface for every operation family and the transaction lifecycle.
• The full reference is being published on codemonster.dev; /docs tracks its status. Until it is live, get-domain-knowledge is the reference your agent reads.