MCP Servers for Claude Code Client Work: Turn a One-Off Build Into a Retainer
- MCP (Model Context Protocol) is Anthropic's open standard for connecting Claude Code to external tools and data. You add a server with `claude mcp add`, stored at one of three scopes: local (private to you), project (shared with the team via .mcp.json in the repo), or user (available across every project you open).
- The commercial angle: a client's CRM, database, ticketing system, or Slack workspace connected through MCP is ongoing infrastructure, not a one-time deliverable, which is the natural line between a fixed-price build and a recurring retainer.
- Wire the integration during delivery if it makes sense, but price it as its own line item, and say so in the proposal before you connect anything to a system that holds the client's real data.
What MCP Actually Is
MCP is an open protocol for connecting an AI model to external tools and data sources. Claude Code acts as an MCP client: once you add a server, Claude can call it the same way it calls its built-in tools, reading a database, searching a knowledge base, or acting on a system like Slack or a CRM. (Claude Code can also run as an MCP server itself, exposing its own file and command tools to other MCP clients, though that is a separate use case from what most client work needs.)
It is not the same thing as a skill, a hook, or a subagent, even though all four live in the same delivery stack. [A skill](/blog/claude-code-skills-for-client-work) packages a repeatable task. [A hook](/blog/claude-code-hooks-for-client-work) fires a check automatically at a point in the session. [A subagent](/blog/claude-code-subagents-for-client-work) runs a scoped piece of work in parallel. MCP is the one that reaches outside the codebase entirely, to a system the client already runs their business on.
Adding a Server: The Three Scopes and When Each One Fits a Client Repo
| Scope | Where it lives | Who sees it | Best for |
|---|---|---|---|
| Local | ~/.claude.json, tied to your project path | Only you, on this machine | Trying a new server before you recommend it to anyone |
| Project | .mcp.json at the repo root, checked into git | Anyone with the client's repo | The client's own integration, shared with their team and with you |
| User | ~/.claude.json globally | Every project you open | Your own tools you use across every client, not the client's systems |
Where each MCP scope is stored and who it applies to
On paid client work, project scope is usually the right default for the client's own integration: it is checked into their repo, so it does not leak into your other clients' sessions when you switch context, and it stays with the project if someone else on their team picks it up later. Local scope earns its keep for the testing phase, before you know a server is worth recommending at all.
The Integrations That Are Actually a Commercial Upgrade
Not every MCP server is a retainer conversation. Connecting a read-only documentation source is a convenience. Connecting the client's CRM, their support ticketing system, their Stripe account, or their internal database so Claude Code can act on live business data is a different category of work, because it keeps running after the original build ships.
- A CRM or support tool connection that lets Claude draft responses or pull records from the client's own system, not a static export of it.
- A database connection that gives ongoing reporting or query capability the client did not have before, beyond the one-time feature you were hired to build.
- A Slack or internal-tools connection that turns a delivered build into something the client's team interacts with daily, which is exactly the kind of dependency that justifies a monthly fee.
The pattern across all three: the integration is not a feature of the build, it is a standing connection to a system that changes every day. That is what separates it from a line in a fixed-price scope, and it is worth naming explicitly rather than folding quietly into the original quote.
Where the Upsell Conversation Actually Happens
Raise it once the original build is scoped, not before, and frame it as a separate decision: 'I can also wire this up to your live CRM so it stays current, that is a separate ongoing piece.' [Upselling an existing client](/blog/how-to-upsell-your-existing-clients) works best off something they already trust, and a finished build is exactly that moment.
Price it the way [a recurring retainer](/blog/recurring-revenue-retainer-vs-subscription) is priced elsewhere in your business, not as an hourly add-on: a monthly fee that covers keeping the connection working, updating it when the client's other tools change, and being the person who gets a message when it breaks. If you already run [productized service tiers](/blog/productize-your-claude-code-service), a connected-integration tier is a natural place to put this.
Security and Access Boundaries Before You Connect Anything
An MCP server that can read a client's production database can also, depending on how it is configured, write to it. Before you add a server, know whether the credentials behind it are read-only or read-write, and default to the narrowest access the task actually needs. This is the same discipline covered in [handling a client's data safely](/blog/is-it-safe-to-use-claude-code-with-client-data), applied specifically to a live connection instead of a one-time export.
MCP vs Skills vs Hooks vs Subagents
| Piece | What it does | Reaches outside the repo |
|---|---|---|
| MCP server | Connects Claude Code to an external tool or data source | Yes |
| Skill | Packages a repeatable task so you stop re-explaining it | No |
| Hook | Runs a check automatically at a fixed point in a session | No |
| Subagent | Runs a scoped piece of work in parallel on the same repo | No |
The four pieces of a systematized delivery stack
None of the four replace each other, and most delivery pipelines worth [systematizing](/blog/systematize-your-delivery-pipeline) end up using all four for different jobs: MCP for reaching outside the codebase, skills for repeatable tasks, hooks for automatic checks, and subagents for parallel work on the same repo.
Common Mistakes
- Wiring an MCP integration into the original fixed-price quote instead of naming it as its own line, which gives away a recurring-revenue opportunity for free.
- Connecting a server with broad write access to a client's production system by default, instead of scoping the credential to what the task actually needs.
- Using user scope for a client-specific integration, so it silently follows you into every other project instead of staying with the client's repo.
- Reaching for an MCP server when the task only needed a skill or a subagent, adding an external dependency the job never required.
- Never telling the client what the connected server can actually access, which turns a useful integration into an unpleasant surprise later.
Inside the Claude Code Profit Room, builders share which MCP integrations turned into an actual monthly line item on a client invoice, and which ones were setup time they never got paid for. Join us at https://www.skool.com/claudecodeprofitroom/about and bring the client tool you are thinking about connecting.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What is MCP in Claude Code?
MCP, the Model Context Protocol, is Anthropic's open standard for connecting Claude Code to external tools and data sources. Once you add a server, Claude can read from or act on that system, such as a database, a CRM, or a ticketing tool, the same way it uses its built-in tools.
How do I add an MCP server to a client project?
Use `claude mcp add`, choosing a scope: local (private to you, stored under your project path in ~/.claude.json), project (shared with the team via .mcp.json checked into the repo), or user (available across every project you open). For a client's own integration, project scope is usually the right default.
Should I charge extra for connecting a client's tools via MCP?
Generally yes. A live connection to a client's CRM, database, or ticketing system keeps running and needs maintenance after the original build ships, which makes it closer to a retainer than a one-time deliverable. Name it as a separate line in the proposal rather than folding it into the fixed-price quote.
Is it safe to connect an MCP server to a client's production database?
Only with the access scoped to what the task needs. Confirm whether the credential behind the server is read-only or read-write before connecting it, default to the narrowest access that works, and tell the client plainly what the integration can access once it is live.
Last reviewed August 29, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →
