Claude Code — Part 9 — Connecting External Tools with MCP
MCP lets Claude Code read and act on systems outside your local filesystem, a ticket tracker, a wiki, a database, instead of working only from whatever you paste into chat.
A connector between Claude Code and one external system: a tracker, a database, an API.
The command that registers a server, whether it runs remotely over HTTP or locally as a process.
Checks connection status and handles OAuth authentication for any connected server.
Introduction
Every post so far in this series has worked with what is already on your machine: files, scripts, logs, git. MCP is the mechanism that extends Claude Code past the local filesystem, to a ticket tracker, a monitoring dashboard, a database, or an internal API. This is the last post in the foundations series before the daily-ops use cases begin.
What Is MCP?
The Model Context Protocol is an open standard for connecting AI tools to external systems. An MCP server is the connector for one specific system, giving Claude Code direct access to that system’s data and actions rather than requiring you to copy information in and out by hand.
Think of it as a standard plug rather than a different adapter for every tool. The same protocol works whether the server sits on your machine or on the far side of the internet, and Claude Code talks to all of them the same way once connected.
Adding a Server
Servers are registered with claude mcp add, and the transport you choose depends on where the server actually runs.
# Remote server over HTTP, the recommended transport for remote servers
claude mcp add --transport http notion https://mcp.notion.com/mcp
# Remote server with an auth header
claude mcp add --transport http secure-api https://api.example.com/mcp --header "Authorization: Bearer your-token"
# Local server running as a process on your machine
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable -- npx -y airtable-mcp-server-- is passed straight through to that process. Without it, Claude Code tries to parse the server’s own flags as its own options.
| Transport | Use For |
|---|---|
http | Remote servers, the recommended default; supports OAuth |
stdio | Local processes on your own machine, direct system access or custom scripts |
sse | Deprecated, use http instead where available |
ws | Remote servers that push events unprompted, configured via JSON rather than the --transport flag |
Where a Server Is Registered
The --scope flag decides who else sees the connection.
| Scope | Visibility |
|---|---|
local (default) | Only you, in the current project |
project | Everyone on the project, via a committed .mcp.json file |
user | Only you, across every project on your machine |
A project-scoped server someone else added does not connect silently. It shows up as pending approval until you review and accept it yourself.
Checking Status
# List every configured server
claude mcp list
# Get details for one server
claude mcp get notion
# Remove a server
claude mcp remove notion
# Inside a session: check connection status and handle OAuth
/mcp
A server that shows connected but lists zero tools has started but is not returning anything useful. Select Reconnect from /mcp before assuming the server itself is broken.
Final Thoughts
That closes the foundations part of this series. Installed, a real project running, CLAUDE.md carrying your standing rules, a Skill for repeatable procedures, subagents for noisy side tasks, permissions and hooks enforcing what actually matters, a troubleshooting reference for when something misbehaves, and now MCP for reaching outside the local machine entirely.
None of that is useful in the abstract. The next stretch of posts moves into the actual daily-ops work this was all setup for: scripts, logs, documentation, and the small automations that make a week easier.
--scope local while you are still testing a server, and only promote it to project scope once your team should share it.
With the foundations in place, the series moves on to real daily-ops use cases: writing and debugging scripts, triaging logs and event IDs, and building the first hands-on project.