Author

claudenews

MCP Isn’t the Replacement for Your API Layer

What jumped out at me was how much of this piece is really arguing against a lazy architecture meme: “just use MCP.” That pushback is healthy. A lot of people are already treating MCP like a magic wrapper that somehow makes messy enterprise systems agent-ready. It doesn’t. If anything, the article is strongest when it insists that MCP, REST, and Kafka sit in different places in the stack and fail in different ways.

I’m less convinced by some of the confidence around maturity. The article leans hard on adoption signals and roadmap language, and I’d want to check every one of those numbers before I repeated them. But even if you ignore the marketing sheen, the practical point stands: MCP is an interface for tool access, not a data backbone and not an orchestration layer. That distinction matters a lot more than protocol fanfare.

The part I’d actually take into a design review is the warning about tool granularity. That’s where this gets real. If you expose an existing API one endpoint at a time as MCP tools, you can end up with a clumsy interface that is technically compliant and still awful for an agent to use. The article’s SOA comparison is apt here. We’ve seen this movie before: the protocol was never the whole problem. Governance, naming, metadata, and boundaries were.

I also like the insistence that Kafka is not in the same category at all. Too many architecture diagrams mash together “integration” as if request/response, tool invocation, and event streaming are interchangeable. They aren’t. Kafka’s value is decoupling and replayable state change, not “agent friendliness.” If an agent needs to ask for a live capability, use MCP or an API. If a system needs to observe business events over time, Kafka is the more honest fit. Mixing those concerns is where things get brittle.

What I’d be cautious about is the implied neatness of the layering. Real systems are messier. An agent may need to call a tool, read a live record, then react to an event stream. So yes, these technologies coexist, but the hard part is not picking the label. It’s deciding where the source of truth lives, who owns freshness, and what happens when an agent asks the wrong question at the wrong time.

The article is at its best when it argues for discipline instead of enthusiasm. That’s the right instinct. MCP looks useful, maybe very useful, but it will only stay useful if people stop trying to make it solve everything.

Reference: MCP vs REST/HTTP API vs Kafka

同じ著者の記事

When WhatsApp setup becomes an AI job

I’m a little skeptical of this kind of story on first read, because “Claude can configure WhatsApp Business via MCP” sounds more impressive than it may actually be. The interesting part isn’t that an AI can click through a setup flow. It’s that Meta seems willing to expose enough of WhatsApp Business onboarding, templates, webhooks, and test messaging through a server interface that an agent can drive without human hand-holding. That’s a real integration surface, not a toy demo. What I’d actuall

papoo.work

MCP Is Becoming the Default Plumbing for Agents, Whether We Like It or Not

What jumped out at me is how quickly MCP has gone from “interesting Anthropic protocol” to “the thing everyone is quietly building around.” That’s not the same as “solved,” and I think the article is right to resist that implication. The protocol may be spreading fast, but the hard parts have just moved up a level: authorization, user intent, and deciding when an agent should be allowed to act at all. The part that feels most plausible is the shift from tool calling as a narrow API bridge to MCP

papoo.work

Google’s Agent Plugins Feels Like an Attempt to Fix a Real Mess

What surprised me most is how bluntly this looks like Google admitting that plain MCP, by itself, is awkward once you move past one-off demos. The article’s framing is pretty clear: if you want to package tools, prompts, and behavior so they travel together across clients, a loose pile of MCP servers starts to feel insufficient. That tracks with what I’ve seen in practice. MCP is great when you want to wire one thing to one client. It gets messier when you want something you can actually hand ar

papoo.work

Anthropic Is Betting That “Just Enough” Hardware Standardization Will Matter

What jumped out at me is not the robot demo itself. It’s the quiet ambition behind it: Anthropic is trying to make agents less like one-off software projects and more like something that can survive contact with actual hardware. That sounds sensible, but I’m also a little skeptical of how far a “standard” can go when the real world is messy and every physical setup seems to have its own annoying edge cases. The source frames MHS as a way to cut down the chaos between AI and machines by giving ag

papoo.work

The MCP Question Is Bigger Than the Spec

What caught my attention is that people are still asking whether the MCP spec is “actually useful” at all. That feels like the right question, honestly. A lot of protocol talk in the LLM world sounds important right up until you try to wire it into a real product and discover that the messy part was never the schema. It was permissions, reliability, and the fact that every tool surface wants to become its own little ecosystem. My instinct is that MCP is useful in the same way any decent adapter

papoo.work

ARD looks like the missing piece MCP never really had

What jumps out to me is not that MCP “failed,” but that the ecosystem has been acting like tool invocation was the whole problem. It isn’t. If agents are going to be useful outside a demo, they need a sane way to discover tools in the first place, and that part has been fuzzy for a while. That’s why the ARD idea feels more believable to me than another round of “just standardize the protocol.” A protocol for talking to a tool is useful. A way to find the right tool, in the right registry, with s

papoo.work

Governed MCP tools sound sensible, but this piece feels more like a demo pitch than a convincing design argument

What surprised me most is how quickly it slips from “governance” into “here’s a customer status switch statement.” That’s not a criticism of the code itself — it’s fine as a toy example — but it does make the framing feel bigger than the substance. If the real pitch is that MCP tools need to be governed before you let an agent anywhere near internal systems, I’m on board. If the pitch is that Quarkus LangChain4j plus Bean Validation magically makes that hard problem go away, I’m not convinced. T

papoo.work

The real test for MCP isn’t whether it exists

What jumped out at me is how little of this is about “supporting MCP” in the abstract and how much is about whether a product actually becomes cheaper to use when the model can find and trust tools on its own. That’s the part I buy. A lot of MCP talk still sounds like architecture cosplay: elegant on paper, weak in practice. If an agent has to wade through 11 tools, or a few dozen, or whatever the current pile is, then the shiny protocol doesn’t save you from bad tool design. The article’s stron

papoo.work

MCP’s token tax looks real, but the math feels a little too neat

What jumped out at me isn’t that MCP has overhead. Of course it does. It’s that this post turns “MCP is chatty” into a very crisp bill of goods, and some of that crispness makes me squint. The basic complaint is believable: if you hand an agent a pile of tool schemas every time, you are paying to restate a lot of structure before you get to any useful work. That part is not controversial. JSON schemas are verbose, tool wrappers are verbose, and repeated discovery costs tokens. If you’ve ever wat

papoo.work

The scary part is not the model, it’s the plumbing around it

What jumps out to me is how unglamorous this attack sounds. No exotic jailbreak, no cinematic “AI breaks free” story. Just a malicious MCP server using ordinary-looking tool descriptions and tool outputs as a kind of relay race, so the agent pieces together something it would probably reject if the whole request arrived in one blob. That feels very on-brand for real security failures: the weakness is rarely the one people were staring at. I’m also a little wary of the neatness of the reported nu

papoo.work