MCP for AI Coding: What It Is & How Teams Use It (2026)

The Model Context Protocol (MCP) has become the de facto wiring standard for connecting AI coding agents to the tools, data, and context they need to do real work. If you're a senior engineer or engineering manager rolling out AI coding agents across a team, understanding MCP — and the layers that sit above it — is now table stakes. This guide explains what MCP actually is, how teams use it in practice, how AGENTS.md and memory servers fit in, and where ZeroShot (the BuildBetter CLI, run as bb) builds the team layer on top of the protocol. ZeroShot doesn't compete with MCP; it embraces it. Let's start with the fundamentals.

MCP in One Paragraph

MCP (Model Context Protocol) is an open standard for connecting AI agents to external tools, data sources, and context through a uniform client-server interface. Before MCP, every agent shipped bespoke, non-portable integrations — a Postgres connector built for one tool wouldn't work in another, and every vendor reinvented the same plumbing. MCP fixes that by standardizing how a model discovers and calls tools and reads context, so you write a tool server once and use it from Claude Code, Cursor, Codex, Gemini CLI, and beyond.

This article walks through protocol fundamentals, real team usage patterns, the AGENTS.md companion standard, the honest landscape of MCP memory servers, and where ZeroShot fits as the team layer above the protocol. Our stance is simple and honest: MCP is genuinely useful and worth adopting. ZeroShot is built to work with it, not around it.

What MCP Actually Is (and Isn't)

MCP is the standardized connectivity layer between AI models and the outside world — frequently described as "USB-C for AI applications." Anthropic introduced it on November 25, 2024, and by 2026 it has been adopted across nearly every major agent ecosystem.

The architecture follows a client-server model with three roles:

• MCP host — the agent or application itself (Claude Code, Cursor, your IDE).
• MCP client — a connection instance the host manages, one per server.
• MCP servers — programs that expose capabilities to the model.

Engineers should know the three core primitives MCP defines:

• Tools — model-controlled callable functions that take actions (run a test, open a PR).
• Resources — application-controlled, read-only data and context the model can reference.
• Prompts — user-controlled reusable templates and workflows.

For transport, MCP supports stdio (standard input/output, for local servers on the same machine) and Streamable HTTP (the modern replacement for the deprecated HTTP+SSE transport, used for remote servers, now with an OAuth 2.1 authorization framework).

Critically, MCP is NOT an agent, NOT a memory system by itself, and NOT an orchestration framework. It's the wiring standard. That's exactly why it matters: a single tool server, written once, works across Claude Code, Cursor, Codex, Gemini CLI, and the thousands of community servers now in public registries.

How MCP Fits Into an AI Coding Workflow

In an AI coding workflow, the agent does the reasoning while MCP servers give it hands and eyes. The agent decides what to do; MCP servers provide the tools to act and the resources to read. Keeping that mental model prevents teams from over-attributing intelligence to the wiring.

Concrete coding examples make this tangible:

• A Postgres MCP server for schema-aware queries against your real database.
• A GitHub MCP server for reading issues and opening pull requests.
• A filesystem server for scoped access to project files.
• A Sentry/observability server to pull live error context into a debugging session.

At runtime, a coding agent connects to each server, discovers the tools and resources it exposes, and invokes them as needed — passing arguments, receiving results, and folding them back into its reasoning loop.

Security and scoping deserve careful attention. Distinguish read tools from write tools explicitly, and scope servers so destructive operations require elevated permissions, separate credentials, and ideally human-in-the-loop confirmation. Prefer running sensitive servers locally over stdio inside the developer's trust boundary, and reserve remote HTTP servers (with OAuth 2.1) for shared, audited infrastructure. Never embed long-lived secrets in server config — use a secrets manager. Because no single server covers schema, source control, and observability, most teams end up running several MCP servers, not one.

Three Categories of MCP Servers Teams Actually Use

MCP servers fall into three practical categories: tool servers, context/resource servers, and memory servers. Knowing which category solves your sharpest pain point tells you what to adopt first.

Tool servers (action-takers)

These do things: run your test suite, query databases, open PRs, hit internal APIs. They're the most common starting point because the payoff is immediate and visible.

Context/resource servers (readable knowledge)

These expose documentation, design specs, runbooks, and ticket systems as read-only context the agent can reference. They reduce the amount of background an engineer has to paste into every prompt.

Memory servers (persistence)

These persist and retrieve knowledge across sessions so the agent doesn't start cold every time. We cover them in depth in the next section.

Practical guidance: most teams begin with a GitHub server (PRs/issues) and a database server (schema-aware queries), then add observability (Sentry) and internal-API servers once those land. Adopt incrementally, starting from the workflow that hurts most today.

MCP Memory Servers: The Honest Landscape

Memory matters because stateless agent sessions force engineers to re-explain context every time — and that cost compounds across a team. When an agent forgets your architecture, your conventions, and last week's decisions, every session restarts from zero.

Several approaches exist:

• Graphiti (built by Zep) — a temporal knowledge-graph memory exposed over MCP. It's built to give an agent persistent recall by modeling facts and their changes over time, which is powerful for long-running, evolving context within a single agent's world.
• Vector-store memory servers — embed past interactions and retrieve them by similarity. Simple and broadly available, but similarity search isn't the same as structured recall.
• ContextPool and Recallium — additional memory-layer projects that persist and retrieve session knowledge, each with their own storage and retrieval models.

Here's the key distinction senior engineers should internalize: most memory servers store per-developer or per-project memory, not cross-agent, cross-teammate session memory. They make one agent smarter about its own history. What they generally don't do is carry a teammate's session learnings to your machine, or move knowledge with you when you switch from Cursor to Claude Code.

That's the gap. Protocol-level memory is not the same as shared team knowledge that travels between people and between different agents. Closing that gap requires a layer above the protocol.

AGENTS.md: The Companion Standard to MCP

AGENTS.md is a simple, repo-level Markdown file — effectively a "README for agents" — that tells coding agents your project's conventions, build commands, test steps, and contribution norms. Where MCP wires up live tools and context, AGENTS.md encodes the rules of engagement.

The two are complementary. MCP gives the agent capabilities; AGENTS.md gives it the guardrails and instructions for using them well. An agent with a GitHub MCP server but no AGENTS.md knows how to open a PR but not how your team expects PRs to look.

By 2026, AGENTS.md is broadly supported as a portable, cross-vendor convention — OpenAI Codex, Cursor, Jules, Factory, RooCode, and others all read it, with the standard tracked at agents.md. It's the highest-ROI, lowest-effort first step you can take: a single well-written file dramatically improves agent output by removing guesswork about build/test commands and conventions.

But it has real limitations. A single static file doesn't scale to large teams, doesn't load conditionally, and doesn't carry session memory or customer evidence. As your repos and team grow, one flat document becomes either too thin to be useful or too bloated to maintain.

Where Individual-Agent Productivity Stalls on a Team

The common origin story is the same everywhere: engineers adopt Cursor or Claude Code individually, productivity spikes, then plateaus. Surveys consistently report that 60–80% of professional developers now use AI coding tools at least weekly, and individual task throughput gains are real and well-documented.

So why the plateau? Because those gains are individual and session-scoped. Context isn't shared. Onboarding knowledge, handoff details, and hard-won conventions live in individual heads and individual agent sessions. When a teammate solves a tricky migration on Tuesday, your agent has no idea on Thursday.

MCP and AGENTS.md solve real problems — connectivity and conventions, respectively — but they don't solve the team-knowledge problem. The missing layer is cross-agent, cross-teammate memory, encoded team conventions, and customer evidence all moving together. Without it, every engineer's AI productivity is an island. Gains stack within a person but never compound across the team.

How ZeroShot Builds the Team Layer on Top of MCP

ZeroShot (the bb CLI, at tryzeroshot.com) is not another agent — it's the context layer that sits under the agents you already use. It embraces MCP and AGENTS.md rather than replacing them, and adds the three things individual-agent setups can't: shared memory, team skills, and customer evidence.

Extends AGENTS.md with composable skills

BB-Skills extend AGENTS.md with composable, conditional skill packs that load only when relevant — solving the static-file scaling problem head-on. Instead of one bloated document, your conventions become modular skills that activate in context.

Cross-agent session memory

Every coding session is saved, indexed, and resumable. bb agent-sessions resume picks up a teammate's session on your machine, in any agent. This is the cross-agent, cross-teammate memory that Graphiti, ContextPool, and Recallium don't provide.

Team-conventional skills

Commands like /bb-review, /bb-specify, and /bb-plan carry your team's actual playbook into every PR. BB-Skills are open source on GitHub, so your conventions are versioned, reviewable, and portable.

Customer-evidence-aware

ZeroShot pulls signals from BuildBetter.ai directly into specs and PR reviews — connecting what customers actually said to the code you ship. That's a layer ContextPool, Recallium, Graphiti, and agent-native team modes simply don't have.

The combination is what's unique: cross-agent memory + team skills + customer evidence, in one privacy-first layer with no lock-in. It's used by Brex, Rappi, PostHog, AppFolio, Clay, Lufthansa, Procore, and Macmillan.

Comparison: MCP Building Blocks vs. the Team Layer

Here's how the building blocks compare across the capabilities that matter for a team:

Capability	Cross-agent support	Cross-teammate session memory	Encoded team conventions	Customer evidence	Open source	Privacy-first
ZeroShot (bb)	✅ Yes	✅ Yes	✅ Yes (BB-Skills)	✅ Yes (BuildBetter.ai)	✅ Yes (BB-Skills)	✅ Yes
Raw MCP tool servers	✅ Yes	❌ No	❌ No	❌ No	Varies	Self-hosted
Graphiti / memory servers	Partial	❌ No	❌ No	❌ No	Varies	Self-hosted
AGENTS.md	✅ Yes	❌ No	✅ Static only	❌ No	✅ Convention	In-repo
Agent-native team modes	❌ Single agent	Partial (same agent)	Partial	❌ No	❌ No	Vendor

The honest takeaway: agents and MCP servers are necessary and good — ZeroShot is the layer that makes them compound across a team. Raw MCP servers give your agents capabilities. Memory servers give one agent recall. AGENTS.md encodes conventions statically. Agent-native team modes lock you into a single agent. None of them combine cross-agent memory, dynamic team skills, and customer evidence. The right move is to adopt these together, not instead of one another.

A Practical Adoption Path for Engineering Teams

Adopt MCP and its companion layers incrementally, starting from your sharpest pain point and building toward shared team context. Here's a sequence that works:

1. Add an AGENTS.md to your core repos. Highest ROI, lowest effort. Document build commands, test steps, and conventions so every agent stops guessing.
2. Stand up the MCP servers your workflow needs. Start with GitHub (PRs/issues) and a database server (schema-aware queries), then add observability (Sentry) and internal-API servers. Scope read vs. write tools and run sensitive servers locally over stdio.
3. Decide your memory strategy. Per-developer vs. shared, and single-agent vs. cross-agent. A tool like Graphiti helps a single agent recall its own history; decide early whether that's enough.
4. Layer in ZeroShot for cross-agent memory, team skills, and customer evidence — exactly when individual productivity stops compounding. This is the step that turns isolated AI gains into team gains.

To measure impact, track onboarding time (how fast a new engineer becomes productive), context-handoff friction (how much re-explaining happens at handoffs), and PR review quality (whether conventions and customer evidence consistently show up in reviews). Those three metrics tell you whether your team layer is actually working.

Frequently Asked Questions

What is MCP (Model Context Protocol)?

MCP is an open standard, introduced by Anthropic in late 2024, that defines a uniform client-server interface for connecting AI agents to external tools, data, and context. It standardizes how a model discovers and calls tools and reads context — often described as "USB-C for AI applications."

What's the difference between MCP and AGENTS.md?

MCP is a runtime protocol that wires an agent to live tools and context (databases, GitHub, observability) via servers. AGENTS.md is a static, repo-level Markdown file that encodes your project's conventions, build commands, and norms. MCP gives the agent capabilities; AGENTS.md gives it the rules of engagement. They are complementary, not competing.

Do I need an MCP memory server like Graphiti?

A memory server like Graphiti (built by Zep) helps when an agent keeps re-asking for context it should already know — it gives one agent persistent recall across its own sessions using a temporal knowledge graph. What most memory servers do NOT provide is cross-teammate, cross-agent memory: your colleague's session learnings or knowledge that travels when you switch from Cursor to Claude Code. For that you need a dedicated team layer.

Does ZeroShot replace Cursor or Claude Code?

No. ZeroShot (the bb CLI) is not an agent and does not replace the coding agents you already use. It sits underneath them as a shared context layer — providing cross-agent session memory, team-conventional skills that extend AGENTS.md, and customer-evidence awareness — and works alongside Cursor, Claude Code, Codex, and Gemini CLI.

Is MCP secure for company codebases?

MCP can be secure when configured correctly. Run sensitive servers locally over stdio inside the developer's trust boundary, use OAuth 2.1 and audited credentials for remote HTTP servers, separate read tools from write tools, avoid embedding long-lived secrets in config, and keep data in-repo where possible. As with any tool integration, the protocol is only as safe as the permissions and secrets handling you wrap around it.

How do MCP, AGENTS.md, and ZeroShot work together?

They compose. MCP wires your agents to tools and context, AGENTS.md encodes your conventions, and ZeroShot adds the team layer on top — cross-agent memory, dynamic skills, and customer evidence — so individual AI productivity compounds across the whole team. Ship at the speed of insight. Get started with ZeroShot.

Make Churn Optional

The same customer evidence that should shape your roadmap belongs in your code. BuildBetter captures every call, ticket, and Slack thread, turns it into structured signals, and — through ZeroShot — pulls that evidence straight into specs and PR reviews. Stop shipping in the dark. Make churn optional. Book a demo.