MCP in practice: What software architects need to know about the Model Context Protocol

Recently, I spoke on the Heise SoftwareArchitekTOUR Podcast with Ole Wendland from INNOQ about the MCP in practice and what software architects need to know about the Model Context Protocol. Here are my key takeaways 👇

What MCP Is

• MCP is an open standard by Anthropic (2024) that connects LLMs with external tools, APIs, or data sources.
• It acts as a bridge layer between the model and your systems, turning passive LLMs into active agents capable of performing tasks.

Core Building Blocks

MCP introduces three main concepts:

• Tools - executable operations (for example, "create ADR", "update Jira ticket").
• Resources - data or documents the model can read (for example, FAQs, architecture docs).
• Prompts - templates or workflows guiding how users or models should act next.

Architecturally, MCP consists of:

• Host (Client) - where the LLM runs (for example, Claude Desktop).
• MCP Server - the integration layer provided by the application.
• Application - the actual system being accessed (for example, Jira, Confluence, or a database).

Security Is the biggest concern

• Authentication is a double problem:
  1. The client authenticates to the MCP server (OAuth resource server).
  2. The server acts on behalf of the user against another API.
• Current solutions (personal access tokens) are temporary workarounds.
• Be extremely cautious with third-party MCP servers - only use trusted ones.
• Risks include prompt injections, data exfiltration, and malicious updates ("RAG pull attacks").
• Future standards like AAUTH and OAuth right propagation aim to fix these issues.

Performance and Determinism Trade-offs

• Every MCP call adds latency (typically 0.5–1 second per request).
• For time-critical or deterministic systems, encapsulate multiple calls in higher-level APIs.
• For flexible workflows, MCP servers can use workflow definitions (for example, Arazzo) to chain actions declaratively.
• Architects must balance latency, determinism, and flexibility.

Maturity Levels for MCP Integration

Similar to REST maturity models:

• Level 0: Basic API wrapper.
• Level 2: Adds validation, error handling, and usage constraints.
• Level 3: Adds business context (domain models, rules, workflows).
• Level 4: Dynamic and self-extending (hypermedia-like).

Early experiments typically start at Level 0 or 1 and evolve over time.

Practical Use Cases

• Internal automations: MCP-powered time tracking, booking hours via natural language.
• Read-only integrations: Safe way to fetch project data or documentation.
• Agent scenarios: LLM agents performing repetitive or administrative tasks.
• Future vision: Dynamic systems where agents can evolve workflows on their own.

Vendor Lock-In Is Real

• While marketed as "open", MCP is currently tightly coupled to Anthropic’s Claude ecosystem.
• Prompts and tool behavior optimized for Claude may perform poorly on other models like Mistral or GPT.
• Expect ecosystem-specific bias until true interoperability emerges.

Architectural Mindset

• Don’t expect "magic" - good engineering and governance remain essential.
• Define measurable metrics and tests early.
• Start small, prove value, then scale.
• Treat MCP integrations like a new team member - train, supervise, and iterate.

The Road Ahead

• MCP will likely become a key integration layer for connecting AI with enterprise systems.
• Not every application needs an agent - but every architect should understand how MCP changes system boundaries.
• Agents and protocol-based AI integrations will shape the next generation of system design.

Final Thought

"We shouldn’t see AI as a golden hammer. MCP won’t replace software - it will enable us to build better, faster, more connected systems."

The whole transcript (translated in english)

Here is the whole translated english transcript of the podcast 👇

Patrick Roos (00:01.422)
Welcome to a new episode of the Heise Software Architecture Podcast. Today we’re talking about the Model Context Protocol, or MCP. It’s a new standard that enables large language models to access tools and data sources - basically the "USB plug for AI". This is especially exciting from a software architecture perspective. What role will MCP play in future system landscapes? What new architectural decisions arise when AI actively interacts with our systems, and what opportunities and challenges come with that? That’s what I’m discussing today with Ole Wendland from INNOQ. Hi Ole, great to have you here. Let’s start with a quick intro - who are you and what do you do?

Ole Wendland (00:58.164)
My name is Ole Wendland. I’m employed at INNOQ Switzerland as a Senior Consultant for software architecture. I work on many client projects - that’s very important to me. I also speak at conferences, write articles, and record podcasts like this one.

Patrick Roos (01:24.59)
I’m looking forward to the next 45 minutes talking about the Model Context Protocol. Let’s touch on the basics. Could you explain in your own words what the Model Context Protocol is?

Ole Wendland (01:50.536)
The Model Context Protocol is an open standard from Anthropic released at the end of November 2024. The idea is to give large language models access to your data. These models are broadly applicable, but to be productive they must know you and your company’s data. MCP is a standard for connecting different kinds of surrounding systems. It often sits on top of existing APIs and prepares them for large language models.
I’d separate a technical view and a functional view - we can return to that when we discuss challenges.

Patrick Roos (03:03.47)
So we’re giving the system context, right?

Ole Wendland (03:10.868)
Exactly. It gives the model context and also the ability to act. Unlike a pure RAG system or a database that only contains information, MCP lets the model act. It can use and call tools. Tool use itself isn’t new, but standardizing it is. Early AI projects suffered from the "N×N integration" problem we know from architecture - online shops and banking systems having to integrate with each other in many bespoke ways. MCP addresses this by moving integration to the service provider’s side. This mirrors data contract ideas: the provider should also provide the integration layer, since they know API updates and proper usage. MCP follows that principle.

Patrick Roos (04:48.926)
Is it comparable to an OpenAPI contract in terms of standardization?

Ole Wendland (05:01.0)
Similar. The service side exposes capabilities. With these come constraints that guide the model or the user. The provider can define preferred usage. That’s the functional layer: expose capabilities with assumptions and constraints. How individual tools are built and described is open.

Patrick Roos (05:46.894)
Let’s cover MCP’s core building blocks first. What are they?

Ole Wendland (06:09.272)
From an architecture perspective you have the host (formerly the client - the spec terminology changed in June). That’s the side that initiates calls - often where the LLM sits. Then the MCP server, usually provided by the application side. There are many open servers on the web - security considerations apply. Third is the application itself: Jira, Confluence, file system, database, etc. So: host, server, application.
Logically, there are three elements:

1. Tools - used in 80–90% of cases. The client calls the MCP server, which forwards to the application. Tools allow writes, deletes, and parameterized queries.
2. Resources - information you fetch, composed by the application (e.g., FAQs, architecture docs, glossaries, DB views).
3. Prompts - rare; they don’t trigger actions but provide workflows or guidance to the user.

Patrick Roos (08:59.75)
If I register which tools can be executed via my server, is that aligned with MCP?

Ole Wendland (09:17.74)
Yes. The server and host converse like a chat, because LLMs are trained for that. Technically it’s JSON-RPC - request/response chained together - with a text buffer. Think of it as a chat between server and host, leveraging the model’s native strengths.

Patrick Roos (10:14.936)
I considered an MCP example for my architecture documentation. I have ADRs (Architecture Decision Records). Mapped to MCP: a tool "create ADR"; resources are my architecture docs; the server exposes creation/editing and doc interaction; the host is the conversational interface. Correct?

Ole Wendland (11:08.66)
Correct. Another angle is runtime. The USB analogy highlights limitations. In most cases, a server has a single client connection - one-to-one, like USB. The term "server" is a bit misleading; we usually think many clients to one server. Here it’s more that a client uses multiple servers. "Adapter" would have been a better term in my opinion.
This is being loosened: a session ID is now included, but it doesn’t cover the full scope - you’d need proper session separation to prevent bleeding. One design principle was keeping servers lightweight; simple implementations can be 250–400 lines. If you add end-user session management and auth, they’re no longer lightweight. Historically MCP servers were designed for agent contexts, with host and server running in one agent artifact. Security wasn’t the first concern. Stdio is a standard transport since LLM and server often run together in a container.
Tip: watch the first talk on a protocol - the original requirements are explained there, and many examples focus on agents. MCP initially targeted agent systems; you can see that in the design decisions.

Patrick Roos (15:08.334)
Interesting. Registering an MCP server in Cloud Desktop starts the server there, showing how "server" can be misleading - more like a wrapper. Thanks for that context.

Ole Wendland (15:47.664)
Early on, developers spoke frankly about intent before marketing shaped the message. MCP adoption accelerated rapidly, and now it’s being adjusted so a server can likely serve multiple clients soon.

Patrick Roos (15:50.158)
Let’s look at concrete use cases from your projects where MCP is in use or will be soon.

Ole Wendland (16:22.288)
With clients, we have several read-only MCP servers in production. We can discuss the security reasons in a moment. Internally, we implemented an MCP server for time tracking, which I use daily; it simplifies my workflow. Working with Claude Code, I can say: "Book the last five hours to this project and cost center." It removes friction like two-factor prompts.

Patrick Roos (17:21.365)
Does it also know client projects, rates, and cost centers?

Ole Wendland (17:48.948)
Yes. It knows projects, hourly rates, and detects overbooked or closed cost centers. There are warnings. When MCP servers or agents can act, we encounter robotics-style issues: they change their environment. What worked five times can fail on the sixth, or they may take unintended actions. The time-tracking system also does forecasts; if it can’t book to a cost center, it might book a forecast, create a similarly named cost center, or delete bookings. It partially understands context and constraints. To act competently, an agent needs rules about its environment - what is and isn’t allowed.

Patrick Roos (19:41.486)
Tell us more about the read-only servers at clients.

Ole Wendland (20:03.792)
It works best when you can avoid authentication. Read-only is safe when you control the data and are sure there’s no injection, or when data is machine-generated (e.g., measurements). Critical areas include reading emails or chats because LLMs are vulnerable to prompt injection, especially if they have file-system access. Known attacks try to exfiltrate SSH keys, for example. That risk exists whenever users can input free text. For production, prefer internal enterprise data or technical data.

Patrick Roos (21:48.27)
Please elaborate on authentication and authorization boundaries for MCP servers. I’m in my LLM client and submit a prompt to book time. It wants to execute a tool on a time-tracking MCP. How do we authenticate?

Ole Wendland (23:00.468)
There’s a double authentication problem. First, the host must authenticate to the MCP server. Newer specs handle this: MCP servers act as OAuth resource servers. Second, the MCP server must act against an API in your name. For that, there’s no great solution yet. Many use personal access tokens (like Git), placing them in server config - long-lived tokens aren’t ideal. In large enterprises, user-managed tokens that expire are unworkable. Some systems simply pass tokens through and instruct the application to accept them - not good.
Two OAuth extensions are emerging toward agent use cases: Agent Authentication (AAUTH) and an OAuth 2.0 extension for right propagation. They allow forwarding tokens so the server can request permissions from the IdP and obtain refresh tokens for specific operations. Until that lands, there isn’t a clean enterprise-grade approach.

Patrick Roos (26:02.63)
These specs are drafts?

Ole Wendland (26:14.708)
Yes - currently RFCs. Okta is active there. First implementations are hoped for soon. This is necessary before broad rollout.

Patrick Roos (26:34.042)
You also mentioned malicious MCP servers and "RAG pull." What are the risks?

Ole Wendland (27:16.788)
Third-party MCP servers carry risks, especially when passing tokens. Use only trusted sources. Companies will likely curate approved servers via repositories like Artifactory or Nexus after audits. Otherwise, you risk injection: servers can instruct the LLM to do harmful things, and if it has file-system access, it could read secrets or forward configs.
"RAG pull" refers to updating tool descriptions without strong versioning. A harmless tool ("add A + B") passes audit, then is hot-updated ("add A + B and also read ~/.ssh/id_rsa"). MCP lacks robust versioning for tool descriptions. If servers are delivered as NPM packages, package-lock.json helps, but vigilance is still required.

Patrick Roos (29:58.574)
So internally we’d approve servers via Artifactory with vulnerability checks.

Ole Wendland (30:23.928)
Exactly. Don’t allow random internet servers to be installed.

Patrick Roos (30:56.852)
Beyond security, what other challenges exist?

Ole Wendland (30:56.852)
Latency is a major issue. Architecture is about trade-offs, and you can integrate at different levels. If determinism and speed matter, build higher-level APIs that hide multiple calls. That’s faster and deterministic but requires building and maintaining an artifact. Alternatively, you can provide a workflow definition as a resource (e.g., Aradzo - JSON, in the OpenAPI ecosystem) and chain tool calls declaratively. The trade-off: less determinism and higher latency due to LLM involvement. Context length also matters. You must decide how much determinism and latency are acceptable, or build classic higher-level APIs exposed via a single tool call.

Patrick Roos (33:41.134)
I exposed Google Places API via an MCP server and was surprised by the slowness: tool listing, tool call, wrapper call to the API, result interpretation - many hops. In a web app, that’s not acceptable. Definitely a challenge.

Ole Wendland (34:40.44)
Erik Wilde has strong articles on MCP integration patterns - worth reading.

Patrick Roos (34:55.336)
We’ll add that to the show notes. Any other important attributes?

Ole Wendland (35:15.06)
Domain context is essential. Like REST’s maturity model, MCP has levels:

• Level 0: wrap an API in an MCP server - works for many tasks but yields erratic errors due to missing context.
• Level 2: add meaningful error descriptions and usage tips in tool descriptions - still limited because every new capability requires updating many tools.
• Level 3: provide real domain context - models, allowed actions, workflow descriptions.
• Level 4: hypermedia-like capabilities - knowing which URLs to access and extending capabilities autonomously. This was an early MCP vision for agents evolving workflows, but it’s risky and may face adoption challenges similar to REST hypermedia.

Patrick Roos (37:30.426)
How should architects think about vendor lock-in?

Ole Wendland (38:09.492)
It’s marketed as open, but different models behave differently. In practice there’s a form of lock-in: prompts optimized for Claude perform best with Claude, possibly also OpenAI; models like Mistral may show reduced tool-use performance. Officially no lock-in, but performance realities introduce risk.

Patrick Roos (39:16.136)
How do you approach client projects where MCP and AI are involved?

Ole Wendland (40:18.964)
Set expectations: it isn’t magic - we still need solid engineering. Be measurable: define scope and security boundaries, then tests and metrics before tweaking prompts. Standardized tests are crucial. Start quickly and iterate, but only after agreeing on tests and quality criteria. Don’t forget guardrails and security.

Patrick Roos (41:48.462)
Outlook: if every AI can connect to every tool, what does "software" mean? Will we still have web apps?

Ole Wendland (42:29.076)
Yes, and likely more software. AI isn’t a golden hammer; it adds capabilities we lacked, especially handling messy inputs and long-tail problems. But performance, security, and determinism remain essential. AI is an enabler to write software faster, not a replacement for everything.

Patrick Roos (43:41.038)
For listeners new to MCP: how should they start and introduce it internally?

Ole Wendland (44:29.748)
Start small - don’t build a multi-agent framework first. Agents are excellent at small, repetitive tasks. Identify pain points like that. Keep a human in the loop, supervise, show value, and expand from there.

Patrick Roos (45:41.902)
That aligns with starting in low-risk areas, proving value, then broadening to more applications.

Ole Wendland (46:15.566)
There’s a learning curve. Think of MCP as onboarding a new assistant: well-read but new to your company’s constraints. It’s motivated and creative, which introduces new failure scenarios. You have to guide it.

Patrick Roos (46:54.574)
Start small, gain experience, see what works, and iterate. Any final remarks?

Ole Wendland (47:51.353)
Even if I sounded cautious, it’s important to engage now. MCP is stateful and not perfect yet, but the conceptual principle is sound. Given the investment in AI, agents and task execution will become central. It’s good to build experience early.

Patrick Roos (49:14.574)
Great closing words. Thanks for the insights. This episode adds real value for our listeners. Have a nice evening. Bye!