5 ms·

Google is so far behind agentic cli coding. Gemini CLI is awful. So bad in fact that it’s clear none of their team use it. Also MCP is very obviously dead, as a

Google is so far behind agentic cli coding. Gemini CLI is awful. So bad in fact that it’s clear none of their team use it. Also MCP is very obviously dead, as any of us doing heavy agentic coding know. Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in. Playwright with headless Chromium or headed chrome is what anyone serious is using and we get all the dev and inspection tools already. And it works perfectly. This only has appeal to those starting out and confused into thinking this is the way. The answer is almost never MCP.

synalx 7mo ago
Antigravity's coding agent is worlds apart from Gemini CLI, though.
girvo 7mo ago
I know it’s a bit of a tangent but man you’re right re. Gemini CLI. It’s woefully bad, barely works. Maybe because I was a “free” user trying it out at the time, but it was such a bad experience it turned me off subscribing to whatever their coding plan is called today.
- luckydata 7mo ago
  it's not the CLI, it's the model. The model wasn't trained to do that kind of work, was trained to do one shot coding, not sustained back and forth until it gets it right like Claude and ChatGPT.
- ElCapitanMarkla 7mo ago
  I had this exp too, but I trialed the pro sub a few weeks back and it has been great. I have no complaints this time
rsalus 7mo ago
MCP is very much not dead. centralized remote MCP servers are incredibly useful. also bespoke CLIs still require guidance for models to use effectively, so it's clear that token efficiency is still an issue regardless.
- nojito 7mo ago
  all you need is a simple skills.md and maybe a couple examples and codex picks up my custom toolkit and uses it.
  - dominotw 7mo ago
    whats your custom toolkit
    - nojito 7mo ago
      I have dozens of clis that are custom built for codex to use.
- abhis3798 7mo ago
  I see remote MCP servers as a great interface to consume api responses. The idea that you essentially make your apis easily available to agents to bring in relevant context is a powerful one. When folks say MCP is dead, I don't get it. What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint?
  - attentive 7mo ago
    > What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint? cli? for example aws cli. It's a full interface to aws API. Why would you need mcp for that? and if you have any doubts, agents use it with a great effect even without any relevant skill. "aws help" is fully discoverable.
    - rsalus 7mo ago
      yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. in a sense, this is the same sort of context tax that MCP servers incur. so in my view cli and MCP are complementary tools; one is not strictly superior over the other.
spiderfarmer 7mo ago
MCP is not just used for coding.
cheema33 7mo ago
> Also MCP is very obviously dead Some people will push back on this. They are holding out hope that the recent improvements Anthropic has made in this regard have improved the context rot problem with MCP. Anthropic's changes improve things a little. But it is akin to putting lipstick on a pig. It helps, but not much. The reason MCP is dying/dead is because MCP servers, once configured, bloat up context even when they are not being used. Why would anybody want that? Use agent skills. And say goodbye to MCP. We need to move on from MCP.
- dominotw 7mo ago
  i am using notion mcp. is there a corresponding skill. also wtf is a plugin.
- Rapzid 7mo ago
  The bloat problem is already out dated though. People are having the LLM pick the MCP servers it needs for a particular task up front, or picking them out-of-band, so the full list doesn't exist in the context every call.
- ktoo_ 7mo ago
  > it is akin to putting lipstick on a pig. It helps, but not much. The lipstick helps? This had me in stitches. Sorry for the non-additive reply. This is the funniest way I have seen this or any other phrase explained. By far. Honestly has made my day and set me up for the whole week.
- maxwellg 7mo ago
  Is your agent harness dropping the entire MCP server tool description output directly into the context window? Is your agent harness always addig MCP servers to the context even when they are not being used? MCP is a wire format protocol between clients and servers. What ends up inside the context window is the agent builder's decision.
- staticassertion 7mo ago
  I'm a layman here. How is a skill any better? Aren't agent tools loaded on-demand, just as a skill would be? People are mentioning OpenAPI, but wouldn't you need to load the spec for that too?
sega_sai 7mo ago
I don't know if this just anecdotal random impression, but in a last week or two I had mostly good experience with Google cli. While previously I constantly complained about it. I have been using it together with codex, and I would not say that one is much better than another. It is hard to say nowadays, when things change so quickly
zeroxfe 7mo ago
> Also MCP is very obviously dead, as any of us doing heavy agentic coding know. As someone that does heavy agentic coding (using basically all the tools), this is so far from the truth. People claiming this have probably never worked in large enterprise environments where things like authentication, RBAC, rate limiting, abuse detection, centralized management/updates/ops, etc. are a huge part of the development and deployment workflow. In these situations you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity. MCP is really useful here, and allows centralized eng and ops teams to manage their services in a way that aligns with the organizations overall posture, policies, and infrastructure. > Google is so far behind agentic cli coding. Gemini CLI is awful. This part I totally agree. It's really hard to express how bad it is (and it's really disappointing.)
- moritonal 7mo ago
  Given MCP is supposed to just be a standardised format for self-describing APIs, why are all the features you listed MCP related things? It sounds more like it's forced the enterprise to build such features which cli tooling didn't have?
  - rsalus 7mo ago
    mostly by virtue of being a common standard. MCP servers are primarily useful in a remote environment, where centralized management of cross-cutting concerns matters. also its really useful for integrating existing distributed services, e.g., internal data lakes. I think it's clear a self-describing CLI is optimal for local-first tooling and portability. I personally view remote MCP servers as complementary in the space.
  - tomnipotent 7mo ago
    MCP's can hide most things behind an API.
- bloppe 7mo ago
  > you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity You're describing MCP. After all, MCP is just reinventing the OpenAPI wheel. You can just have a self-documenting REST API using OpenAPI. Put the spec in your context and your model knows how to use it. You can have all the RBAC and rate limiting and auth you want. Heck, you could even build all that complexity into a CLI tool if you want. MCP the protocol doesn't actually enable anything. And implementing an MCP server is exactly as complex as using any other established protocol if you're using all those features anyway
quotemstr 7mo ago
> Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in What about all the CLI tools not baked into the model's priors? Every time someone says "extensibility mechanism X is dead!", I think "Well, I guess that guy isn't doing anything that needs to extend the statistical average of 2010s-era Reddit"
danpalmer 7mo ago
> So bad in fact that it’s clear none of their team use it. I use it extensively, many of my colleagues do. I get a ton of value out of it. Some prefer Antigravity, but I prefer Gemini CLI. I get fairly long trajectories out of it, and some of my colleagues are getting day-long trajectories out of it. It has improved massively since I started using it when it first came out.
IX-103 7mo ago
FYI: Gemini Cli is used internally at Google. It's actually more popular than Antigravity. Google uses MCP services internally for code search (since everything is in a mono-repo you don't want to waste time grepping billions of files), accessing docs and bugs, and also accessing project specific RAG databases for expertise grounding. Source - I know people at Google.
- deleted 7mo ago
  [deleted]
- mmaunder 7mo ago
  Have you tried it? It's like working with an idiot savant. It's absolutely brilliant, but goes off the rails constantly, spewing out CoT when it shouldn't be, getting into weird loops, spewing gibberish or repeated phrases. But when it does actually work, it's brilliant. But the issues make it unusable for dev at any level - and completely untrustworthy. Contrasted with CC or Codex CLI it's night and day. The latter two are incredibly reliable, rock solid, and crazy productive, and becoming exponentially more so by the week.
edwinjm 7mo ago
MCP is dead? Which cli tool should we use to instruct Chrome to open a page and click the Open button? And to read what appears in the console after clicking? MCP permanently sacrifice a chunk of the context window? And a skill for you cli is free?
deleted 7mo ago
[deleted]
hu3 7mo ago
> Also MCP is very obviously dead... Couldn't have been more wrong. MCP despite its manageable downsides is leagues ahead of anything else in many ways. The fact that SoTA models are trained to handle MCP should be hint enough to the observant. I probably build one MCP tool per week at work. And every project I work on gets its own MCP tool too. It's invaluable to have specialized per-project tooling instead of a bunch of heterogeneous scripts+glue+prayer. Anything specialized goes into an MCP.
deleted 7mo ago
[deleted]
hugs 7mo ago
some serious people use vibium instead. (full-disclosure: "some serious people" is me.)
sunaookami 7mo ago
Gemini 3.1 Pro through Gemini CLI always tries to write files with cat instead of using the write_file tool, it's awful at tool use.

synalx 7mo ago

Antigravity's coding agent is worlds apart from Gemini CLI, though.

girvo 7mo ago

I know it’s a bit of a tangent but man you’re right re. Gemini CLI. It’s woefully bad, barely works. Maybe because I was a “free” user trying it out at the time, but it was such a bad experience it turned me off subscribing to whatever their coding plan is called today.

luckydata 7mo ago
it's not the CLI, it's the model. The model wasn't trained to do that kind of work, was trained to do one shot coding, not sustained back and forth until it gets it right like Claude and ChatGPT.
ElCapitanMarkla 7mo ago
I had this exp too, but I trialed the pro sub a few weeks back and it has been great. I have no complaints this time

rsalus 7mo ago

MCP is very much not dead. centralized remote MCP servers are incredibly useful. also bespoke CLIs still require guidance for models to use effectively, so it's clear that token efficiency is still an issue regardless.

nojito 7mo ago
all you need is a simple skills.md and maybe a couple examples and codex picks up my custom toolkit and uses it.
- dominotw 7mo ago
  whats your custom toolkit
  - nojito 7mo ago
    I have dozens of clis that are custom built for codex to use.
abhis3798 7mo ago
I see remote MCP servers as a great interface to consume api responses. The idea that you essentially make your apis easily available to agents to bring in relevant context is a powerful one. When folks say MCP is dead, I don't get it. What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint?
- attentive 7mo ago
  > What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint? cli? for example aws cli. It's a full interface to aws API. Why would you need mcp for that? and if you have any doubts, agents use it with a great effect even without any relevant skill. "aws help" is fully discoverable.
  - rsalus 7mo ago
    yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. in a sense, this is the same sort of context tax that MCP servers incur. so in my view cli and MCP are complementary tools; one is not strictly superior over the other.

spiderfarmer 7mo ago

MCP is not just used for coding.

cheema33 7mo ago

> Also MCP is very obviously dead Some people will push back on this. They are holding out hope that the recent improvements Anthropic has made in this regard have improved the context rot problem with MCP. Anthropic's changes improve things a little. But it is akin to putting lipstick on a pig. It helps, but not much. The reason MCP is dying/dead is because MCP servers, once configured, bloat up context even when they are not being used. Why would anybody want that? Use agent skills. And say goodbye to MCP. We need to move on from MCP.

dominotw 7mo ago
i am using notion mcp. is there a corresponding skill. also wtf is a plugin.
Rapzid 7mo ago
The bloat problem is already out dated though. People are having the LLM pick the MCP servers it needs for a particular task up front, or picking them out-of-band, so the full list doesn't exist in the context every call.
ktoo_ 7mo ago
> it is akin to putting lipstick on a pig. It helps, but not much. The lipstick helps? This had me in stitches. Sorry for the non-additive reply. This is the funniest way I have seen this or any other phrase explained. By far. Honestly has made my day and set me up for the whole week.
maxwellg 7mo ago
Is your agent harness dropping the entire MCP server tool description output directly into the context window? Is your agent harness always addig MCP servers to the context even when they are not being used? MCP is a wire format protocol between clients and servers. What ends up inside the context window is the agent builder's decision.
staticassertion 7mo ago
I'm a layman here. How is a skill any better? Aren't agent tools loaded on-demand, just as a skill would be? People are mentioning OpenAPI, but wouldn't you need to load the spec for that too?

sega_sai 7mo ago

I don't know if this just anecdotal random impression, but in a last week or two I had mostly good experience with Google cli. While previously I constantly complained about it. I have been using it together with codex, and I would not say that one is much better than another. It is hard to say nowadays, when things change so quickly

zeroxfe 7mo ago

> Also MCP is very obviously dead, as any of us doing heavy agentic coding know. As someone that does heavy agentic coding (using basically all the tools), this is so far from the truth. People claiming this have probably never worked in large enterprise environments where things like authentication, RBAC, rate limiting, abuse detection, centralized management/updates/ops, etc. are a huge part of the development and deployment workflow. In these situations you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity. MCP is really useful here, and allows centralized eng and ops teams to manage their services in a way that aligns with the organizations overall posture, policies, and infrastructure. > Google is so far behind agentic cli coding. Gemini CLI is awful. This part I totally agree. It's really hard to express how bad it is (and it's really disappointing.)

moritonal 7mo ago
Given MCP is supposed to just be a standardised format for self-describing APIs, why are all the features you listed MCP related things? It sounds more like it's forced the enterprise to build such features which cli tooling didn't have?
- rsalus 7mo ago
  mostly by virtue of being a common standard. MCP servers are primarily useful in a remote environment, where centralized management of cross-cutting concerns matters. also its really useful for integrating existing distributed services, e.g., internal data lakes. I think it's clear a self-describing CLI is optimal for local-first tooling and portability. I personally view remote MCP servers as complementary in the space.
- tomnipotent 7mo ago
  MCP's can hide most things behind an API.
bloppe 7mo ago
> you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity You're describing MCP. After all, MCP is just reinventing the OpenAPI wheel. You can just have a self-documenting REST API using OpenAPI. Put the spec in your context and your model knows how to use it. You can have all the RBAC and rate limiting and auth you want. Heck, you could even build all that complexity into a CLI tool if you want. MCP the protocol doesn't actually enable anything. And implementing an MCP server is exactly as complex as using any other established protocol if you're using all those features anyway

quotemstr 7mo ago

> Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in What about all the CLI tools not baked into the model's priors? Every time someone says "extensibility mechanism X is dead!", I think "Well, I guess that guy isn't doing anything that needs to extend the statistical average of 2010s-era Reddit"

danpalmer 7mo ago

> So bad in fact that it’s clear none of their team use it. I use it extensively, many of my colleagues do. I get a ton of value out of it. Some prefer Antigravity, but I prefer Gemini CLI. I get fairly long trajectories out of it, and some of my colleagues are getting day-long trajectories out of it. It has improved massively since I started using it when it first came out.

IX-103 7mo ago

FYI: Gemini Cli is used internally at Google. It's actually more popular than Antigravity. Google uses MCP services internally for code search (since everything is in a mono-repo you don't want to waste time grepping billions of files), accessing docs and bugs, and also accessing project specific RAG databases for expertise grounding. Source - I know people at Google.

deleted 7mo ago
[deleted]
mmaunder 7mo ago
Have you tried it? It's like working with an idiot savant. It's absolutely brilliant, but goes off the rails constantly, spewing out CoT when it shouldn't be, getting into weird loops, spewing gibberish or repeated phrases. But when it does actually work, it's brilliant. But the issues make it unusable for dev at any level - and completely untrustworthy. Contrasted with CC or Codex CLI it's night and day. The latter two are incredibly reliable, rock solid, and crazy productive, and becoming exponentially more so by the week.

edwinjm 7mo ago

MCP is dead? Which cli tool should we use to instruct Chrome to open a page and click the Open button? And to read what appears in the console after clicking? MCP permanently sacrifice a chunk of the context window? And a skill for you cli is free?

deleted 7mo ago

[deleted]

hu3 7mo ago

> Also MCP is very obviously dead... Couldn't have been more wrong. MCP despite its manageable downsides is leagues ahead of anything else in many ways. The fact that SoTA models are trained to handle MCP should be hint enough to the observant. I probably build one MCP tool per week at work. And every project I work on gets its own MCP tool too. It's invaluable to have specialized per-project tooling instead of a bunch of heterogeneous scripts+glue+prayer. Anything specialized goes into an MCP.

deleted 7mo ago

[deleted]

hugs 7mo ago

some serious people use vibium instead. (full-disclosure: "some serious people" is me.)

sunaookami 7mo ago

Gemini 3.1 Pro through Gemini CLI always tries to write files with cat instead of using the write_file tool, it's awful at tool use.