Chemaclass - software-architecture

MCP: Giving Your AI Agent the Right Context

2026-01-11T00:00:00+00:00

Modern AI coding assistants are remarkably good at understanding context. Models like Claude Opus with large context windows (~200k tokens) can hold substantial portions of your codebase in mind, reason about architecture, and maintain coherence across long conversations. Not the entire project for large codebases, but enough to work effectively.

But understanding isn’t the same as access.

The AI can reason about your database schema if you paste it. It can suggest changes to files you share. It knows patterns from code you show it. The limitation isn’t intelligence. It’s reach.

That’s where MCP comes in.

What MCP enables #

Modern AI can understand your codebase when you share it. But understanding and acting are different things.

Many IDE-integrated assistants like VS Code Copilot or Cursor already access your project files through their own indexing. So file access itself isn’t new. What MCP brings is standardization. Instead of each tool building its own integration, MCP provides a common protocol. You configure a server once, and any MCP-compatible client can use it. It’s portable, configurable, and extends beyond just files to databases, APIs, and custom tools.

MCP turns AI from a conversation partner into an active participant in your development environment.

With MCP, you give the AI direct access to tools and resources. It can read files, run commands, query databases, fetch documentation. The intelligence was always there. MCP gives it hands.

What MCP actually is #

MCP is a protocol, not a product. It’s an open standard that defines how AI agents can connect to external data sources and tools. Think of it as a bridge between the AI model and your development environment.

The architecture is simple: MCP servers expose capabilities, and AI clients consume them. Claude Desktop and Claude Code officially support MCP, with more tools adopting the protocol as it matures.

For example, in Claude Code you can add servers to a .mcp.json file at your project root. Claude Code reads this file when you open the project and starts the configured servers automatically:

{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": { "GITHUB_TOKEN": "your-token" }
 },
 "postgres": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-postgres"],
 "env": { "DATABASE_URL": "postgresql://localhost/mydb" }
 }
 }
}

Each server gives the AI different capabilities:

filesystem: Read and navigate your project files. The AI can explore your codebase, check existing patterns, and understand your directory structure before suggesting changes.
github: Access issues, pull requests, and repository metadata. Ask the AI to summarize open issues, check PR comments, or understand what your team is working on.
postgres: Query your database directly. The AI can inspect your schema, run read queries, and understand your data model without you copying table definitions.

Different tools, same protocol. You configure once, and any MCP-compatible client can use these servers.

Where MCP shines #

Working with your codebase #

The most immediate benefit is filesystem access. The AI can navigate your project, read source files, understand your directory structure. When it suggests code, it can check existing patterns first.

Git integration takes this further. The AI can see your commit history, understand what changed recently, and suggest modifications that align with how your codebase evolves.

Database schema access means the AI understands your data model. No more explaining table relationships or column types. It sees the structure and generates queries that actually work.

Documentation and knowledge #

Connect your internal documentation and the AI becomes aware of your team’s decisions. API specifications, architecture documents, coding guidelines. All available as context.

This is where MCP starts feeling different. The AI isn’t just generating generic code anymore. It’s generating code that fits your project.

The best AI assistance comes from understanding not just what you’re building, but how your team builds it.

External integrations #

GitHub integration means the AI can read issues, understand PR discussions, and see the broader context of what your team is working on. Slack or other communication tools can provide even more context about ongoing decisions.

Custom integrations let you connect internal tools specific to your workflow. The protocol is extensible by design.

Using MCP effectively #

MCP amplifies whatever it connects to. If your documentation is outdated, the AI will use outdated information. If your codebase is messy, the AI will learn messy patterns.

This is the mirror effect I mentioned in AI gives you speed, not quality. The AI reflects the context you give it. Good context produces useful output. Bad context produces confident-sounding garbage.

Giving AI access to your codebase doesn’t replace your responsibility to maintain it. It makes good hygiene more valuable.

A few practices that help:

Connect only what the AI needs. More context isn’t always better. Focused context is better.
Keep your documentation current. If the AI reads your docs, those docs matter more than before.
Review your MCP configuration periodically. As your project evolves, so should your context setup.
Start small. One or two servers. See what works. Expand from there.

Security matters too. Be intentional about what you expose. MCP servers can access sensitive information. Treat them like any other access control decision.

What comes next #

MCP is the foundation. But the ecosystem is building on top of it.

Agentic workflows. Tools like Claude Code and Cursor now run in “agent mode” where the AI autonomously plans and executes multi-step tasks. It reads files, makes changes, runs tests, fixes errors. MCP servers are the hands. The agent loop is the brain deciding what to do next.

Skills and custom commands. Claude Code introduced skills. Custom slash commands that chain MCP tools into reusable workflows. /deploy, /test, /review. You define them once, and they become part of your development toolkit.

A2A Protocol. Google’s Agent-to-Agent protocol. While MCP connects AI to tools, A2A connects AI agents to each other. Multiple specialized agents collaborating on complex tasks. One agent writes code, another reviews it, a third runs tests.

The pattern is clear: AI is moving from assistant to collaborator. From answering questions to executing workflows. MCP gave AI access to your environment. What’s next is AI that knows how to use that access autonomously.

The question is shifting from “what can AI access?” to “what should AI decide on its own?”

Human judgment doesn’t disappear. It moves upstream. Instead of reviewing every line the AI writes, we design the context and boundaries that shape what it produces.

That’s still our job. And it’s a job worth doing well.

AI Gives You Speed, Not Quality

2025-10-10T00:00:00+00:00

I’ve been using AI coding assistants extensively: ChatGPT, Codex, Claude with Sonnet and Opus. They’re incredibly helpful. They give you speed like nothing else.

But speed isn’t quality.

The vibe-coding trap #

AI models are excellent at imitating their surroundings. Give them context, and they’ll do whatever it takes to complete the task. This has become known as “vibe-coding”: you describe what you want, and the AI produces something that works. Fast.

The problem? AI will happily generate messy code if that’s what gets the job done. It doesn’t care about maintainability. It doesn’t think about what happens when requirements change next month. It just produces output.

AI is a mirror that reflects the context you give it. If your codebase is messy, it will generate more mess. If your prompts are vague, it will make assumptions.

Without careful guidance, you end up with patches on top of patches. Freshly created legacy code. A codebase where every change feels risky and the team spends more time fighting the code than building features.

The art of asking #

Remember Stack Overflow? Google searches that led you to forum threads from 2011 where someone had the exact same problem?

Ten years ago, being a developer meant learning how to ask good questions. You’d craft your Stack Overflow post carefully: describe the problem, show what you tried, explain what you expected versus what happened. If your question was vague or lazy, the community would let you know. Sometimes harshly.

But that friction taught us something valuable: the quality of your answer depends on the quality of your question.

The same principle applies to AI. A vague prompt gets a vague response. A well-structured prompt with clear context, constraints, and examples gets something useful. The skill of formulating good questions didn’t become obsolete. It became more important.

Learning to prompt AI effectively is the modern equivalent of learning to search Google and ask Stack Overflow. The developers who master this will get better results.

Even when AI gives you a fast, impressive-looking answer, never accept code you don’t fully understand. It’s tempting. The response appears in seconds, it looks professional, it might even work. But if you can’t explain what it does and why, you’re planting a time bomb in your codebase. And when it breaks at 2am, you’ll be debugging code you didn’t write with no mental model of why it exists.

Challenge the output. Ask: “Can you simplify this?” or “Is there boilerplate here we can remove?” AI’s default is to add, not to improve. It will generate abstractions, helper functions, and patterns you didn’t ask for. It won’t refactor unless you tell it to. Push back.

This is especially critical with tests. Ask AI to generate tests and you’ll often get tests that mirror implementation details rather than behavior. They’ll break the moment you refactor, even if the logic stays the same. If you want tests that verify behavior, you need to explicitly say so. AI won’t make that choice for you.

Don’t be seduced by speed. Sometimes, a fast answer you don’t understand is worse than a slow answer you do.

The human factor #

AI can write code fast, but it can’t understand overall architecture. It doesn’t know why certain decisions were made months ago. It can’t see the bigger picture of where the product is heading. It only sees what you show it, making local decisions without understanding global implications. That’s our job.

As I explored in different beliefs about software quality, teams often have varying standards for what “good enough” means. When you add AI to the mix, maintaining that shared understanding becomes even more critical. The AI doesn’t share your team’s values. It just generates code.

The discipline to maintain clean architecture, to say “no” to quick hacks, to refactor before things get worse. That’s uniquely human.

Books like Clean Code and Clean Architecture aren’t less relevant in the AI age. They’re more relevant. They help you spot when AI is heading in the wrong direction.

Collaboration over automation #

There’s something else AI can’t replace: the team.

A conversation with a colleague about “should we extract this into a service?” often leads to insights that no AI prompt would surface. That back-and-forth, the pushback, the “what if we tried this instead”. That’s where real understanding happens.

Extreme Programming Explained emphasizes practices like pair programming and collective code ownership for good reason. These aren’t inefficiencies to be automated away. They’re how teams build quality into their process.

When you skip the human discussion and just let AI generate solutions, you lose the opportunity to learn, to challenge assumptions, and to grow as a team.

You own the code #

When AI writes code and you commit it, review it, approve it, merge it, and deploy it, it’s your code. You can’t blame the AI when something breaks in production. You can’t point at Claude or Copilot when the architecture becomes unmaintainable.

As I wrote about the art of testing, quality is a choice we make at every step. Every commit is a decision. Every review is an opportunity to catch problems. Every merge is an endorsement of the code’s quality.

We are the ultimate responsible party for the code AI writes. The commit, the review, the approval, the merge, the deploy. That’s all us.

Moving fast in the wrong direction just gets you lost faster. Lines of code appearing on screen isn’t progress. The value we bring as developers isn’t typing speed. Our value is in understanding where we’re going, maintaining discipline over chaos, and ensuring that the code we ship today doesn’t become tomorrow’s nightmare.

Use AI. Embrace the speed. But never forget: you’re the one steering. If you let go of the wheel, you’ll end up in a pile of unmaintainable code faster than you expected.

And when that happens, there’s no one else to blame.