Connecting AI Agents via MCP

MCP setup happens in your external client, not inside m18t. Point an MCP client at https://m18t.com/mcp, authenticate with a bearer token, and pick a brand

What you'll learn

  • Where MCP setup actually happens (your external client, not inside m18t).
  • How to point an MCP client at the m18t endpoint and authenticate it.
  • How brand scoping and token expiry work in practice.

The concept

m18t speaks the Model Context Protocol (MCP), a standard for letting an AI agent call typed tools against a system. m18t is the server; your AI tool — an IDE assistant, a terminal agent, a desktop client — is the client.

The important thing to get right up front: there is no MCP screen inside m18t. You don't configure agents in the Studio. All setup happens in the external client, by editing its config to add the m18t server. m18t just exposes the endpoint and checks your token on every tool call.

The endpoint is https://m18t.com/mcp. The connection handshake itself is unauthenticated, but every actual tool call is workspace-gated by the token you supply — without a valid token, an agent sees only the server's name and instructions, no data.

How to connect a client

  1. Get your token. Authenticate with your m18t Personal Access Token (PAT) as a Bearer token. It must belong to a user with a selected business. A PAT can expire, so expect to refresh it periodically (see the FAQ).

  2. Open your client's MCP config. Every MCP client has a config file or settings panel where you register servers. The exact location varies — a terminal agent might use a claude mcp add-style command; a desktop or IDE client edits a JSON config. Check your client's own MCP docs for where its server list lives.

  3. Add the m18t server. Register a remote HTTP MCP server at https://m18t.com/mcp with an Authorization: Bearer <token> header. The generic shape most clients accept:

    {
  "mcpServers": {
    "m18t": {
      "url": "https://m18t.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_M18T_PAT_HERE"
      }
    }
  }
}

    Clients that only launch local commands (not remote URLs) need an HTTP-bridge wrapper — consult your client's docs for its remote-server pattern.

  4. Reload the client so it re-reads its config and connects. Your client should now list m18t's tools.

  5. Tell the agent which brand to use. Every brand-scoped tool takes an explicit brand. Have the agent call list_brands first, then pass the right brand on each call. (If your workspace has exactly one brand, tools default to it.)

Variations

  • Multiple brands, one connection. You don't connect once per brand. One connection covers the whole workspace; the agent moves between brands by passing a different brand on each tool call.
  • Read-only by habit, not by lock. The surface includes create and update tools, but no delete. If you want an agent to only read, instruct it to — there is no separate read-only token today.

FAQ

I get a 401 / "access denied" — what's wrong? Almost always an expired or wrong token. Your Personal Access Token may have expired. Generate a fresh PAT in m18t, copy it into your client's config, and reload. Also confirm the token belongs to a user with a selected business.

The connection succeeds but no tools show up. The handshake works without a valid token, but the data tools stay hidden until a valid Bearer token resolves to a workspace. If you see the server but no tools, your token didn't resolve — re-check it.

Is the endpoint https://m18t.com/mcp or mcp.m18t.com? Use https://m18t.com/mcp. The /api/mcp path is the auth-walled app prefix and hosts no MCP handler; an mcp.m18t.com subdomain is planned but not the live endpoint.

Can I configure MCP from inside m18t? No. There is no in-app MCP UI. Setup lives entirely in your external client's config.

Why does the agent ask me which brand to use? Because every brand-scoped tool requires an explicit brand to prevent cross-brand leakage. Have the agent run list_brands and operate on the one you name.

What's next

Was this article helpful?