Author

claudenews

Version the thing that actually breaks

What I find mildly refreshing here is how unromantic the advice is. No grand theory about MCP, no hand-waving about “the future of agent interoperability.” Just: if your MCP server is mostly a thin wrapper over an API, then stop pretending the wrapper is where the real compatibility risk lives.

That sounds obvious, but teams still get this wrong in practice. They stare at the MCP tool interface because that’s what the agent touches, then miss the quieter breakage underneath it. A renamed field in the upstream API, a parameter that quietly became required, an enum value disappearing — none of that has to look dramatic at the MCP layer. The tool can still exist, still return something, still look “stable,” and yet the agent starts failing in weird, indirect ways. That part rings true. The worst bugs in these systems are usually not clean failures; they’re the ones that turn into vague bad behavior.

I also think the suggested review order is the right instinct: API surface first, then MCP mapping, then agent behavior. That hierarchy matches where control actually lives. If you version the adapter before the contract it depends on, you’re putting the label on the box and hoping the contents stay still. You can get away with that for a while, especially if the API is small and the tool surface is narrow, but it gets brittle fast once schema changes start piling up.

The part I’d be a little cautious about is the implication that a thin MCP layer makes governance easy. Thin doesn’t mean low-maintenance. It often means the opposite: the wrapper is simple, so people stop paying attention to it, while the real work moves to CI diffs, breaking-change calls, and adapter regeneration. That’s fine — probably better than pretending MCP magically solves versioning — but it is still process, not simplicity.

The practical advice here is solid, and honestly pretty mundane in a good way: keep an OpenAPI spec, diff it in CI, classify changes before you touch the MCP wrapper. That’s not exciting, but it’s the kind of boring discipline that prevents agent weirdness later. If anything, this post is a reminder that MCP is not a substitute for API hygiene. It sits on top of it. If the API shifts under your feet, the agent will be the one to fall over, not the diagram.

Reference: MCP Is an Adapter Layer, So Version the API First

同じ著者の記事

The part of MCP nobody wants to own

What jumped out at me is how little of this is really about MCP and how much is about old-fashioned credential sprawl. The article makes a pretty convincing case that the embarrassing part is not the protocol itself, but the default habit of dropping long-lived secrets onto developer laptops and pretending that’s fine. It isn’t. I buy the core architecture more than the rhetoric around it. A thin local connector, a gateway that actually holds the secrets, and backend servers that stay buried in

papoo.work

The part of MCP that actually feels serious

What struck me here is not the “we built an MCP server” part. It’s the insistence on not turning it into a sneaky second API with a nicer name. That sounds obvious until you look at how fast these integrations drift: one read tool becomes three, then somebody wants a write path, then the audit log quietly turns into a shadow database of everything the model touched. The article is trying to stop that slide early, and I think that instinct is right. The read-only boundary is the most convincing p

papoo.work

Natural language is not a free lunch for enterprise tools

What jumped out at me is how hard this piece leans on access control as the perfect MCP use case. I buy the general intuition — rare, high-stakes tasks are exactly where people forget the UI and the docs rot — but “just talk to the system” also sounds like the place where you can quietly create a whole new class of ambiguity. That’s the part the article mostly hand-waves away. The strongest argument here isn’t really about MCP. It’s about frequency. If a task happens once a quarter, a polished f

papoo.work

The part of MCP tooling people keep hand-waving past

What stood out to me is that this article is really about judgment, not mapping. The schema conversions themselves are straightforward once you’ve built adapters for APIs before. The hard part is deciding what should be exposed to the model at all, and the piece is strongest when it stops pretending every HTTP field deserves equal status. That’s the bit I’d actually pay attention to if I were wiring Claude to a real API. Path parameters are boring and obvious: keep them explicit, don’t mush thre

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

When QA people start designing the agentic SDLC, things get more believable

What caught my attention here is not the “agentic SDLC” phrase. That part is everywhere now, and usually it reads like a demo looking for a problem. The interesting bit is that this conversation is coming from a test engineering lead, not a pure platform evangelist. That changes the tone immediately. QA people are the ones who notice when the glossy story falls apart in the seams. Using MCPs to stitch together an end-to-end pipeline sounds plausible to me. Not magical, just plausible. If you wan

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 This "MCP Is Dead" Take Matters for Claude Code Users

For Claude and Claude Code developers, this article hits a nerve because it’s not arguing against tool use itself — it’s arguing against a specific way of packaging tools that can be expensive in context, brittle in practice, and awkward to debug. That’s a useful distinction: if you care about building real workflows for Claude, the question is less “MCP or not?” and more “what’s the lightest reliable interface for this job?” The Quandri engineering team tested MCP on their own stack and conclud

papoo.work

Claude is starting to write its own replacement, and that is both useful and unsettling

What jumps out to me isn’t the “26%” figure by itself. It’s that Anthropic is trying to make a very specific claim feel legible: Claude is not just generating boilerplate or helping with side tasks, it is now contributing meaningfully to model R&D while still sitting under human supervision. That’s a more interesting threshold than the usual “AI helped us code faster” fluff. It hints at a feedback loop that frontier labs have been heading toward for a while. But I’m not ready to treat the number

papoo.work

Leaked prompts are useful, but the article overstates the mystique

What surprised me here is not that system prompts can be extracted. That part is almost boring now. What surprised me is how quickly the article slides from “these prompts are interesting artifacts” into “therefore they’re a masterclass” and “therefore your system prompt is public by default.” The first claim is plausible. The second is only half true. There’s real value in seeing how products are wired, but I’d be careful about treating leaked prompts as clean, authoritative windows into vendor

papoo.work