The same server, three hosts
You wrote daybreak-mcp once. A host is any AI app that speaks MCP - Claude Code, Claude Desktop, Cursor, VS Code. Each connects to your server by configuration, not code: point it at the command that launches your server, and the same handshake and tools/list you have been reading all track runs automatically. Nothing in server.py changes. That interoperability is the entire promise of MCP, and tonight you cash it in.
.mcp.json and into Claude Desktop via claude_desktop_config.json, a clear rule for which of the three scopes to use when, the tool-naming convention that tells you a server landed (mcp__daybreak__query_sales), and a reference server running alongside your own in the same host.
Claude Code: .mcp.json and scopes 8 min live
Claude Code configures MCP servers at three scopes, and the scope decides who sees the server and where the config lives. Precedence runs local > project > user: if the same server name is defined at more than one scope, the more specific one wins. Get the scope right and you never fight config again.
LiveScope decision guide4 min▶
The rule is about audience, not difficulty. Ask "who should have this server?" and the scope falls out:
- Experimenting alone? Use local. Private to you and this project, gone when you clean up. Nothing leaks into a repo.
- Team repo where everyone needs it? Use project. The
.mcp.jsonis checked into the repo root, so every teammate who clones gets Daybreak with no setup. - A tool you want in every project? Use user. Your personal toolbox - a reference filesystem server, say - available everywhere you work.
Here is the project-scope config. It lives at the repo root as .mcp.json and gets committed:
command+args- exactly how to launch your stdio server; the host runs it as a subprocess.envsupports variable expansion:${VAR}and${VAR:-default}pull from the environment, so secrets and paths never get hard-coded into the checked-in file.
LiveVerifying a server landed4 min▶
Two ways to confirm Claude Code actually loaded your server. First, run /mcp in the session - it lists connected servers and their status. Second, look at how the tools are named:
mcp__daybreak__query_sales- the host prefixes every tool withmcp__and the server name from your config. Seeing this prefix is proof the server connected and its tools are namespaced.- The server name comes from the JSON key (
"daybreak"), not fromFastMCP("daybreak-mcp")- name the key deliberately, because it shows up in every tool name. - If
/mcpshows the server failed, the command in your config threw - run it by hand in the terminal to see the error, exactly like the Inspector failures in b2.
Claude Desktop and beyond 7 min live
Claude Desktop uses a single config file, claude_desktop_config.json, with the same mcpServers shape you just wrote - command and args. Edit it, restart Desktop, and your server appears. This is the payoff moment: the identical server.py now runs in a second host, and you changed zero lines of Python.
LiveDesktop config walkthrough4 min▶
Open Desktop's settings, go to Developer, click Edit Config, and add Daybreak. The file lives at:
- Absolute paths. Desktop does not launch from your project folder, so pass
--directorywith the full path - a relative path is the number-one Desktop failure. - Restart to load. Desktop reads this file only at startup. Fully quit and reopen - not just close the window - for the server to appear.
- Same shape as
.mcp.jsonunder the hood:mcpServers,command,args, optionalenv. Learn it once.
Self-studyVS Code, Cursor, and the rest3 min read▶
The host list keeps growing, and they all consume the same server. You do not relearn MCP per host - you learn where each keeps its config:
- VS Code (via GitHub Copilot) and Cursor both support MCP servers through their own settings, using the same
command/args/envidea. - The pattern is universal: a host needs the launch command and, for remote servers, a URL. That is the whole contract.
- This is why interoperability is the point. You wrote Daybreak once in b2 and b3; every host above runs it unchanged. Adding a host is config, never code.
Reference servers 6 min live
You are not the only server in the host. The MCP project ships official reference servers - filesystem, git/github, memory, and more - that you can install alongside Daybreak. A host with several servers is the normal case, and the tool-name prefix is what keeps them straight.
LivePairing your server with reference servers4 min▶
Add a reference server next to Daybreak in the same config. The filesystem server is the classic pairing - now the model can read a file and query your sales in one conversation:
Reload, and /mcp lists both. The tools are namespaced - mcp__daybreak__query_sales and mcp__filesystem__read_file - so nothing collides. Now watch the handshake that every one of these servers runs when the host starts it:
Wire Daybreak into Claude Code ★ 12 min · everyone connects
Do it live. Four moves from a checked-in config to a real answer about March in a real chat.
Write .mcp.json at your repo root with the project-scope config from Part 1. Commit it - that is what "project scope" means.
Reload Claude Code in that directory and run /mcp. Confirm daybreak is connected.
Ask, in plain English: "How did March look?" The model finds mcp__daybreak__query_sales, fills month=2026-03, and calls it.
Read the answer. It reports completed revenue $150.00 with one refund - your server, your data, a real host, no code changes.
Same server, Claude Desktop ★ 8 min · connect
Now the second host, to feel the payoff: identical server, different config file, one restart.
Edit config. Desktop settings -> Developer -> Edit Config. Add the daybreak block from Part 2, with the absolute --directory path.
Restart Desktop fully - quit and reopen, not just close the window. It reads the config only at startup.
Verify. Open the connectors indicator and confirm daybreak lists its three tools.
Ask "how did March look?" again. Same $150 answer, second host, still zero changes to server.py.
Try it yourself - this week ◐ 25-35 min total
- Add a reference server at user scope so it follows you into every project - the filesystem or memory server is a good first choice. Confirm with
/mcpfrom a different project directory. - Write your own one-paragraph scope policy: which servers your team should put at project scope (checked in) versus user scope (personal), and why. This is the same judgement the leader track calls governance.
- Deliberately create a name collision: define
daybreakat both local and project scope with different commands, and confirm local wins. Then delete the local one. - Ask a question that needs two servers at once ("read notes.txt and tell me if March matches"). Watch the model call one tool from each namespace in a single answer.
Official sources covered
This session teaches the working core of the host-connection docs across the official sources, on the running project. Certificates and videos stay official. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · The same server name is defined at local and user scope. Which wins?
Precedence is local > project > user: the most specific scope wins. A local definition overrides both project and user for that server name.
2 · Where does a project-scope .mcp.json live, and what happens to it?
Project scope means .mcp.json sits at the repo root and is committed. Every teammate who clones the repo gets the server with no extra setup - that is the point of the scope.
3 · You edited claude_desktop_config.json but the server does not appear. Most likely fix?
Claude Desktop loads MCP config at launch. After editing the file you must fully quit and reopen the app (not just close the window) for the new server to load. A relative path is the other common culprit.