MCP is the new API economy

A caveat upfront: this was a controlled demo, not a production environment. It took some setup to get the MCP servers configured and connected. But once that was done, the experience felt like what APIs were always supposed to feel like — and that's what caught my attention.

A brief history of me yelling at OAuth screens

If you've ever integrated a third-party API, you know the drill. Read the docs (ha, "docs"). Register an app. Get your client ID and secret. Implement the OAuth flow. Handle token refresh. Parse their specific flavor of JSON. Discover that their "v2" endpoint actually returns v1 responses on Tuesdays. File a support ticket. Wait three weeks. Give up and hardcode a workaround.

I've done this dance dozens of times. Stripe is great. Most others make you want to cry.

The promise of APIs was always beautiful: everything talks to everything. The reality was: everything talks to everything, if you have two weeks and a therapist.

MCP makes integrations easier (not effortless)

MCP (Model Context Protocol) is someone finally saying "what if integrations were significantly less painful?"

Here's the idea: instead of every AI tool building custom integrations for every service, you build one MCP server for your product. Any MCP-compatible agent can use it. In theory, that's a big simplification.

No SDKs per language. No webhook configuration hell. No "which version of the API are you on?" One protocol. Universal.

It's worth noting what MCP doesn't do: it doesn't eliminate integration complexity so much as shift it. The complexity moves from the app developer to the MCP server builder and the agent runtime. Someone still has to handle authentication, error states, and edge cases — it's just a different someone, working at a different layer. That's a meaningful improvement in many cases, but it's not magic.

The protocol got donated to the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, and Cloudflare backing it. Kong launched an enterprise MCP registry. Cloudflare built "Code Mode" that gives agents an entire API in roughly 1,000 tokens.

This isn't a side project anymore. This is infrastructure — though the protocol is still under active development and could see breaking changes.

Why agents change the integration model

REST APIs were designed for developers to integrate applications. MCP is designed for agents to integrate everything. That's a different design target, and it leads to different outcomes.

When I work with REST APIs, I build an integration once, maintain it forever, and pray the provider doesn't change their schema. API changes can break integrations, and maintenance is an ongoing challenge.

With MCP, agents can discover capabilities on demand, which reduces some of the brittleness. But it's important to be honest about the limits: if a service fundamentally changes its API behavior or schema, the MCP server wrapping that API still needs to be updated. The adaptation problem shifts from your app code to the MCP server layer — it doesn't disappear.

Cloudflare's Code Mode is an interesting example. They give an agent a compressed API description (the whole thing) in about 1,000 tokens. The agent reads it, understands the endpoints, and starts making calls. No SDK. No documentation deep-dive. No Stack Overflow.

I tried this with my own setup. Pointed an agent at an MCP server I'd never configured before. It figured out the available tools, understood the parameters, and started using them correctly. On the first try.

If you've spent any time debugging API integrations, you understand why I nearly fell off my chair.

The early mover window

The npm comparison is tempting but imperfect. When npm took off, it brought versioning, dependency resolution, lock-files, and a maturing quality ecosystem. MCP registries don't have most of that yet — which is actually the point. The infrastructure is nascent, and the people building it now are shaping what it becomes.

PulseMCP tracks servers across registries (their site lists thousands, though exact numbers are hard to pin down as the landscape changes daily). Kong's registry appears to be growing with enterprise-ready integrations, though I haven't seen independently verified numbers. Google launched managed MCP servers with enterprise security.

The developers who published popular npm packages early became indispensable. Their download counts became moats. Their packages became dependencies in thousands of projects.

A similar dynamic could play out with MCP — but it depends on whether the ecosystem develops the kind of quality infrastructure (versioning, security auditing, dependency management) that made npm's success durable.

If you build things

Build an MCP server

If your product has an API and you don't have an MCP server, you're increasingly hard to discover for AI agents. And AI agents are rapidly becoming a way people interact with software.

SaaStr reportedly started 2025 'AI-lean' with 20+ AI agents running their operations, showing how SaaS companies are under real pressure to be agent-compatible.

An MCP server isn't hard to build. A basic one for a REST API takes an afternoon. A good one (with proper capability descriptions, error handling, and streaming) maybe a weekend.

The payoff? Any MCP-compatible AI agent can now discover and use your product. Not just the ones you've built custom integrations for. That's a meaningful expansion of your integration surface.

There's a marketplace gap here

I keep looking for a "ThemeForest for MCP servers" — a place where you can buy a well-built, tested, documented MCP server for $49 and plug it into your stack. It doesn't exist yet.

Someone's going to build this. IT leaders are dealing with unexpected costs from AI features and integrations. They'll pay for plug-and-play solutions.

The opportunity is sitting right there: build an MCP server that wraps a common integration (accounting software, CRM, payment providers), package it nicely, sell it. The plumbing is standard. The value is in knowing the domain.

Solo dev math

I run my whole operation with AI agents and MCP. My content pipeline. My research. My code reviews. My scheduling. Not because I'm lazy (okay, partly), but because MCP significantly reduces the integration cost.

Before MCP, connecting a new tool meant hours of API work. Now it means: find an MCP server, point my agent at it, and — after some initial testing and configuration — it's running. That changes the economics of being a one-person company.

The rough math: if each MCP integration saves me several hours of custom API work compared to building a traditional integration, and I'm using 15+ integrations, the time savings add up fast. In practice it's not zero work per integration — you still spend time evaluating MCP servers (quality varies), debugging agent behavior, and configuring security. But even conservatively, I estimate I'm saving weeks of plumbing work over the course of a year. Time I can spend building actual features, writing actual content, or touching grass.

The problems nobody talks about

Before I sound like a VC pitch deck, some real talk:

• Security is still the wild west
  Giving an AI agent access to your services via MCP means trusting the agent with your credentials. TrueFoundry is building enterprise access control for MCP servers through their MCP Gateway, and Kong's doing governance layers, but we're early. Very early.
• Prompt injection is a real risk
  A malicious or compromised MCP server could potentially manipulate agent behavior through crafted tool descriptions or responses. When you give an agent broad tool access across multiple MCP servers, the attack surface grows — and the agent might take actions you didn't anticipate or authorize. This is an active area of security research with no settled solutions yet.
• Quality varies wildly
  Some MCP servers are production-ready. Others are someone's weekend project that breaks if you look at it funny. There's no npm-style quality scoring yet (though PulseMCP is trying).
• Finding what you need is annoying
  The registries exist but they're not great at helping you evaluate options. You end up searching and hoping.
• Vendor lock-in sneaks up on you
  The protocol is open, but the implementations often aren't. Google's managed MCP servers are great until you want to leave Google Cloud.
• The protocol itself is still evolving
  MCP is under active development, and breaking changes are possible. Building heavily on today's spec carries some risk that tomorrow's version may require rework.

These are solvable problems. But they're not solved yet. And some of them — particularly around security and agent predictability — are genuinely hard.

Where I think this goes

I'll frame this as a prediction, not a certainty: I believe that within roughly 18 months, "does your product have an MCP server?" could become as standard a question as "does your product have an API?" Used to be, no API meant no integrations. If the current trajectory holds, no MCP server may increasingly mean no agent integrations.

My bet is that agent integrations will start to matter as much as — and eventually more than — human-driven integrations. Not because humans are going away, but because every human will have agents doing their integration work for them. That's a prediction based on current momentum, not an inevitability.

The companies that see this coming — that build great MCP servers, that make their products agent-friendly, that publish capabilities instead of just endpoints — they're going to have a head start over everyone still forming committees about their MCP strategy.

And if you're an indie dev? You can have a server live this weekend while enterprises are still in meetings about it.

Worth doing. The ecosystem is hungry for good implementations.

If you're building with MCP and want to compare notes, hit me up on X. I'm deep in this rabbit hole and I'm bringing snacks.