Forem: Tobias Herber

Why Your AI Agent Needs MCP (And When It Doesn't)

Tobias Herber — Sun, 26 Oct 2025 16:42:00 +0000

You've built an AI agent. It's smart, it's conversational, and it can reason through complex problems. There's just one problem: it lives in a bubble.

Your agent can't check Slack, pull data from your Postgres database, read files from Google Drive, or update tickets in Linear. Every time you want to add a new integration, you're staring down weeks of custom API work, authentication headaches, and the inevitable "wait, their API changed again?" moments.

This is the N×M problem, and it's been quietly killing AI agent projects for years. Every agent needs to connect to M services, and every service speaks a different language. The math is brutal: 10 agents × 50 services = 500 custom integrations to build and maintain.

Enter the Model Context Protocol.

What MCP Actually Solves

MCP addresses the challenge where every new data source previously required its own custom implementation by providing a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol.

Someone, maybe it’s you, maybe it’s someone who puts their implementation on GitHub, writes an MCP server. People often think of it this way: Before USB-C, your laptop needed different ports for everything (power, display, data transfer, peripherals). Each required its own cable, its own standards.

But here's what makes MCP different from just another API standard: it's built specifically for how AI agents actually work. MCP enforces consistency with well-defined input schemas per tool and (ideally) deterministic execution. In a perfect word, OpenAPI would do the same for HTTP. But sadly, we don’t live in a utopia.

Four Reasons Your Agent Needs MCP

1. Development Velocity

The integration problem compounds exponentially. Each service has its own authentication flow, rate limiting strategy, error handling patterns, and data models. The teams we talk to often end up integrating the same applications over and over again for different projects, with only one third of organizations' internal IT software assets actually available for developers to reuse.

MCP flips this equation. Build or configure the integration once, use it everywhere. MCP enables AI agents to better retrieve relevant information and produce more nuanced code with fewer attempts.

The difference shows up in iteration speed. MCP allows quick validation of agent ideas before building anything, enabling comprehensive testing without writing code. You can prototype with real integrations, see what works, and only then commit to building production workflows.

2. Reusability at Scale

Traditional API integrations don't travel well. The Stripe integration you built for Project A needs substantial rework for Project B. The authentication layer you wrote for the customer dashboard won't work in your internal tools. You're constantly rebuilding variations of the same thing.

MCP enables a new form of reuse purpose-built for LLMs and agents, with tools, data, and workflows exposed in a format AI models can directly use without wrappers or custom integration, plus dynamic reuse where LLMs discover and use existing systems in real time.

The ecosystem effect matters here. The MCP ecosystem has grown rapidly with over 16,000 MCP servers available, covering everything from databases and file systems to development tools and productivity applications. When you need a new integration, there's a decent chance someone's already built it. When you build one, others can use it (as long as you give it to them).

3. Security and Compliance

Giving AI agents access to your data infrastructure raises legitimate security concerns. With traditional API integrations, you're managing authentication, authorization, and audit logging separately for each service. The attack surface grows linearly with each integration you add.

MCP standardizes authorization using OAuth 2.1 with mandatory PKCE (Proof Key for Code Exchange), providing enhanced security right out of the box and protecting against common attacks like authorization code interception.

More importantly: This approach allows enterprises to integrate their existing Single Sign-On infrastructure, enabling users to access any MCP server using standard corporate credentials while maintaining centralized identity management and audit logging across all deployments.

The tradeoff? MCP servers represent high-value targets because they typically store authentication tokens for multiple services, creating a "keys to the kingdom" scenario where compromising a single MCP server could grant attackers broad access to all connected services. This isn't unique to MCP—any integration hub faces this problem. The solution is proper token management, rotation policies, and treating your MCP infrastructure with the same security rigor as your authentication service. The classic painful parts of security.

When You Might Not Want to Use MCP

Here's the part where we get honest: MCP isn't always the answer.

Skip MCP If You Only Need 1-2 Simple Integrations

The value of MCP is limited when integrating only a few tools where the overhead of MCP implementation isn't justified.

If you're just pulling data from a single Postgres database, a direct connection is probably simpler. MCP's power comes from orchestrating multiple services—if you don't need that, you're adding unnecessary abstraction.

Skip MCP for Ultra-Low Latency Requirements

For high-performance, low-latency applications, direct API calls are more efficient, as MCP adds a reasoning layer that introduces latency as the model decides how to use tools.

If you're building high-frequency trading algorithms, IoT sensor networks, or anything where sub-100ms latency is critical, the overhead of MCP's reasoning layer will hurt. Direct API calls give you predictable, minimal latency.

Skip MCP in Highly Regulated Industries

For regulated industries, MCP currently lacks native support for end-to-end encryption, is not certified under SOC 2, PCI DSS, or FedRAMP, and has sparse documentation that regulators expect.

If you're in healthcare, finance, or any industry where compliance certifications matter more than velocity, traditional API approaches with established audit trails might be necessary. MCP is maturing fast here, but it's not quite enterprise-certified everywhere yet.

Here’s the catch though: Metorial solves those problems for you. Let’s go through that list step by step.

You can set up any of our more than 600 MCP server on Metorial in just a couple of clicks, not matter what you’re not going to be this fast integrating them yourself
Metorial’s proprietary (but open source) MCP engine solves this by using magic, i.e., our own MCP compatible protocol, heavy container optimization, our proprietary hibernation technology, and more.
We’re SOC2 and GDPR compliant. One less thing for you to worry about. One less thing for legal and procurement to bug you about.

Getting Started (The Easy Way)

The MCP ecosystem is growing exponentially, but let's be real: the developer experience is still maturing. Developer experience limitations include substantial complexity in implementing MCP servers, with basic examples requiring hundreds of lines of code and limited testing options.

This is where platforms like Metorial come in. Instead of configuring individual MCP servers, dealing with authentication for each service, and maintaining everything yourself, you get 600+ integrations that just work. A few lines of code, and your agent can talk to Slack, GitHub, Notion, Stripe, Postgres, and hundreds of other services.

It's the difference between building your own USB-C calbe or just ordering one off of Amazon.

The Bottom Line

MCP is winning for agentic AI applications. Major developer-focused companies like Zed, Replit, Stripe, Linear, OpenAI, and Cursor jumped on MCP quickly, indicating strong demand for a standardized way to integrate AI with development environments.

But winning doesn't mean universal. Use MCP when you need to orchestrate multiple services, enable agent autonomy, or ship integrations fast. Use direct APIs when performance, control, or simplicity is paramount.

The best teams use both strategically. They prototype with MCP, optimize critical paths with direct APIs, and focus their engineering time on what actually differentiates their product.

Whether you build your own MCP implementation or use a platform like Metorial, the important thing is choosing the integration strategy that lets you ship faster. Because at the end of the day, the best integration approach is the one that gets your agent into production.

Building AI agents that need reliable integrations? Check out how Metorial makes connecting to 600+ services as simple as a few lines of code.

My First Time Vibe Coding: A Skeptic's Journey

Tobias Herber — Fri, 24 Oct 2025 04:51:05 +0000

It’s October 2025 and it’s my first time vibe coding. I have mixed feelings.

Frankly, when vibe coding tools came out I was very skeptical. Don't get me wrong, I like using LLMs and I've gotten so used to GitHub Copilot just completing my thoughts in VSCode and Vim. But generating entire code bases with LLMs? I'm not so sure about that.

Then from time to time, I looked at code from Lovable, Repl.it, and Cursor that my friends had sent me. I wasn't impressed. It was full of redundancies. It wasn't elegant. It was code that's fine for a beginner, someone making their first strides at building products, not someone I would let touch an actual production code base.

Also for context, here at Metorial we build infrastructure that's capable of running tens of thousands of MCP servers concurrently. We basically invented hibernation for MCP. Everything is completely custom and there is actual production infrastructure that our customers rely on behind it. Not something to play around with. But the other day I had this idea for a better MCP testing playground, called Starbase. Starbase is an experiment. A toy. Starbase can't take our customers down. Starbase can't expose our customer's data.

People keep telling me that they vibecode so much now and I'm always like "yeah, nah!". This time, I thought I should give it a shot and Starbase is the right opportunity to do so. Not much at stake, but a lot to learn.

This isn't a benchmark or anything even close to scientific. It's just my learnings as an anti-vibecoder vibecoding for the first time.

Setting the Scene

I used Claude Code. I felt like that's probably the best option for someone like me. I could still use the terminal, don't have to learn too much new, and don't have to switch to a new text editor.

I wanted to give it a fair chance so I actually put some effort into writing the first prompt. Clearly explaining what I want it to build. Giving it technical directions. Very precisely explaining the UI and the functionality.

I used a stack that it would probably have a lot of data for: Next.js + Prisma + styled components. I don't want to hear anything about Tailwind! I write CSS so should Claude Code.

I tried to go step by step. I had it build a very basic version initially. Something that barely functions and lacks the features I really wanted. I then iterated feature by feature asking it to add them.

And you know what? The first thing it gave me was impressive. It had a clear vision of the UI and except for a few minor bugs, it delivered. It looked cool. It worked well enough for a prototype. I was seriously reconsidering my stance on vibecoding.

Then came the advanced features. Starbase is an MCP playground. Nothing complicated but also more than a todo list. MCP connections aren't super straightforward and I wanted to do the MCP connections client side while of course running the models on the backend (to not leak our API keys). A basic auth system. Some simple tables to store previous server connections. Nothing crazy.

The back and forth

And then began the back and forth. It made mistakes, lots of them. Every time I got it to fix one, another one would pop up. It was tedious. Some mistakes were simple and it fixed them well. Some were difficult, like the MCP connection handling, and it really struggled with them.

The MCP client-side connection logic was where things got messy. Claude Code would generate code that might look right at first glance, but it kept mixing up where the connection should be established versus where it should be used. I'd point out the issue, it would fix that specific instance, and then introduce the same pattern in a different file.

What frustrated me most was the lack of consistency in error handling. Some functions would throw errors, others would return null, and some would just silently fail. When I asked it to standardize error handling across the codebase, it would update the files I mentioned but leave the rest untouched. It couldn't maintain a holistic view of the project’s architecture (that shouldn’t be a context problem to context is more than big enough to fit the entire code base into it).

The code quality

The code is far from perfect. It's often very inconsistent. It doesn't adhere to the standards you've given it (or even try to set it’s own standards). This reassured my initial feelings about vibecoding. The code is like someone trying to learn and play around. Not someone who has years of experience and does stuff the right way. It’s not a senior engineer and not even a junior.

The styling was all over the place. Despite my explicit instruction to use styled components consistently, I found inline styles sprinkled throughout and some components using Tailwind. When I called this out, it would fix the issue and then after a while generate some new code with the same issue.

The code structure showed no understanding of separation of concerns. No modularity. No reuse. Business logic lived in components. API calls were duplicated across files. Utility functions that should have been extracted were copied and pasted. When I asked it to refactor, it would clean up some stuff but underlying problems remained.

The comments were insane. Most good code is self documenting. Comments should add extra context; the code explains what (if possible), the comments explain why. Claude commented everything in grave detail. Things that are super obvious had a comment explaining what they do.

My take on vibe coding

I'm a bit torn. On the one hand I am impressed. What it built works. And I was able to do other stuff while babysitting the model here and there. At the same time, after having read the code, I wouldn't let Claude Code even remotely close to Metorial's primary codebase. There's too much at stake. But that highlights an interesting point. There is code where a lot is at stake. Hell, some people are out there writing code that, if it malfunctions, could kill people (not including the people who intentionally write code for killing people). On the other hand, there are codebases where bugs just don't matter that much. Internal tools, or experiments, like Starbase.

In addition to that is the fact that I love writing code. And I know many software engineers do too. There's a reason we sometimes talk about recreational programming. There's a reason why many devs work on OSS and side-projects on the weekend. Vibecoding takes that away. Instead of being the maker, you are the supervisor, which isn't fun.

So my conclusion is that I've learned a lot and become a bit more open about vibecoding. While also having my initial fears and biases against it reinforced. It's an interesting tool that, if used correctly, can help many devs (and of course non-technical people) become more productive. But it's no replacement for humans and it takes away the fun. The real value proposition became clear to me afterwards: vibe coding is perfect for the stuff you don't want to write anyway. Boilerplate. Proof of concepts. Internal tools that five people will use. But for anything that matters, anything where code quality affects maintainability, reliability, or user trust, you still need human developers who care about the craft.

Would I use it again? Absolutely. For the right project. But for now, keep it far away from anything that actually matters.

Building something with MCP? Check out Metorial. We make it dead simple to integrate 600+ tools with your agents. Open source, great SDKs, and actually maintained by people who understand infrastructure.