3 connect prompts · 4 checks · run them in order and your second brain gains its first real MCP connections
Every move from the closing demo lives here, consolidated and cleaned up. Each one says what it is for and what you should see when it lands. Open a terminal in your second brain repo, type claude, and paste them in order. Rephrasing in your own words works just as well. If a result does not match, ask Claude what it did differently, fix that step, and keep going.
Anthropic maintains a small set of official reference MCP servers, and they are the safest possible first connection: known author, open source, nothing to sign up for. This one connects at personal scope on purpose; your first experiment should not ship to teammates.
i want to try connecting an MCP server. find anthropic's official reference MCP servers and connect the one called fetch, just for me in this repo, not for the team. if fetch won't run on my machine, use the one called memory instead. then tell me what tools it added and what they do
What you should see: Claude registers the MCP server in your personal config (no new committed file, because this is just for you), and after a restart the inventory shows the MCP server's tools under their long names. If the connection fails, ask Claude what the MCP server needs installed and let it walk you through it.
Pick a system your team actually uses: Jira, Confluence, GitHub, Notion, Slack. This prompt makes Claude do the vetting legwork and show its sources, which is exactly the artifact you would bring to a client conversation.
we use confluence. find the official MCP server for it, published by the vendor itself, and run our three questions against it: who wrote and maintains it, what data does it send and where does it go, and what access would it hold. give me the answers with sources, and tell me plainly if any answer is missing
What you should see: Three answers naming the vendor as the author, pointing at its documentation for the data path, and describing access as scoped to the account you sign in with. A missing answer on any of the three is a stop sign, and Claude saying so plainly is the vetting working. Swap "confluence" for whichever system you picked.
Project scope writes the registration into a committed .mcp.json, so the connection travels with the repo. The sign in happens once, in your browser, through /mcp; each teammate approves the MCP server once in their own first session.
connect that official MCP server at project scope so the whole team gets it, then walk me through the sign in
What you should see: A .mcp.json at the repo root naming the MCP server and its address, and /mcp opening a normal browser login for the vendor. After signing in, /mcp shows the MCP server as connected. Teammates who pull the repo get asked, once, to approve the MCP server before their sessions use it.
Fresh matters because MCP servers connect and menus load at session start. Close Claude Code, open it again inside your repo, and run these in order; the last one breaks the connection on purpose and repairs it.
The menu should show the new hands next to the old ones, wearing their long names: mcp, then the MCP server, then the tool.
what tools do you have here?
What you should see: the built-ins, your skills and command, and each connected MCP server's tools with their prefixed names. If an MCP server is missing, run /mcp to check its status and sign in state.
You never name a tool; the menu does the matching. Use the reference MCP server's version first, then your vendor's if you connected one.
fetch the page at modelcontextprotocol.io and tell me in two sentences what MCP is
check our confluence for the most recent page about pricing and summarize what it says
What you should see: the right tool fires unnamed, and the answer arrives with its source. Notice what just happened, because it is the fact governance hangs on: the page content the tool returned is now in your session's context window. Swap the second prompt's system and topic for your own.
/mcp is where connection questions get answered: which MCP servers, which tools, signed in or not.
/mcp
What you should see: every connected MCP server with its status. This is also where a sign in that expired gets renewed, so knowing this screen is most of MCP troubleshooting.
The registration is the on switch. The vendor's MCP server keeps running in their cloud either way; your repo just stops pointing at it. Run the first prompt, open a fresh session to see the effect, then run the second and restart again.
remove the MCP server entry from the project's mcp file, then tell me what tools you have
put the MCP server entry back
What you should see: with the entry removed, the MCP server's tools are gone from a fresh session's menu. Restore the entry, restart, and they return. Now you know both switches, and where the off switch lives is a governance answer clients genuinely ask for.
Back to the Module 06 lesson, or straight to the quiz.