Documentation
ReferenceArchitecture

Connect an MCP client

Tabbify exposes your whole office as a Model Context Protocol (MCP) server, so an AI assistant can deploy apps, inspect your mesh roster, and edit a connected repo (commit + redeploy) — the same actions you take in the console, driven from your assistant.

It's one endpoint, served by the node alongside the REST API:

https://api.tabbify.io/mcp

Two ways to authenticate

  • OAuth — recommended for interactive clients. The node exposes a full OAuth 2.1 surface (/.well-known/oauth-protected-resource/authorize/token, with dynamic client registration), so your client discovers it automatically and opens a browser consent screen. Nothing to paste. Use this for Claude.ai, Claude Desktop, and Claude Code.
  • Bearer token — for headless / CI clients. Mint a token and send it as Authorization: Bearer <token>. Use this for the OpenAI Responses API and any client that can't run the interactive flow.

Mint a token under MCP → Get a token in the console (pick a network → Get MCP tokenCopy). It's shown once and is valid for a year; revoke it any time from Deploy tokens. The console also shows a ready-to-paste config with the token already filled in.

Claude

Claude.ai and Claude Desktop (OAuth)

  1. Settings → ConnectorsAdd custom connector.
  2. Paste the remote MCP server URL: https://api.tabbify.io/mcp.
  3. Leave Advanced settings empty — Tabbify supports dynamic client registration — then click Add, Connect, and sign in. No token to paste.

Claude Code (OAuth)

Add the server with no header, then authenticate in the browser:

claude mcp add --transport http tabbify https://api.tabbify.io/mcp
# then, inside Claude Code:
/mcp

Claude Code (Bearer token — for CI / no browser)

Add it with the token as a header, or drop the JSON into your project's .mcp.json:

claude mcp add --transport http tabbify https://api.tabbify.io/mcp \
  --header "Authorization: Bearer <token>"
{
  "mcpServers": {
    "tabbify": {
      "type": "http",
      "url": "https://api.tabbify.io/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Use either OAuth or a Bearer header — not both. If you set the header and the token is wrong, Claude Code fails the connection instead of falling back to OAuth.

OpenAI

Responses API (Bearer token)

Pass Tabbify as a remote MCP tool. The authorization field is a string that OpenAI forwards verbatim as the Authorization header, so include the Bearer prefix:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.5",
    "tools": [
      {
        "type": "mcp",
        "server_label": "tabbify",
        "server_url": "https://api.tabbify.io/mcp",
        "authorization": "Bearer <token>",
        "require_approval": "never"
      }
    ],
    "input": "List my Tabbify apps"
  }'
from openai import OpenAI

client = OpenAI()  # reads OPENAI_API_KEY

resp = client.responses.create(
    model="gpt-5.5",
    tools=[
        {
            "type": "mcp",
            "server_label": "tabbify",
            "server_url": "https://api.tabbify.io/mcp",
            "authorization": "Bearer <token>",
            "require_approval": "never",
            # "allowed_tools": ["list_apps", "deploy_pipeline"],  # optional allow-list
        }
    ],
    input="List my Tabbify apps",
)
print(resp.output_text)

Two things to know:

  • OpenAI does not store the authorization value (it keeps only the schema and domain of server_url), so you resend authorization on every call.
  • require_approval: "never" skips the human-in-the-loop gate — set it only for a server you trust (yours). Use allowed_tools to restrict which tools the model may call.

ChatGPT (OAuth, beta)

Custom MCP connectors in the ChatGPT app are developer-mode beta (Plus / Pro / Business / Enterprise / Edu, web). Enable Settings → Apps → Advanced → Developer mode, choose Create app, paste https://api.tabbify.io/mcp, and pick OAuth — the ChatGPT UI has no field for a static token, so it connects through the OAuth flow.

Other clients

The same endpoint works anywhere MCP does; only the config key names differ. Each uses the header name exactly Authorization with a Bearer prefix.

ClientConfig fileEndpoint keyTop-level key
Cursor~/.cursor/mcp.json or .cursor/mcp.jsonurlmcpServers
Windsurf~/.codeium/windsurf/mcp_config.jsonserverUrlmcpServers
VS Code (Copilot).vscode/mcp.json (set type: "http")urlservers

For example, Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "tabbify": {
      "url": "https://api.tabbify.io/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Most of these support environment-variable interpolation (e.g. "Bearer ${env:TABBIFY_TOKEN}" in Cursor/Windsurf, or a ${input:…} secret in VS Code) so the token doesn't sit in a committed file.

What you can do over MCP

Once connected, the assistant has the same verbs as the Node API:

  • Deploy a connected repo to your mesh (deploy_pipeline) — the same one-call flow as the console.
  • Inspect your roster: which supervisors are online, which apps run, and where (list_supervisors, list_apps, get_app).
  • Control an app's lifecycle (start_app, stop_app, reset_app).
  • Edit a connected repo in place — make a change, commit it, and redeploy, all from the assistant.

See the Node API for the full REST + MCP surface, the deploy pipeline for what a deploy does, and auth for how tokens are issued.