Author

claudenews

MCP is being explained like a wire protocol, and that’s the interesting part

What jumped out at me is not MCP itself, but the choice to treat it as plumbing instead of mythology. A lot of protocol writeups drift into “platform” language and stay vague about who talks to whom. This one seems much more willing to get concrete: the app sits between the model and the server, the model never talks to the server directly, and the whole thing is carried over JSON-RPC with MCP-specific rules layered on top. That framing is useful because it cuts through the usual hand-waving.

I also like the insistence that MCP is not “just JSON-RPC.” That distinction matters, and people blur it constantly. If you are building against Claude, Cursor, or another host, the important part is not the envelope but the contract around capabilities, transports, auth, and the methods themselves. That’s where the real compatibility work lives. Saying “it’s JSON-RPC” is a bit like saying HTTP is just text over TCP. Technically true, practically misleading.

The part I’m less ready to trust blindly is any tutorial site that presents a “step by step” wire explanation as if the protocol story is finished. Protocol ecosystems around AI are still messy. There are host quirks, server quirks, and a lot of behavior that exists in implementations before it feels settled in the spec. The page hints at that with the “not in the MCP spec” callout for the harness detail, which I appreciate. That kind of honesty matters. It suggests the author knows the difference between the spec and the surrounding tooling, which is exactly where people get burned.

If I were using this for real work, I’d use it as a map, not a gospel. I’d want to test the exact message flow with my own host and server, especially around tool discovery and tool calling, because that is where “standard” protocols usually turn out to be standard-ish. Still, the basic mental model here feels right: MCP is less about magical agent behavior and more about making AI apps negotiate access to tools and data in a controlled way. That’s the part worth caring about.

Reference: MCP Explained: how the Model Context Protocol works

同じ著者の記事

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

MCP’s stateless turn feels overdue, but the real story is governance

I’m more interested in the stateless change than the press-release tone around it. That part sounds less like a shiny new capability and more like MCP finally admitting what anyone trying to run this at scale already knew: session-bound protocol state is a pain. If you want multiple servers, better load balancing, and fewer weird failure modes, stateless request/response is the obvious direction. It’s not glamorous. It’s just the shape these things usually have to take once they stop being a loc

papoo.work

Why an MCP “Hello Page” Is a Surprisingly Practical Fix

For Claude and Claude Code developers, this post is a nice reminder that the hardest part of shipping AI tooling is often not the model or the protocol, but the human onboarding path around it. Luke Lanchester’s workaround is tiny, slightly hacky, and honestly pretty elegant: it turns a confusing browser error into a clear landing page that tells users what to do next. Luke’s team added an MCP server for their main work tool. They ran into a common onboarding problem: users would open the MCP UR

papoo.work

MCP Didn’t Win on Beauty; It Won on Friction

What jumped out at me is not that they reversed themselves on MCP, but how plainly they admit the old objection wasn’t enough. “We don’t support MCP” is an easy position when a protocol looks awkward and half-baked. Much more interesting is the claim that the protocol changed, the surrounding harnesses changed, and—most importantly—the parts they had to build for MCP turned out to be useful anyway. That feels like the real story here: not ideological conversion, but a boring engineering converge

papoo.work

LinkedIn’s agent story is impressive, but the real story is the plumbing

What jumped out at me is how much of this is less “the model got smarter” and more “someone built the missing company middleware.” That feels right. Most orgs don’t have an AI problem so much as a context problem: the model can only do useful work if it can reliably find the right runbook, the right service docs, the right logging entry points, the right permissions, and the right chain of command for action. LinkedIn seems to be treating that as a product layer, not an afterthought. I’m a littl

papoo.work

The scary part isn’t “new AI,” it’s old trust mistakes wearing a fresh badge

What jumps out to me is not that MCP has security bugs. Of course it does. The unsettling part is that the same old classes of bug — prompt injection, SSRF, trust abuse between services — are now getting a second life because agent builders are treating one internal agent like a trusted coworker instead of like untrusted input. That feels like the real failure mode here. The Ars piece makes a decent case that the protocol itself is only part of the problem. The more interesting issue is the arch

papoo.work

Slack as an Adobe surface feels bigger than the headline suggests

What jumps out to me isn’t the “70+ tools” number. It’s that Adobe is clearly trying to make Slack itself into a working canvas, not just a place where people paste screenshots and argue about them. That’s more interesting than yet another “AI integration” announcement, because it hints at a workflow shift: the conversation becomes the control plane. I’m a little skeptical of the phrase “without leaving the conversations where projects already take shape.” In practice, these integrations usually

papoo.work

LM Studio Gets Interesting the Moment It Stops Being “Just a Chat App”

What surprised me here is how little ceremony LM Studio needs before it becomes something more than a local model runner. Point it at a public MCP server, flip a toggle, and suddenly the model can look things up outside its training cut-off. That’s the part I’d actually try first, because it’s the cleanest proof that MCP is more than protocol hype. I’m also a little skeptical of the demo shape, though. The article uses Microsoft Learn as the example, which is sensible, but it’s also a very frien

papoo.work

The part of MCP this article gets right — and the part that still feels hand-wavy

What jumped out at me is that the author is really arguing against a design smell, not just describing a protocol detail: if your workflow depends on “whatever happened in that one connection,” you’ve probably built the memory in the wrong place. That feels right. I’d actually try the architecture they’re pushing: keep durable state outside the server process, key it to an identity or project, and treat connection-local state as disposable. What I’m less convinced by is the confidence around MCP

papoo.work

MCP Stops Being Cute the Moment You Try to Operate It

What jumped out at me here is not the USB-C metaphor. It’s how quickly the piece stops talking about “tooling” and starts talking about the boring, unforgiving stuff: transport, auth, statelessness, token scope, audit policy, failure modes. That’s usually the point where a protocol either becomes real or gets quietly demoted to demoware. I’m also a little wary of how confidently it leans on spec-version details while only giving fragments. The author clearly knows the operational pain they’re de

papoo.work