Enhancements with MCP servers

You now have Claude Code running in your terminal with its built-in toolkit of files, shell, and web access. That's enough for most coding tasks, but your team's actual work involves a lot more — bug reports in Sentry, tickets in Jira, designs in Figma, messages in Slack, production queries in whatever monitoring stack you use. Claude Code has an MCP client built into it, which means you can plug in MCP servers for any of those systems and Claude gets new capabilities without any code changes on your side.

The one command you need

Registering an MCP server with Claude Code is one command:

claude mcp add [server-name] [command-to-start-server]

The server-name is whatever you want to call it inside Claude Code. The command is how Claude Code should launch the server process — usually something like uv run main.py or npx some-mcp-server or a path to an executable.

For example, if you've built a custom document-processing MCP server that starts with uv run main.py, register it like this:

claude mcp add documents uv run main.py

From now on, every time you start Claude Code in that project, it automatically connects to the server and the tools the server exposes become available to Claude. No other configuration required.

The MCP primitives, applied to Claude Code

Because this is an MCP client, everything you learned in Module 9 transfers directly:

• Tools the server exposes become tools Claude Code can call during its reasoning loop.
• Resources the server exposes become data the Claude Code UI can fetch (for example, to support @-mentions or context injection).
• Prompts the server exposes become slash-commands in the Claude Code interface.

The MCP servers you built in Module 9 would, if pointed at with claude mcp add, immediately work inside Claude Code. The primitives are the same; the client is the same; only the application is different.

Popular MCP servers for development workflows

The MCP ecosystem already includes servers for many common tools. A non-exhaustive list of ones you'll probably care about as a developer:

| Server | What it adds | |---|---| | sentry-mcp | Fetch bug reports from Sentry, investigate stack traces, and fix issues in code | | playwright-mcp | Let Claude drive a headless browser for testing, scraping, and end-to-end verification | | figma-context-mcp | Expose Figma designs so Claude can read component layouts and implement them in code | | mcp-atlassian | Access Confluence pages and Jira tickets from the conversation | | firecrawl-mcp-server | Web scraping and fetch-to-markdown for research and documentation workflows | | slack-mcp | Read and post Slack messages, reply to threads, notify channels when work is done |

Each one is registered with claude mcp add the same way. Pick the ones your workflow actually touches; adding servers you don't use just clutters the tool surface Claude has to reason over.

Building a custom development environment

The real payoff is combining multiple servers into a workflow tailored to your team. A realistic setup might look like:

• sentry-mcp — Claude can fetch the details of a production error you're investigating.
• mcp-atlassian — Claude can read the Jira ticket describing the feature or the bug.
• playwright-mcp — Claude can run browser tests to verify a fix works end-to-end.
• slack-mcp — Claude can post a message to your team when the work is complete.
• A custom internal MCP server — for your own APIs, databases, or tooling that doesn't have a public MCP server yet.

With that setup, a typical interaction looks like:

> Fetch the stack trace for Sentry issue CODE-4271 and the associated
> Jira ticket PROJ-812. Plan a fix. Do not write code yet.

Claude Code calls the Sentry MCP to get the stack trace, calls the Jira MCP to get the ticket, and responds with a plan grounded in both. After you approve the plan:

> Implement it. Run the Playwright test to verify. Commit the change
> with an appropriate message. Post the resolution to #engineering.

Claude Code writes the fix using the files and shell tools, runs the test via the Playwright server, commits via its built-in git integration, and posts to Slack via the Slack MCP. That's five different systems touched in one conversation, all without you leaving the terminal or switching context.

Why this matters more than it looks

The promise of AI coding assistants a couple of years ago was "it writes the code for you." That promise is partially real and incredibly useful, but it's also a narrow view of what a developer spends time on. A huge percentage of real work is orchestration — reading tickets, correlating bugs with deploys, running tests in the right environment, updating stakeholders, making sure the fix landed everywhere it needed to.

MCP-extended Claude Code turns Claude into an agent that can do orchestration, not just code generation. The integrations are what turn it from "a code generator" into "an engineer who can work your stack." That's a much larger productivity lever, and it's the reason this module spends time on the MCP enhancement story rather than just the install.

Writing your own MCP servers

Everything you learned in Module 9 about building MCP servers applies here. If there's a service in your team's workflow that doesn't have an off-the-shelf MCP server — your internal API, a custom database, a weird build system — you can write a server for it in an afternoon using FastMCP, register it with claude mcp add, and every developer on the team can plug into it.

The server you write once benefits every Claude Code user on your team, every time they work on anything that touches that service. Integration work is already one of the highest-leverage things a senior engineer can do; building an MCP server is a particularly neat version of it.

The wrap on Module 10

Claude Code is a production-quality reference implementation for building agents on Claude. Three things to carry forward:

• The primitives are the same ones you already know — tool use, MCP, the conversation loop from Module 6 — just applied at a level of polish and breadth that makes it feel like a new product.
• The developer workflows matter more than the tool set. /init, context-plan-implement, the test-driven variant, /clear between tasks — these are the habits that make the same CLI produce dramatically different results for different users.
• The MCP enhancement story is the long-term compounder. Today you connect to the servers that already exist; tomorrow you write the ones that don't yet. Every server written compounds across every Claude Code user on your team.

With that under your belt, the next and final technical module is Agents and Workflows — building your own agents from scratch, using every primitive from the course, to produce systems that rival Claude Code's design applied to problems Claude Code isn't built for.