One command adds your DenkOps connector to Claude Code:
claude mcp add --transport http my-tools https://my-tools.denkops.host/mcpClaude Code registers the server, and when it needs to authenticate it hands you off to the browser: the hosted login and consent screen opens, you approve, and you are back in the terminal with working tools. No config files to hand-edit, no tokens to copy.
This assumes your server is deployed with "connector": true, so it lives at https://<slug>.denkops.host/mcp with OAuth in front of it. That setup is one line in denkops.json, covered in the one-flag OAuth post.
How does the OAuth handoff work?
The same way it does for every MCP client, because the platform serves a standard flow. Claude Code fetches the discovery metadata from your connector's domain, registers itself via dynamic client registration, and opens your browser at the login and consent screen. You sign in, approve, and the CLI receives its token.
Inside a session, the /mcp command shows your configured servers and their connection state, and lets you trigger or redo authentication for a server that needs it. If a connector ever shows as disconnected, /mcp is the first place to look.
Whether your login succeeds is decided by the connector's access policy, not by anything on the client side. The project owner sets it in the dashboard's Access tab: public, or an allowed-email list. If you are not on the list, the refusal happens at login, before any tool call.
Which scope should I use?
claude mcp add can store the server config at different scopes, and the choice matters more in a CLI than in a chat app:
- Local (the default): the server is available to you, in this project only. Good for trying things out.
- Project (
--scope project): the config is written to a.mcp.jsonfile in the project root, meant to be committed. Everyone who clones the repo gets the connector offered automatically. Each person still completes their own OAuth login, which is exactly what you want: shared config, individual identity. - User (
--scope user): available to you across all your projects. Right for personal tools you use everywhere.
For a team connector, project scope plus an allowed-email access list is the clean setup: the repo carries the URL, the dashboard controls who can actually connect, and every grant is auditable.
Using the tools in a session
Once connected, the tools join everything else Claude Code can do. Ask for the outcome, not the tool: if your connector exposes a search_orders tool, "find the orders from last week that failed" is enough. Claude Code reads the tool descriptions and input schemas from your server and decides when to call what. Tool descriptions are the interface, so write them for a reader who has zero context.
Because the server is a hosted connector rather than a local stdio process, there is nothing to start or keep running on your machine, and the same URL serves your teammates and every other client.
Same connector, other clients
The DenkOps side never changes: one URL, hosted OAuth, dynamic client registration, owner-controlled access. Only the paste-step differs. The same server works in Claude web and desktop, ChatGPT, and OpenAI Codex.