MCP and ADK: Two Tools, Two Jobs, One Stack

Every few months, the AI tooling space produces a new acronym that developers are apparently supposed to already know. MCP and ADK are the current contenders—and if you've been nodding along in meetings while quietly wondering what either of them actually does, you're in better company than you think.

A recent IBM Technology video featuring developers Cedric Clyburn and Anna Gutowska takes a clean run at explaining both. It's worth breaking down not just for the definitions, but for what the existence of these tools tells us about where AI agent development actually stands right now.

The problem they're each solving

Here's the honest framing: building an AI agent that does useful things in the real world involves at least two distinct engineering problems that often get conflated.

The first is connectivity. How does your agent reach out and touch external systems—databases, APIs, file systems, GitHub repos, Slack channels? Before standardization, every developer was writing custom glue code for every integration. You'd write your Postgres connector, your colleague would write theirs, and some other team across the company was doing the same thing from scratch. Multiply that across an industry and you get an enormous amount of duplicated effort solving the same plumbing problem.

The second problem is orchestration. Once your agent can talk to things, how do you structure its reasoning? How does it decide what to do next? How do you give it memory that persists across a conversation—or across many conversations? How do you test it, debug it, and stop it from doing something catastrophic like (Clyburn's example, not a hypothetical) deleting your production database?

MCP solves the first problem. ADK solves the second. The video's core argument is that simple, and it largely holds up.

MCP: the USB-C of AI tooling

The Model Context Protocol is an open standard created by Anthropic. Its job is to define a common interface—a set of rules—for how an AI agent (the "client" or "host") talks to an external tool or data source (the "server"). The message format is JSON-RPC, which Clyburn describes as "almost like plain text." Local servers talk via standard input/output; remote servers use HTTP with streaming and authentication tokens.

What you end up with is something like a wrapper: write an MCP server once for, say, your Jira instance, and any MCP-compatible client can use it. You don't rebuild the integration when you switch models. The ecosystem of pre-built MCP servers already covers GitHub, Slack, Google Drive, Postgres, Figma, and more, with the community actively expanding it.

MCP has three core primitives: tools (functions the LLM can invoke, like running a SQL query), resources (things the LLM can read, like documentation or databases), and prompts (reusable prompt templates you don't have to rewrite each time). Clyburn emphasizes one thing developers particularly appreciate: "It doesn't matter if you're using Claude, GPT, Gemini, a local model, whatever. If it speaks MCP, it works." Model-agnostic is the operative phrase—your integrations survive a model swap.

Worth noting here: MCP exists in a growing ecosystem of agent communication protocols. Where MCP connects agents to data and tools, a separate question is how agents talk to each other—territory covered by protocols like A2A, which addresses agent-to-agent communication. The two protocols aren't competing; they're operating at different layers of the same stack.

ADK: structure for the part that's actually hard

Google's Agent Development Kit is where things get more interesting—and more complex.

ADK is an open-source Python framework. But calling it "just a framework" undersells what it's trying to do. As Gutowska puts it: "ADK isn't just making an LLM do stuff, it's a full stack system for building reliable multi-agent architectures."

Its core building blocks are agents, tools, memory, events, and runners. The runner is particularly elegant: it receives a user query, passes it to the agent, and then—when the agent yields a response (a tool call request, a state change)—takes back full control to handle the consequences before the agent sees what happens next. "The agent is suspended at each yield," Gutowska explains, "so it's giving the runner full control to handle consequences before the agent sees what's going to happen next." That pause-and-hand-off pattern is what makes ADK-built systems significantly easier to debug than agents cobbled together from ad hoc code.

ADK also makes a meaningful distinction between two kinds of memory: short-term state (working memory within a single conversation) and long-term memory (what persists across sessions, like user preferences). That's not a novel concept in software engineering, but it's one that a lot of hastily-built agents skip, and the omission shows.

The multi-agent angle is where ADK gets genuinely powerful. You can build a root orchestrator that delegates to specialized sub-agents—a research agent, a writing agent, a validation agent—each doing one thing well. And ADK gives you flexibility in how those agents operate: LLM-driven agents for tasks where reasoning flexibility matters, or deterministic workflow agents (sequential, parallel, loop-based) for tasks where you need steps executed in a fixed order. Less "trust the model to figure it out," more "this absolutely must happen before that."

The stack, not the choice

The video's thesis—that MCP and ADK are complementary, not competing—is correct, and the concrete example they use makes it click. Imagine building a coding assistant that can search a repo, run tests, open files, and debug problems.

ADK handles the cognition: how the agent reasons, when it decides to run a test versus search the repo, how it handles failure without cascading into something worse. MCP handles the connectivity: standardized, reusable interfaces to the repository, the test runner, the issue tracker.

"ADK defines what the agent should do," Clyburn says, "and MCP defines how it actually does those things by communicating with the world while doing them."

The video's title frames them as rivals; the hosts acknowledge, with some self-awareness, that the framing was algorithmic necessity. "The algorithm demanded we have some conflict," Clyburn admits. It's a small moment, but an honest one—and it's worth sitting with, because the AI tooling space is genuinely littered with false "vs." framings that create confusion where there shouldn't be any.

What the IBM framing doesn't cover

Clyburn and Gutowska are IBM developers making content for IBM Technology. That's not a disqualifier—the technical explanation is solid and vendor-neutral in the important ways. But there are things the video doesn't interrogate.

ADK comes from Google. MCP comes from Anthropic. Both companies have obvious stakes in how AI agent infrastructure gets standardized—whoever's protocol becomes the default has significant leverage over the ecosystem. The video treats both as neutral utilities, which they functionally are for now. Whether they remain so as the market matures is an open question worth tracking.

There's also the question of complexity overhead. ADK's structure is genuinely valuable for production systems, but it adds cognitive load. For a developer spinning up a quick prototype, the framework might be more scaffolding than the task requires. The video gestures at this without dwelling on it—"it depends" is their acknowledged cop-out before they walk through the concrete example. Fair enough, but real-world adoption decisions involve a lot of "it depends" that no 14-minute explainer can fully resolve.

And MCP, for all its elegance, is still young. The community-built server ecosystem is growing fast, but "community-built" also means varying quality, maintenance uncertainty, and security review gaps that enterprise teams will need to think through before plugging third-party MCP servers into production systems.

The deeper pattern

What MCP and ADK represent, taken together, is the industry's attempt to stop reinventing the same wheels. Custom integrations, ad hoc agent code, bespoke orchestration logic—these aren't engineering problems, they're engineering friction. Standardization is how mature industries eliminate friction, and the AI agent space is, belatedly, beginning to behave like a maturing industry.

The interesting question isn't whether MCP and ADK are useful—they clearly are. It's whether the standards that stick will be the ones that are genuinely best, or the ones backed by the companies with the most distribution. That race is very much still on.

---

Marcus Chen-Ramirez is a senior technology correspondent at Buzzrag.