AI agents (MCP)

BeziSync speaks the Model Context Protocol, so agents such as Claude Code, Claude Desktop, ChatGPT, Codex, Gemini CLI, Cursor, VS Code or Windsurf can list, build, check, deploy and operate pipelines for people. An Admin turns it on in Settings → MCP; the endpoint is <public URL>/api/v1/mcp (Streamable HTTP). Account → AI agents shows everyone how to connect: pick your agent and it shows that client's own command or config (ChatGPT signs in only; the rest also take an API token). For example:

claude mcp add --transport http bezisync https://bezisync.example.com/api/v1/mcp

Two ways in, each switchable in Settings → MCP:

Sign in (OAuth 2.1). The agent finds BeziSync's authorization server from the endpoint's 401 (/.well-known/oauth-protected-resource), registers itself, and opens BeziSync in the browser. The person picks which projects it may open (one or all of theirs), whether it may only read, and for how long (an Admin sets the maximum). New agents can be usable at once or wait for an Admin. People see and disconnect their agents under Account; Admins see every agent and connection in Settings → MCP and can block or remove an agent.
API tokens. A token from Account → API tokens in the agent's Authorization: Bearer header. A read-only token gives read-only tools; a project-scoped token one project; revoking the token disconnects the agent. The dialog that shows a new token once also shows the Claude Code command with the token filled in, and Account → AI agents has the steps under API token:
```
claude mcp add --transport http bezisync https://bezisync.example.com/api/v1/mcp \
  --header "Authorization: Bearer bzt_…"
```
Clients configured with JSON (Cursor, VS Code, Windsurf, Claude Desktop through mcp-remote, …) take the same header; Codex reads it from an environment variable (--bearer-token-env-var). The generic form:
```
{
  "mcpServers": {
    "bezisync": {
      "type": "http",
      "url": "https://bezisync.example.com/api/v1/mcp",
      "headers": { "Authorization": "Bearer bzt_…" }
    }
  }
}
```
To check a token, list the tools it may use:
```
curl -s https://bezisync.example.com/api/v1/mcp -H "Authorization: Bearer bzt_…" \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

Tools follow the person. Each request only lists the tools the person's live roles allow (an Editor gets no Admin tools, a viewer no write tools), and every tool calls BeziSync's own API as them: permissions, validation, policies, approvals ("deploy" asks for approval where required) and the audit log (the actor reads email (token MCP · <agent>)) work exactly as in the app. Tools that delete or reset (delete a pipeline, reset offsets, …) are off until an Admin turns them on; Admins can turn any tool off.

No credentials. No tool takes or returns a password, key or token: creating API or agent tokens, runtime, secret-store and alert-channel credentials, sign-in providers, passwords and the MCP settings themselves are left to people in the app. A connection's secret fields can only be secret-store references (ref+vault://…); event previews always mask personal data.