MCP for Developers: Giving Claude Code Access to Your Real Systems

Claude Code, out of the box, can read files, run commands, and search the web. That covers a lot. It does not cover your staging database, your deployment pipeline, your error tracker, your feature flag system, your internal documentation wiki, or any of the other systems an engineer touches fifty times a day. The Model Context Protocol (MCP) is how you close that gap. An MCP server exposes a system to the AI as a set of tools, resources, and prompts, and once it is connected, Claude can interact with that system the same way it interacts with the filesystem.

I wrote about MCP from a founder's perspective in the MCP playbook for SaaS founders. This article is the developer version — how to build an MCP server, what the protocol actually looks like, and the specific servers I install on client engineering teams to make Claude Code dramatically more useful.

What MCP actually is

MCP is a standard protocol for connecting AI tools to external systems. The protocol defines three primitives:

Tools are actions the AI can take. "Query the database." "Create a Jira ticket." "Deploy to staging." "Toggle a feature flag." A tool has a name, a description, a typed input schema, and returns a result. When Claude decides it needs to interact with a system, it calls the appropriate tool.

Resources are data the AI can read. "The current deployment status." "The error rate for the last hour." "The schema of the users table." Resources are like read-only references that Claude can pull into its context when it needs information.

Prompts are reusable instruction templates that the AI can invoke for specific workflows. Less commonly used than tools and resources, but useful for encoding standard operating procedures.

An MCP server is a process that implements some combination of these primitives for a specific system. Claude Code connects to MCP servers and can then use their tools and resources as part of its normal workflow.

The servers I install first

When I set up Claude Code for an engineering team, there is a standard set of MCP connections I install in the first week. These cover the systems engineers interact with most:

Database query server. Gives Claude read-only access to the development or staging database. Claude can run SELECT queries to understand data, check schema, verify that a migration worked, or investigate a bug. Read-only is critical — Claude should never have write access to a database via MCP. The server accepts a SQL query, validates it is read-only, runs it against the connection, and returns the results.

Error tracker server. Connects to Sentry, Bugsnag, or whatever the team uses. Claude can query recent errors, search for specific error messages, and pull stack traces. When debugging, the engineer says "find the most recent errors related to the billing module" and Claude queries the tracker directly instead of the engineer switching to a browser tab.

Deployment server. Gives Claude access to the deployment pipeline — check the status of the current deploy, see the diff between staging and production, trigger a deploy to staging (with explicit confirmation). This makes the deployment skill described in subagents, skills, and hooks possible.

Feature flag server. Connects to LaunchDarkly, Unleash, or the team's flag system. Claude can check whether a flag is on or off, see which users are in a rollout, and toggle flags in non-production environments. Useful for debugging ("is this feature enabled for the user who reported the bug?") and for controlled rollouts.

Documentation server. Exposes the team's internal docs — Notion, Confluence, a wiki, a docs folder — as resources Claude can search and read. When Claude encounters a system it does not understand, it can query the docs before guessing. This reduces hallucination about internal systems.

Ticket tracker server. Connects to Jira, Linear, or the team's issue tracker. Claude can read tickets, create tickets for follow-up work, and update ticket status. When Claude finishes a task, it can update the ticket with a summary of what it did.

Not every team needs all of these. The first two — database and error tracker — provide the highest leverage and I install them on every engagement.

Building an MCP server

An MCP server is a process that speaks the MCP protocol over standard I/O (for local connections) or HTTP with server-sent events (for remote connections). The simplest implementation is a Node.js or Python script that registers tools and handles calls.

The structure of a minimal server:

Define the tools. Each tool has a name, a human-readable description (this is what Claude reads to decide when to use it), and a JSON Schema for the input. The description matters — a vague description means Claude will not know when to call the tool.

Handle the calls. When Claude calls a tool, the server receives the tool name and the input, executes the operation against the real system, and returns the result. Error handling is important — the server should return clear error messages that Claude can reason about, not stack traces.

Register resources if applicable. Resources are URIs that Claude can read. A database server might expose db://schema/users as a resource that returns the users table schema. Resources are optional but useful for information Claude needs repeatedly.

A well-built MCP server for a typical internal system takes 1–3 days to build, depending on the complexity of the system's API and the number of operations you want to expose.

Security considerations

MCP servers are a bridge between an AI and your real systems. The security implications are not trivial.

Principle of least privilege. The MCP server should have the minimum permissions needed for its purpose. The database server gets a read-only connection string. The deployment server can trigger staging deploys but not production deploys. The ticket server can create and update tickets but not delete them.

No secrets in the protocol. The MCP server holds the credentials (database password, API key, OAuth token) and Claude never sees them. Claude calls the tool, the server authenticates to the system on Claude's behalf, and the result comes back without exposing the credential. If you find yourself passing API keys through the tool interface, something is wrong.

Rate limiting. The server should enforce rate limits to prevent accidental or intentional abuse. A runaway agent loop should not be able to DDos your staging database. Simple per-minute caps are sufficient.

Audit logging. Every tool call should be logged with a timestamp, the calling session, the input, and the result. This is the trail you need when something unexpected happens.

Environment scoping. MCP servers should connect to development or staging environments, not production. If production access is needed for read-only queries (error investigation, data analysis), the server should be explicitly scoped to read-only operations and the connection should use production-reader credentials with no write capability.

The composition pattern

The power of MCP shows up when you compose multiple servers. A debugging workflow that used to require an engineer to context-switch between six tools now looks like this:

The engineer says: "The billing endpoint is returning 500 errors for some users. Investigate."

Claude queries the error tracker server for recent 500 errors on the billing endpoint. It finds a stack trace pointing to a specific function. It reads the function in the codebase. It queries the database server to check the data for an affected user. It finds a null value in a field that should not be null. It checks the ticket tracker for any recent changes to the billing module. It finds a ticket for a migration that ran last week. It reads the migration code and finds the bug — the migration did not backfill the field for existing users.

Claude reports back with the root cause, the affected scope, and a proposed fix. The engineer reviews, approves, and ships the fix.

That entire investigation used four MCP servers (error tracker, database, ticket tracker, plus the built-in filesystem access), took a few minutes of wall-clock time, and would have taken the engineer 30–45 minutes of manual context-switching.

Common mistakes

Exposing too many tools. A server with fifty tools confuses Claude about which to use. Keep the tool count small and the descriptions clear. If you have fifty operations, group them into multiple focused servers.

Vague tool descriptions. The description is how Claude decides whether to call the tool. "Query the database" is vague. "Run a read-only SQL SELECT query against the staging PostgreSQL database and return the results as JSON" is specific.

Missing error messages. When a tool call fails, the error message should tell Claude what went wrong and what to try instead. "Error" is useless. "Query failed: table 'user_preferences' does not exist. Available tables: users, accounts, billing" is actionable.

Not testing the server independently. Before connecting the server to Claude, test every tool manually. Confirm it handles edge cases, returns sensible errors, and does not leak sensitive data in error messages.

Skipping the read-only constraint. It is tempting to give the database server write access "just for convenience." Do not. The cost of a bad write from an AI is far higher than the inconvenience of running writes manually.

Counterpoint: not every system needs an MCP server

A warning. I have seen teams build MCP servers for systems they interact with once a week. The build cost is not justified. Build MCP servers for the systems your team touches every day — the ones where the context-switching cost is real and frequent. For everything else, a browser tab is fine.

Your next step

This week, identify the two systems your engineers context-switch to most often during debugging. Build a read-only MCP server for one of them. Connect it to Claude Code and try a real debugging session. The time savings on the first investigation will tell you whether the second server is worth building.

Where I come in

Building the MCP server layer for an engineering team is a common 1–2 week engagement. I identify the highest-leverage integrations, build the servers, configure the security constraints, and pair with the team on the workflows that use them. Book a call if your team is using Claude Code and wants it connected to your real systems.