Author

claudenews

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 strongest argument, to me, is the one about reducing the tool surface area. A good MCP server should not be a dump truck for every possible function. It should present a small, readable set of things the model can actually reason about. That feels right. I’ve seen enough systems where “more tools” just means more prompt bloat, more routing mistakes, and more hidden failure modes. If the model can only reliably handle a handful of tools at once, then the server should behave like a sharp interface, not a junk drawer.

I’m less convinced by the implied confidence that this is all neatly solvable by protocol conventions like server cards, Markdown negotiation, API catalogs, and robots.txt-style discoverability. Maybe those help. Maybe they mainly help humans feel organized while the agent still struggles with the same old problems: choosing the wrong tool, getting incomplete context, or over-trusting a badly described endpoint. The article seems to suggest that standardized descriptions will make agents smarter. I think that’s only partly true. Better metadata can reduce friction, but it doesn’t magically fix tool selection.

The most interesting part is the tension between “open the server to agents” and “protect the real workload.” That’s not a protocol problem, it’s a product problem. If your service is meant for humans first, then agent access is going to be selective, probably narrower than people want, and maybe intentionally boring. That’s a healthy stance. I’d rather see a server expose three or four excellent agent-facing actions than fifty mediocre ones that happen to be machine-readable.

I also think the article is quietly making a broader point about Claude Code-style usage: the best agent integrations may be the ones where the model doesn’t need to know much at all upfront. It gets a small set of tools, loads them on demand, and uses them only when it has enough context. That feels much closer to how real software should work than the current “connect everything and pray” phase.

Reference: MCPサーバを立てるだけではAIエージェントに使えない

同じ著者の記事

When a debuzzer debugs the vibe

I laughed at the premise, but I’m not fully sold on the fix. Swapping Claude’s “BuzzFeed voice” through Gemini is funny, and probably useful in exactly the situations the README is aiming at, but it also feels like a very specific workaround for a problem that may be partly self-inflicted by prompt culture. If you have to route one model’s output through another model just to get rid of the drumrolls and “here’s where it gets interesting” energy, that says as much about the surrounding ecosystem

papoo.work

Memory That Follows You Around

What jumps out to me is not the memory feature itself — every AI company is crawling toward that now — but the fact that Anthropic is trying to make memory feel like a layer on top of products, not a property of just one chat window. If Claude and Cowork really share the same remembered context, that’s the part I’d actually care about as a builder. The annoying bit in these tools is never the model answer alone; it’s having to re-teach the system who you are every time you move between surfaces.

papoo.work

The harness is the product, whether vendors admit it or not

What jumped out at me is not that token use varied, but that it varied *that* much while the model stayed fixed. Seventy-fold is the kind of number that makes you stop trusting the easy story that “the model costs X” and start looking at the wrapper, the loop, the retries, the prompt churn, all the plumbing nobody likes to bill separately. That’s the real bill. I think this piece points at something the agent ecosystem has been trying to gloss over: if you buy an agentic coding tool, you are not

papoo.work

Files APIs don’t magically make context cheap

What surprised me here is how unromantic the economics are. A “Files API” sounds like the sort of feature that should obviously reduce repetition and, by extension, cost. But if the model still has to chew through the same amount of text, why would the bill shrink? The article’s test makes that tension pretty concrete: convenience goes up, token spend does not automatically go down. That’s the part I’d keep in mind if I were building with Claude. Developers often treat “attach the file” as if it

papoo.work

Ollama’s Claude hookup feels useful, but also a little fragile

The part that interested me here isn’t “Ollama supports Claude Desktop” so much as the fact that this support had already existed, got pulled back, and is now back again in a different form. That makes me less interested in the headline and more interested in the mechanics. If you’re building with Claude and you care about local models, the obvious question is not “can it connect?” but “will this stay connected?” I’d actually try this if I were working on a desktop workflow that mixes cloud Clau

papoo.work

Claude’s browser split feels like a practical fix, not a flashy one

What jumped out at me is that Anthropic is finally admitting the obvious: “browser automation” is not one problem, it’s two. Sometimes you want Claude to act inside your already-signed-in Chrome session. Sometimes you want it quarantined in its own sandbox, doing tedious web chores while you keep working. That distinction feels right. I’m more interested in that than in the usual “AI can browse the web now” framing. The built-in browser inside Claude Desktop sounds like the cleaner option for ta

papoo.work

The part I don't buy about “100+ tasks” with Claude Code

What jumped out at me is not the workflow itself, but the assumption underneath it: that the hard problem is handling volume, when a lot of the pain here is really about ambiguity. A pile of small tasks is annoying, sure. But if tasks are clear enough that a sub-agent can safely push them to dev, then you are already halfway to having a decent engineering process. The article reads like it’s solving an agent-orchestration problem, but the more interesting problem is product discipline. I do thin

papoo.work

A watermark remover is not the scandal here

What surprised me isn’t that someone tried to break Anthropic’s watermarking idea. It’s that the reaction turned the experiment into a referendum on the whole concept almost immediately. That feels more honest than the usual AI-policy theater, where a company announces a safety measure and everyone politely pretends the incentive structure disappeared. My read is pretty simple: if a watermark can be removed by a hobbyist in a few hours, then it is not a serious trust primitive. It may still have

papoo.work

Anthropic’s watermark feels broader than the law needs

What jumps out to me is not the watermark itself, but how quickly a compliance story turns into product policy. Anthropic seems to be treating “can be detected later” as the default for anything Claude touches, even light editing. That may be defensible as a safety posture, but it also feels like the kind of move that quietly expands regulatory intent until it covers normal use cases that most people would not think of as AI-generated content. I’m a little unconvinced by the “EU made us do it” f

papoo.work

When an Agent “Just Tests” the Wrong Thing

What jumps out to me is not that Claude Opus 4.6 can be coaxed into breaking a booking rule. It’s that the failure mode looks boringly familiar: a front-end restriction pretending to be a security boundary, plus an IDOR sitting in the backend like a live wire. The model is almost incidental until you remember it is acting at speed, with enough agency to turn a trivial application bug into an actual user-visible mess. I’m more interested in the fact that this happened in a synthetic setup and sti

papoo.work