Context Engineering Series · Part 3
Part 1 gave Claude memory, but it still couldn't touch anything outside the conversation. MCP servers give it direct access to your CRM, your code, your docs, and your channels, so you stop being the one who copies things in.
When I wrote this I was running 9 servers with more than 120 tools between them, all on one protocol, plus a case study where the standard integration path didn't exist and we had to build around it.
After Part 1, Claude remembers your corrections, your architecture decisions, and your product naming rules. But ask it to pull up the Acme account, or check what's in Slack, or look at that PR, and it can't, because none of that lives in memory.
So you end up doing the fetching for it. Ask what Acme owns and you're the one in Salesforce, clicking across multiple account variants, screenshotting the asset page, pasting it into the conversation and hoping Claude reads the formatting correctly. A PR review goes worse, since you copy the diff, paste it, and lose half of it to context-window limits, and Claude ends up reviewing a fragment without ever seeing the repo. And when you say "send the follow-up to the customer," Claude drafts the email and stops there, leaving you to copy it, open Slack, paste it, fix the formatting, and send it yourself.
Every one of those Alt-Tab round trips burns 30-60 seconds and clutters the context window with raw, unstructured data. Do it 20 times in a session and you've lost 10-20 minutes, with 30% of your context window spent on copy-paste artifacts instead of real work.
Model Context Protocol is an open standard from Anthropic that lets Claude call external tools such as APIs, databases, CLIs, and browsers through one standardized interface. Think of it as USB-C for AI, where a single protocol carries whatever capability sits on the other end of it.
There are three pieces worth keeping straight. The protocol itself is a JSON-RPC standard, so any host, whether Claude Code, Cursor, or Windsurf, speaks the same language to any server. A server is a lightweight wrapper around an API, CLI, or service that runs locally or remotely and exposes the tools Claude can call. And a tool is a single capability like "search Slack," "read a PR," or "query CRM," which Claude decides when to call while you either approve each call or auto-allow it.
Each one pushes Claude into a different domain. Some are open source, some are commercial, and one we built ourselves for our Salesforce intelligence platform. The tool counts are a snapshot from when I wrote this.
PRs, issues, code search, file reads, and branch management, so Claude reviews PRs, creates issues, and pushes code without leaving the terminal.
AI-native web search that runs on semantic queries rather than keywords and returns clean content instead of SEO spam. It powers my daily intelligence sweep.
It serves library docs that stay current. When Claude's training data is 6 months stale, Context7 pulls the live API reference, and there's a free tier to start on.
Full web scraping across single pages, multi-page crawls, and structured data extraction, and it handles the JS-rendered SPAs that a basic fetch can't.
Reads channels, searches and sends messages, and creates canvases, so Claude can draft a Slack post, find a thread, or summarize a channel from the terminal.
Browser automation that navigates pages, clicks elements, takes screenshots, and fills forms. Claude can use it to test a deployed app or screenshot a live UI for review.
More than 1,000 pre-built scrapers for X/Twitter feeds, LinkedIn profiles, and product data, and the workhorse behind my daily intelligence pipeline.
Semantic search across all Salesforce documentation, so when Claude needs Apex governor limits or the right way to build a Flow, it checks the source directly.
This is the one we built. At the time it had 40 tools wrapping our intelligence platform and corporate CRM, bringing account briefs, pipeline data, competitive intel, and RAG search into Claude natively, and it's the server that matters most in this stack. The case study below is how it got its CRM access.
One more piece of the setup isn't an MCP server at all. Context-Mode is a Claude Code plugin that compresses large tool output ~98% into a local SQLite FTS5 index, and only the search-matched excerpts re-enter the conversation, so raw build logs, test suites, and web fetches stay out of your context window. It works through tools like ctx_batch_execute, ctx_search, ctx_execute, and ctx_fetch_and_index.
Our internal CRM holds pipeline, contacts, contracts, installed products, and consumption data. It's the single source of truth for every deal, and I wanted it inside Claude.
The standard route would have been a direct API integration, and getting that approved for an individual SE project wasn't practical, so the usual credential-based patterns were off the table. Our Cloud Run middleware couldn't query the internal CRM either. There was a hard wall between our production infrastructure and the corporate CRM.
What worked was the Salesforce CLI, because it logs in as me.
sf org login web --alias corp-crm is a browser-based SSO login that uses your existing corporate credentials, with no app registration needed.
sf data query --query "SELECT..." --target-org corp-crm under the hood. Claude calls the tool, and the server runs the CLI.
Meridian is one custom MCP server that wraps our entire intelligence platform, so Claude can pull account briefs, query the corporate CRM, search grounding data, and run financial analysis from a plain-English request. At the time it had 40 tools, split into three groups.
The 11 CRM tools are the ones the case study made possible. crm_account_detail returns firmographics, owner, and team, crm_asset_lines returns installed products with pricing, crm_opportunity_history gives the full deal history, and crm_consumption_plans carries CCR health data, with contacts, cases, contracts, products, search, and query filling out the rest.
Eight intelligence tools sit on the platform itself. aip_analyze runs the full 25-source analysis, aip_account_brief returns the cached brief, aip_enhance re-analyzes a single section, and aip_search_grounding searches 1,598 RAG chunks, alongside tools for health, deployment, opportunities, and activities.
The remaining 21 are composable v4 tools for outside research, like v4_company_brief for a quick multi-source brief, v4_financials for key financial metrics, v4_news for GDELT news with tone analysis, and v4_techstack for technology detection, plus stock, patents, SEC, GitHub, wiki, and meeting prep.
Here's one research cycle, four common requests, done by hand and then through MCP.
crm_opportunity_history and structured data comes back in 3 secondsslack_search_public and threaded results come back in 2 secondsget_pull_request_files and the full diff lands in context in 2 secondsweb_search_exa for AI-native search with clean content, back in 5 secondsThe times are approximate, but twelve minutes down to about twelve seconds works out to 60x faster, with no tab switching and no copy-paste in between.
Slack was the last server I added, and it mattered more than I expected. With it Claude can search Slack, read channels and threads, send messages, and create canvases, but what it really surfaces is the unstructured human signal that no CRM ever captures.
In practice that means I can find that conversation about a deal strategy from last week without scrolling, and Claude can follow a thread to understand the full discussion before it drafts a response. It posts directly too, meeting follow-ups, deal updates, team announcements, and it can publish long-form content like this very post series as a canvas, formatted and ready to share.
Once I authenticated to corporate Slack I briefly wondered whether I still needed the Meridian CRM tools, since a Slack search for "Acme" turns up a lot on its own.
I kept querying our internal CRM separately, and running one account through both servers shows why, they hand back different kinds of information about it.
What Slack turns up is the conversation around the account, who's working the deal, who the AE is, and who's looped in on the technical side, plus mentions of competing platforms and win/loss context from deal channels, how the customer reacted in meetings and what concerns they raised, and risk signals like executive changes, project delays, and escalations the team flagged. It's unstructured and conversational, and most of it never makes it into a CRM field.
Meridian's CRM tools give me the structured, quantitative side, the system of record. For the same account that's the installed products down to exact SKUs, quantities, per-unit pricing, discount percentages, and contract periods, along with every won, lost, and open opportunity with amounts and close dates. It also catches account variants, since multi-org customers appear as separate CRM accounts (core, Slack, Tableau), and consumption health, meaning CCR utilization, contract values, and renewal timelines.
MCP servers don't need to talk to each other, or even know the others exist. Claude is the part that does the integrating, deciding which servers to call and stitching the results back together.
It works a lot like Unix pipes, where each MCP server is a specialized command (grep, sort, awk) and the LLM plays the pipe operator | that chains them, so the servers compose without being coupled to one another.
You don't need 9 servers on day one. Start with the three that pull the most weight for SE work, which takes about 15 minutes to set up, and add the rest as you go.
claude mcp add github --scope user -- npx -y @modelcontextprotocol/server-github
PR reviews, issue management, and code search, once you set GITHUB_PERSONAL_ACCESS_TOKEN in the env.
claude mcp add context7 --scope user https://mcp.context7.com/mcp
Current library docs for any framework, on a free tier with no API key needed, which fixes the stale-training-data problem for technical work.
claude mcp add slack --scope user -- npx -y @anthropic/slack-mcp
Search, read, and send messages. It needs a Slack bot token carrying the channels:history, chat:write, and search:read scopes, and then you set SLACK_BOT_TOKEN.
Once you've seen the pattern you can wrap any API. Our Meridian server is ~400 lines of Node.js, each tool is a function that takes params, calls an API, and returns JSON, and the MCP SDK handles the protocol. If your team has internal APIs, dashboards, or data sources Claude should reach, a custom MCP server is 2-4 hours of work for a developer who's seen it done.
Part 3 gave Claude reach, the tools to touch your systems. Part 4 picks up once it can, when it stops treating those systems as a flat list and starts mapping how everything connects, in a knowledge graph. The rest of the series is below.
Wiki, CLAUDE.md, hooks, rules
From wrong to expert
Connecting to your systems
Entities and relationships
Packaged, reusable expertise
From memory to an OS
A guard that grades the work
Gated, portable, human-held key
Autonomy on a leash
Where it belongs