An MCP server is how you give a coding agent tools it did not ship with: your issue tracker, your database, your internal API. Verboo Code adds one with a single command. The two things people get wrong are which scope the config lands in and which transport the server speaks.
This walks through both, plus the diagnostic command for when the server refuses to connect.
How do I add an MCP server?
The command is verboo mcp add. Its shape is the same regardless of transport:
verboo mcp add <name> <commandOrUrl> [args...]What changes is the transport. There are three, and Verboo Code assumes stdio when you do not say otherwise.
A remote server over HTTP
verboo mcp add --transport http sentry https://mcp.sentry.dev/mcpA remote server that needs a header
verboo mcp add --transport http corridor https://app.corridor.dev/api/mcp \
--header "Authorization: Bearer ..."--header repeats. Pass it once per header.
A local server over stdio
verboo mcp add -e API_KEY=xxx my-server -- npx my-mcp-serverThe -- matters. Everything after it becomes the subprocess command line instead of being parsed as flags for verboo, which is what lets you pass flags to your own server:
verboo mcp add my-server -- my-command --some-flag arg1Two errors that look like the same mistake. Leaving out the name gives you Error: Server name is required. Leaving out the command gives you Error: Command is required when server name is provided. Both print the usage line, so read which of the two you got before retrying.
Which scope should I use?
This is the flag that decides who else sees the server, and the default is the narrowest one.
| Scope | Where the config lives | Use it when |
|---|---|---|
local (default) | Only this machine, only this project | You are trying a server out, or it holds a personal token |
project | Travels with the repository | Everyone working on this codebase needs the same server |
user | Your machine, every project | A server you want everywhere, like your notes or your tracker |
verboo mcp add --scope project ci-tools https://internal.example.com/mcp --transport httpThere is a fourth scope you can read but not write. verboo mcp doctor accepts enterprise as a scope to inspect, while verboo mcp add only accepts local, user and project. If your team has enterprise-level MCP config pushed down, you diagnose it from the CLI but you do not edit it there.
What about servers behind OAuth?
Three flags cover it, and they only apply to HTTP and SSE transports:
--client-id <id> | The OAuth client ID |
--client-secret | Prompts for the secret. You can set MCP_CLIENT_SECRET instead of typing it |
--callback-port <port> | Pins the callback port, for servers that require a pre-registered redirect URI |
The pinned port is the one worth remembering. Plenty of OAuth providers reject a redirect URI they have not seen before, and a random port fails every time without saying why.
The server will not connect. What now?
Run the diagnostic against the server by name:
verboo mcp doctor my-serverIt reports on configuration, precedence between scopes, whether the server is disabled or pending, and connection health. Three flags change how it behaves:
| Flag | What it does |
|---|---|
--config-only | Analyses configuration only. Starts no process, contacts no remote server |
-s, --scope <scope> | Restricts the analysis to one scope: local, project, user or enterprise |
--json | Emits the report as JSON, for a script or a CI step |
Read this before running it in a directory you did not write. The command's own description says it plainly: unless --config-only is passed, stdio servers may be spawned and remote servers may be contacted. A project-scoped MCP config that arrived with a cloned repository is code you are about to execute. In an unfamiliar checkout, start with --config-only.
How do I turn a server off without removing it?
Inside a session, the /mcp slash command handles it. Its argument hint is [enable|disable [server-name]]:
/mcp opens the MCP settings panel
/mcp disable my-server turns off one server
/mcp disable turns off all of them
/mcp enable my-server turns it back on
/mcp reconnect my-server reconnects without restarting the sessionOmitting the server name targets all servers, which is convenient and occasionally surprising. And if everything is already in the state you asked for, it tells you so rather than pretending it did something: All MCP servers are already disabled.
reconnect is the one people miss. When a remote server drops, the reflex is to restart the whole session and lose the context you built. Reconnecting the single server keeps it.
The order that actually works
- Add with the narrowest scope that makes sense.
localis the default for a reason. Promote toprojectonce you know the server is worth committing. - Approve it. Verboo Code asks before letting a new server into the session. That dialog is the security boundary, not a formality.
- If it does not connect, run
doctorwith--config-onlyfirst. Most failures are configuration, and the config-only pass tells you that without executing anything. - Only then let it try the live connection.
Every command above came from reading the source of verbeux-ai/code on 3 September 2026, in src/commands/mcp/. The flags, the defaults and the error strings are what the code does, not what a changelog claims.
That is the same reason the agent gets to read the whole repository before answering: on Verboo Code the models run on dedicated GPU with unlimited tokens, so reading three files or thirty costs the same.
MCP is worth the setup precisely because it stops being setup. Once the server is added at the right scope, the tools are simply there, in every session, and the agent stops guessing at things it could have looked up.
