MCPs: giving AI the context it actually needs

The context problem

AI models have a training cutoff. Anything released or significantly updated after that point is a gap in the model's knowledge — and for fast-moving SDKs, that gap matters immediately. The model produces plausible-looking code using API surfaces it half-remembers, methods that were renamed, or patterns that were deprecated in the version you're actually using.

The naive fix is to copy the relevant documentation into the conversation. This works, but it doesn't scale. You're manually curating context for every session, deciding what to include, and hitting context limits when the docs are large. There needs to be a better way to give the AI accurate, current information about the tools in use.

What MCPs are

MCP stands for Model Context Protocol — an open standard, developed by Anthropic, that lets AI tools connect to external processes that expose structured data and capabilities. An MCP server is a small process that runs alongside the AI and responds to queries: search this documentation, fetch this page, list these records, run this command.

In Claude Code's context, MCP tools appear in the same toolbox as built-in capabilities like file editing and Bash execution. The AI decides when to call them based on the task — just like it decides when to read a file or run a command. The difference is that MCP tools connect to external systems that Claude can't reach natively.

Setting up MCPs

Claude Code has solid documentation on how to install and configure MCP servers — project-level vs. global, how the settings.json files work, and how to manage permissions. No point reproducing it here. Read the official setup guide →

The Strands Agents documentation server

The main MCP we use in this project is the Strands Agents documentation server. This codebase is built on @strands-agents/sdk — a framework for multi-agent orchestration that is actively developed and not heavily represented in the model's training data. Without the MCP, the AI produces code that references the right concepts but the wrong method names, wrong import paths, or wrong configuration shapes.

With it, a prompt like “add a memory tool to this agent” works as expected. The AI calls mcp__strands-agents__search_docs to find the relevant documentation, reads the actual API, and generates code against the real interface. The result is correct on the first attempt far more often than without it.

The server ships as part of the SDK — no separate installation. It's worth checking if any SDK you use heavily does the same before building your own.

The MCPs we reach for

Beyond the project-specific Strands Agents server, a handful of servers earn their place across almost every project:

• PostgreSQL MCP— lets Claude query the database directly, inspect the schema, and debug data issues without leaving the conversation. Particularly useful when diagnosing unexpected query results or verifying that a migration applied correctly.
• GitHub MCP— gives Claude access to pull requests, issues, and code search across the repository. Useful for writing PR descriptions, triaging issues, or understanding what changed in a specific commit without switching windows.
• AWS documentation MCP — AWS has one of the largest and most dense API surfaces in the industry. Having the model look up IAM policies, service quotas, or CloudFormation syntax from the actual docs rather than training memory makes a meaningful difference in accuracy.
• Web search and fetch — the fallback for everything else. When a library doesn't have a dedicated MCP, Claude can look up the changelog, check an open issue, or read the relevant section of the docs on demand.

Don't over-saturate

More MCPs is not better. Every server you add is another process to run, another authentication surface, another thing that can be slow or fail mid-session. Too many servers also give the model too many tools to choose between — and it will sometimes call the wrong one, or call several when one would do. Keep the list deliberate and short.

The pattern that earns a server a place in the list:

• Fast-moving or niche SDKs where the model's training data is stale or thin
• Large API surfaces — AWS, GitHub, complex internal tools — where including the relevant docs in every prompt isn't realistic
• Live data you genuinely need in the conversation — like the database schema or open issues
• Tools you reach for across many sessions, so the one-time setup cost actually amortizes

Things that don't need their own server: stable, well-known APIs the model already knows well (React, standard SQL, REST conventions), small codebases already loaded into context, or one-off lookups where pasting the relevant section is faster than spinning up and configuring a server.

The underlying principle

MCPs are a way of giving the AI accurate context instead of hoping it remembers correctly. This matters because vibe engineering requires the AI to work against real APIs, not plausible-sounding ones. When the model has live access to the documentation for the specific SDK version you're using, the quality of suggestions jumps noticeably — and so does your ability to trust them.

It's also a practical example of “AI as leverage” rather than delegation. You're not asking the model to figure things out on its own. You 're giving it the tools it needs to look things up accurately, then reviewing what it produces with that context in mind.