I hope they also improve their JSONSchema support for structured output and tool calling. Currently it has many limitations compared to OpenAI’s, for example it doesn’t support “additionalProperties” which eliminates an entire class of use cases and makes it immediately incompatible with many MCP servers.
Marketing the API as OpenAI-compatible and then me getting 400s when I switch to Gemini leaves a sour taste in the mouth, and doesn’t make me confident about their MCP support.
Given their anti-trust struggles, if Google for some reason dominates AI, they'd not want people to bring up anti-competitive behavior as a reason for that. Adopting open standards, especially open standards conceived outside Google is good for everyone including Google. They're well placed - from research to hardware to software and data.
They'll also want the industry to rapidly move forward and connect data to AI. MCP has momemtum.
To escape the anti-trust struggles, they'll need to provide MCP servers (meaning provide callable tools). Stopping at providing MCP client (the chatbot that connects to MCP servers) isn't enough.
I'll believe in Google not actively being anti-competitive when I (a paying customer) can access/modify my gmail, google contacts, google sheets, plan routes in google maps, ... from my local llm chatbot using mcp.
Containers are usually considered pretty weak security at best. Especially since you don’t always control what the user does with it (docker va rootless podman etc)
It doesn't really matter what it is as there are many equally good implementations, but whoever sets up the framework first and cements usage is likely to guarantee dominance for the foreseeable future. Probably into AGI and post.
I agree the idea seems much better - and I think it's what a lot of big-shops are doing internally too. An earlier article [1] showed that internally, gemini has a python sandbox it uses to call other google services.
I'm guessing the main limitation is that it's harder to orchestrate, especially on clients.
Looks similar to most other mid-level remote procedure call protocols, from XMLRPC to CORBA.
The usual sync, async, poll, progress test problems apply.
Things I'd expected to see and didn't:
- Client to server: "tell me what you can do". This has always been hard, but in the LLM era, it could potentially work, because a textural response would work.
- Similarly, being able to ask "How do I..." might be feasible now. It should be possible to talk to a new server and automatically figure out how to use it.
- "How much is this going to cost me?" Plus some way to set a cost limit on a query.
cost isn't part of MCP in the same way that cost isn't part of HTTP. It wouldn't really make sense to include that in the protocol, just put it in the application layer on top.
It's a little different. These are systems which are explicitly able to achieve better or worse outcomes by tuning the cost, in ways that aren't especially configurable otherwise. For an HTTP API, you can read the docs and use the small image vs large image endpoint or whatever and have a clear idea of what you're getting and for what cost. For LLMs, it would be very nice to be able to communicate about the desired and actual cost breakdowns for each sub-action.
honestly, it looks like an unnecessary additional protocol to a REST API. Couldn't you just add a "LLM-description" (optional) field to any RESTAPI that provides a JSON description of how to use it? That's what it sounds like because every LLM already will have it's own "idea" of how to use a MCP interface. So why have a totally disparate thing.
I think we can assume even if it is any voting power, it’s far less than 14%. No startup growing like that would give up shares with the same voting rights as the founders
Phase one is adopting it (you are here). Phase two is somehow turning it into a Web standard deeply integrated with Chrome which they have no real competition from and takes billions of dollars just to stay apace with.
Not sure about Extinguish to be honest, Google just wants the monopoly and they already have it.
Every time I see MCP I think of the Unisys mainframe OS.
It runs on x86 processors (under emulation), so it'd make some sense if Google offered it as an option in Google Cloud. Maybe they could offer OS2000, GCOS, and GECOS as well.
They have a chance to come-up with a user-friendly framework on top of MCP and make a big difference in acceleration of adoption. Cherry on the cake would be if they can build a UI on top of it to build/monitor/visualize. Hosted by them with a generous free-tier i.e. more private data to munch on for ads (only half joking).
it's wild to me how rapidly this has exploded in popularity. there's even a twitter account/site dedicated to news updates - https://x.com/getMCPilled and mcpilled.com
56 comments
[ 2.6 ms ] story [ 141 ms ] threadMarketing the API as OpenAI-compatible and then me getting 400s when I switch to Gemini leaves a sour taste in the mouth, and doesn’t make me confident about their MCP support.
They'll also want the industry to rapidly move forward and connect data to AI. MCP has momemtum.
I'll believe in Google not actively being anti-competitive when I (a paying customer) can access/modify my gmail, google contacts, google sheets, plan routes in google maps, ... from my local llm chatbot using mcp.
[1] https://blog.sshh.io/p/everything-wrong-with-mcp
Just wrap it in an SSH tunnel or a HTTPS websocket
> MCP servers can run (malicious code) locally.
Just run it in a Docker container
You should probably read the original article in the footnotes of OP's article: https://equixly.com/blog/2025/03/29/mcp-server-new-security-...
While a container will surely protect you from those, it will also prevent you using the features implemented by those MCP Servers.
> Just wrap it in an SSH tunnel or a HTTPS websocket
I assume this is sarcasm, but if not (and for people that take it at face value), it fundamentally misunderstands what auth is used for.
Tools often need access to data sources but I don't want to hard code passwords.
https://news.ycombinator.com/item?id=43631381
"The Agent2Agent Protocol (A2A)", 279 comments
Model Context Protocol seems good enough to me.
I'm guessing the main limitation is that it's harder to orchestrate, especially on clients.
1. https://news.ycombinator.com/item?id=43508418
Smells like a new project in Killed By Google graveyard.
We're observing a response to takes that A2A meant they weren't going to support MCP.
Everyone's got a take and a response these days, it's a nice little infinite loop of complaints and that keeps PR kicking.
- Client to server: "tell me what you can do". This has always been hard, but in the LLM era, it could potentially work, because a textural response would work.
- Similarly, being able to ask "How do I..." might be feasible now. It should be possible to talk to a new server and automatically figure out how to use it.
- "How much is this going to cost me?" Plus some way to set a cost limit on a query.
Just seems like i+1 syndrome with computing.
It's also "Model Context Protocol", a protocol for LLMs to interact with third-party services.
Phase one is adopting it (you are here). Phase two is somehow turning it into a Web standard deeply integrated with Chrome which they have no real competition from and takes billions of dollars just to stay apace with.
Not sure about Extinguish to be honest, Google just wants the monopoly and they already have it.
It runs on x86 processors (under emulation), so it'd make some sense if Google offered it as an option in Google Cloud. Maybe they could offer OS2000, GCOS, and GECOS as well.
It's so clearly a dead-end. It gives freethinking developers and innovators time to focus on the next generation of software.