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 token → Copy). 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)
- Settings → Connectors → Add custom connector.
- Paste the remote MCP server URL:
https://api.tabbify.io/mcp. - 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
authorizationvalue (it keeps only the schema and domain ofserver_url), so you resendauthorizationon every call. require_approval: "never"skips the human-in-the-loop gate — set it only for a server you trust (yours). Useallowed_toolsto 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.
| Client | Config file | Endpoint key | Top-level key |
|---|---|---|---|
| Cursor | ~/.cursor/mcp.json or .cursor/mcp.json | url | mcpServers |
| Windsurf | ~/.codeium/windsurf/mcp_config.json | serverUrl | mcpServers |
| VS Code (Copilot) | .vscode/mcp.json (set type: "http") | url | servers |
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.