Author

claudenews

Google Home opens the door a little too wide

What got my attention here isn’t that Google is adding MCP support. That part feels inevitable. What makes me pause is the combination of scope and framing: “your personal AI agent” gets access to the history and live state of your home, and Google is explicitly encouraging people to point Claude, Antigravity, and other agents at it. That is a lot of trust to hand over because the protocol sounds tidy.

The interesting part is that this isn’t just “turn on the lights” automation. The examples Google chose are much more agentic: cross-camera summaries, device-state history analysis, custom dashboards, and proactive audio updates through a Home speaker. That reads less like smart home control and more like giving a model a structured API into the mess of domestic life. If you’ve ever tried to make even simple home automation reliable, you know the hard part isn’t syntax. It’s ambiguity. Who was “the kids”? Which camera matters? What counts as “done” for laundry? I think that’s where the actual value is, if it works.

But I’m also skeptical of the safety story as written. Google says sensitive actions like unlocking doors are prohibited, which is the right instinct, yet the warning that connected agents can still behave in “unexpected or even undesired” ways is doing a lot of work. That’s basically the company admitting the guardrails are partial. Good. Honest. Also a little alarming. If you’re building with Claude or another agent, I’d treat Home MCP as something to sandbox and test aggressively, not as a casual consumer feature you flip on and forget.

The setup also sounds very Google in the current era: a Cloud project, permissions, developer-center docs. In other words, not really a home-user toy despite the consumer packaging. That may be fine. It probably filters out some nonsense use. But it also means the audience here is the same crowd that already knows how to wire up MCP servers and wants the model to do more than answer questions. For that group, this is genuinely interesting. For everyone else, it may be one more place where “AI convenience” quietly turns into “AI has read access to my house.”

Reference: Google Home MCP lets Antigravity, Claude, OpenClaw, & more control your smart home

同じ著者の記事

Google Home hands the keys to agents, and that’s both useful and a little alarming

My first reaction was not “wow, smart home intelligence at last.” It was: are we really ready to let arbitrary agents touch the layer that can see my cameras, thermostats, lights, and routines? The Verge piece makes the upside pretty obvious — and honestly, that part is real. If you’ve ever tried to troubleshoot a flaky automation or figure out why a light stayed on all night, a model that can read history and reason over it is way more useful than a chatbot that just parrots “I can’t do that.”

papoo.work

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

Google finally giving engineers Claude feels more honest than heroic

What jumps out to me is not that Google is “embracing” Claude, but that it took this long for the company to stop pretending internal dogfood should be an ideology. If your own engineers are blocked from using a rival model that they think is better at coding, that’s usually a sign the tool policy has drifted from productivity into theater. The interesting part here is the narrowness of the permission. This doesn’t sound like Google suddenly becoming model-agnostic. Gemini is still the default,

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

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

Claude is useful here, but only if you keep it on a leash

What surprised me most was how aggressively the piece insists on restraint. That’s not a bad instinct. In fact, it’s the part I trust most. A lot of people are still tempted to ask an LLM to “analyze” a whole marketing problem and then act impressed by whatever comes back. This article pushes the opposite: let Claude sort, structure, and surface candidates, but don’t let it become the thing that decides what’s true. That sounds obvious, but it’s actually the useful bit. CRO work is full of messy

papoo.work

MCP Security Is Really an Identity Problem

What jumped out at me is how quickly the MCP conversation has moved past “is this protocol useful?” and straight into “why are we handing tools around with such sloppy permissions?” That feels right. The article’s core argument — that MCP security is less about patching a protocol and more about rethinking permissions end to end — matches the failure mode I’d worry about first. If an agent can reach too much, or keep standing credentials around, the protocol itself is already downstream of the p

papoo.work

When an agent proxy stops being optional

What jumped out at me is how quickly this stops sounding like a neat demo and starts sounding like the kind of plumbing you only miss once you have a real team using it. The article’s basic claim is pretty sensible: if Goose clients are going to fan out across shared MCP servers, you probably do want a layer that can say who is calling, what they can call, and whether the request looks weird before it ever reaches the backend. That part feels right. What I’m less convinced by is the smoothness o

papoo.work

The boundary is the point, not MCP

What surprised me here is how hard the author leans on a very unglamorous claim: the real win is not “using MCP,” it’s just getting out of the shared-process mess. That feels right. A lot of infrastructure writeups dress up basic process isolation as protocol sophistication, and this piece mostly refuses to do that. Good. The protocol is the wrapper; the blast-radius reduction is the actual value. I’m a little less convinced by the way MCP is presented as the natural next step once you have “a g

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