Claude Code

Live-proven with an API key OAuth: built and tested, not run live

What Zyx serves and which gates apply: Use Zyx from your AI tool.

With an API key

1. In Zyx, open Manage, API & MCP and make a key for the person Claude Code acts as. Tick read, and tools if it may change things.

2. Paste the line the screen shows:

   claude mcp add --transport http zyx https://zyx.example.com/api/mcp \
     --header "Authorization: Bearer <key>"

   To work inside one folder, add ?folder=<folder> to the URL and give the server its own name, for example zyx-client.

   A staff member who wants their own mail, Notion or other own sign-ins to answer adds ?private=1 instead, for example as zyx-private. The calls then run in their private chat: only they read it, and every approval it asks for is theirs alone.

3. In Claude Code, /mcp lists zyx as connected, and its tools appear as mcp__zyx__<tool>.

With OAuth

This needs the operator to publish Zyx’s MCP and OAuth paths (see the overview). Add the server without a header, then sign in from /mcp:

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

Zyx’s consent screen asks for your Zyx sign-in and the scopes. The grant shows on the keys screen labelled OAuth; revoke it there.

Zyx’s screens inside Claude Code

An optional Claude Code mod, zyx-screens, adds a status line (waiting, working, failed, session cost) and a /zyx pane with the waiting cards, the files touched and the sources cited. A person can press Approve or Reject there with a separate key that has only the approve scope. That key never goes into the MCP config, so Claude Code itself can never approve.

What was proven

• A Claude Code session with the API key setup above called a Zyx tool against an installed Zyx and got the answer back.
• The OAuth path is proven by an automated test with the MCP SDK’s own OAuth client, not from a Claude Code session over a public address.