MCP vs SDK: Why Protocols and Building Frameworks Are Different Layers

Much of the criticism around the Model Context Protocol (MCP) argues that teams should have built a software development kit (SDK) first, and that chasing MCP integrations such as claude-to-mcp delayed their products. That argument depends on mixing up two different layers of the stack. MCP is a connection protocol, and an SDK is a building framework. They do not compete for the same job, and treating them as rival strategies leads to the wrong conclusions about Google, n8n, and the choices facing your own team. This article reconstructs the reasoning so you can see what each layer does, how two well-known platforms made their choices, and which decision rule the evidence supports.

Summary

The criticism that teams chased MCP integrations like claude-to-mcp and therefore could not build an SDK, which delayed them, rests on a confusion of layers. MCP is a connection protocol and an SDK is a building framework. They are complementary, not competing. Google is not keeping pace because it built an SDK first. It can keep pace because it had the resources to build its agent development kit (ADK), its own agent-to-agent protocol (A2A), and adopt someone else’s standard (MCP) at the same time. n8n also has SDK-equivalent tooling. It already had a node development kit, and it layered MCP on top as an adapter. For n8n, prioritizing MCP was a generally reasonable move that produced large leverage for little effort.

Core diagram

Core data

1. MCP and SDKs are different layers (redefining the comparison axis)

	MCP (protocol)	SDK (development library)
What it is	Standard specification for agents and tools to talk to each other	Code kit for building something
Analogy	USB-C specification	The parts and tools that make the device
Question it answers	“How do we connect?”	“How do we build?”
Representative examples	Anthropic MCP, Google A2A	Claude Agent SDK, Google ADK, LangChain

The real comparison axis is not “MCP or SDK.” It is the choice between a strategy of plugging into a standard protocol and a strategy of growing your own building framework.

2. Google did not pick one; it installed the full stack

• ADK (Agent Development Kit, 2025): an open-source Python agent building kit, which is the SDK layer
• A2A (Agent2Agent, April 2025): a communication standard between agents, which is the protocol layer
• MCP adoption: ADK uses MCP tools directly
• A2A and MCP complement each other rather than compete: MCP connects agents to tools, and A2A connects agents to agents

The lesson from Google’s case is not “SDK first.” It is that Google had the resources to install all three at once. That is possible at Google’s scale.

3. n8n does not lack SDK-like tooling; its kind is different

n8n has the following SDK equivalents:

1. Node development framework: n8n-nodes-* npm packages, declarative and programmatic node APIs, and the n8n-nodes-starter template
2. Public REST API: controlling workflows from code
3. MCP as an adapter on top of the two: n8n works in both directions. It is an MCP server, exposing its own workflows as tools, and an MCP client, using external MCP tools. In 2025, its MCP server gained the ability to build workflows directly.

n8n’s identity is a visual, no-code automation tool. Building a code-first agent SDK, like ADK or LangChain-style frameworks, was never its lane. Pursuing one would have been an identity conflict.

4. Access surfaces: API, SDK, CLI, and MCP

A CLI is not an SDK. All four are different “access surfaces” built on the same REST API. The Notion example below shows how.

Surface	What it is	Who uses it and how	Notion example
REST API	Underlying HTTP interface	Called directly	api.notion.com
SDK	Library imported into code	Developers, inside their code	@notionhq/client
CLI	Program run from a shell	People or scripts, from a terminal	ntn
MCP	Protocol for agents to call tools	LLM agents	Notion MCP server

• SDK is “code you call”: you import it and call its functions as part of your program. CLI is “a program you run”: a shell command, usually a wrapper around an SDK or API. The CLI is a higher-level tool, not the SDK itself. They are cousins, not nested layers.
• This is a difference in audience, not a hierarchy. API, SDK, and CLI are human and developer surfaces, while MCP is an agent surface. The distinction is who the same API is opened to and in what shape.

5. Pros and cons of each strategy

MCP (plugging into a protocol)

• Pros: immediate access to an existing ecosystem, interoperability and portability because it is a standard, low implementation cost, and weak lock-in
• Cons: you depend on a specification you do not control, there are limits on fine-grained control and performance tuning, and versions can break while the protocol is still maturing

SDK (your own building framework)

• Pros: full control and full features, deep optimization, developer loyalty and ownership of the ecosystem, and a long-term differentiating asset
• Cons: high build and maintenance cost, slower adoption, isolation if it drifts from the standards, and fragmentation if it does not fit your identity

Insights

• The claim that an SDK should have come first is hard to support in general. In n8n’s position, MCP integration was the move with the greatest leverage for the least effort. Its more than 500 existing integrations and nodes became agent tools immediately. Reimplementing them with a custom SDK would take several months. Because n8n also works as an MCP client, it plugs into the ecosystem in both directions. Because MCP is a standard, the lock-in risk is low.
• The reasonable core of the criticism is this: if the goal was a developer experience for writing agents in code, MCP can feel like a patch over the underlying problem, which is the lack of a first-class building experience. The sense that things were delayed probably comes from the gap between that expectation and n8n’s no-code identity. It is less likely to come from MCP being the wrong choice.
• Decision rule: use a protocol when you want to plug into someone else’s ecosystem quickly, and use an SDK when you want to own and differentiate your own ecosystem. With enough resources, do both, as Google did. If your identity is no-code, do what n8n did: ship a node kit and adopt MCP. “SDK first” is not a universal answer. It depends on resources and identity.

Bottom line

The evidence supports treating MCP and SDKs as complementary layers rather than rival strategies. MCP connects agents to tools, and an SDK is how you build the agents and tools themselves. So the question is less about which one to do first and more about your resources and what you want to own. Google could build ADK, A2A, and MCP support at once. n8n kept its no-code identity, extended its node kit, and adopted MCP as an adapter. Neither case shows that building an SDK first would have been the right answer everywhere.

Sources

• Building MCP Server: SDK vs n8n, which one to choose? — Medium (Destiya Wijayanto) (accessed June 18, 2026)
• n8n’s MCP server can now build workflows! — n8n Blog (accessed June 18, 2026)
• Google ADK Introduction (4): Google ADK and A2A vs MCP and Traditional APIs — DEV Community (accessed June 18, 2026)
• Getting Started with MCP, ADK and A2A — Google Codelabs (accessed June 18, 2026)
• n8n MCP Guide: Server, Client Node, Workflows — UI Bakery Blog (accessed June 18, 2026)