Why do people have to make this stuff so complicated? An API that requires a key and enabling an MCP server and configuring your client to fetch markdown files on the fly? There's documentation on how to set things up to be able to get the documentation? Why not just a tar with all the docs? How big are they? A couple MB? Agents are really good at using grep on text files. So is my text editor.
Want it to be easy to update? Make it a git repo with all the docs. My agent already knows to always do a git fetch before interacting with a repo in a new session. Or you can fetch on a timer. Whatever.
I haven't yet figured out the point of this MCP stuff. Codex seems to have innate knowledge of how to curl jira and confluence and gitlab and prometheus and SQL databases and more. All you need to configure is a .netrc file and put the hostname in AGENTS.md. Are MCP tools even composable? Like can the model pipe the response to grep or jq or another MCP call without it entering/wasting context? Or is a normal CRUD API strictly more powerful and easier to use?
> Why do people have to make this stuff so complicated? An API that requires a key
If it didn't require a key, it would be marginally harder to track usage...
I can't help but feel that "read-only public knowledge Markdown-files MCP" should really just be a webpage. Authentication should be optional by default, for things like company IP. But maybe I'm missing the point too?
Sure, but Google isn't maintaining two sets of documentation here, the MCP server is just a thin wrapper around the webpage with a little search tool. So it's still the docs for humans just with a different delivery mechanism. Which is fine, but you can understand when hypertext exists largely for this exact purpose folks would find it odd and over complicated to reinvent the web over jsonrpc for robots.
The point of MCP is discoverability. A crud app is better, except you have to waste context telling your LLM a bunch of details. With MCP you only put into it's context what the circumstances are where it applies, and it can just invoke it. You could write a bunch of little wrapper scripts around each api you want to use and have basically reinvented MCP for yourself.
But this is entirely besides the point. The point of MCP is bundling those exact things into a standardized plugin that’s easy for people to share with others.
MCP is useful because I can add one in a single click for an external service (say, my CI provider). And it gives the provider some control over how the agent accesses resources (for example, more efficient/compressed, agent-oriented log retrieval vs the full log dump a human wants). And it can set up the auth token when you install it.
So yeah, the agent could write some those queries manually (might need me to point it to the docs), and I could write helpers… or I could just one-click install the plugin and be done with it.
I don’t get why people get worked up over MCP, it’s just a (perhaps temporary) tool to help us get more context into agents in a more standard way than everyone writing a million different markdown files and helper scripts.
"The point of MCP is bundling those exact things into a standardized plugin that’s easy for people to share with others." Like... a CLI/API?
"MCP is useful because I can add one in a single click for an external service" Like... a CLI/API? [edit: sorry, not click, single 'uv' or 'brew' command]
"So yeah, the agent could write some those queries manually" Or, you could have a high-level CLI/API instead of a raw one?
"I don’t get why people get worked up over MCP" Because we tried them and got burned?
"to help us get more context into agents in a more standard way than everyone writing a million different markdown files and helper scripts." Agreed it's slightly annoying to add 'make sure to use this CLI/API for this purpose' in AGENTS.md but really not much. It's not a million markdown files tho. I think you're missing some existing pattern here.
Again, I fail to see how most MCPs are not lazy tools that could be well-scoped discoverable safe-to-use CLI/APIs.
That's literally what they are. It's a dead simple self describing JSONRPC API that you can understand if you spend 5 seconds looking at it. I don't get why people get so worked up over it as if it's some big over-engineered spec.
I can run an MPC on my local machine and connect it to an LLM FE in a browser.
I can use the GitHub MCP without installing anything on my machine at all.
I can run agents as root in a VM and give them access to things via an MCP running outside of the VM without giving them access to secrets.
It's an objectively better solution than just giving it CLIs.
All true except that CLI tools are composable and don't pollute your context when run via a script. The missing link for MCP would be a CLI utility to invoke it.
How does the agent know what clis/tools it has available? If there's an `mcpcli --help` that dumps the tool calls, we've just moved the problem.
The composition argument is compelling though. Instead of clis though, what if the agent could write code where the tools are made available as functions?
>Like... a CLI/API? [...] , I fail to see how most MCPs are not lazy tools that could be well-scoped discoverable safe-to-use CLI/APIs.
The "discoverable" action itself is specified in the MCP standard. The "well-scoped" is accomplished by creating a whitelist of tool resources in the MCP manifest.
In contrast, a general-purpose CLI/API that wasn't specialized for AI usage is more open-ended and less standardized than the explicit MCP protocol.
Yes, existing Claude can already use existing CLI/API tools without any MCP server but that doesn't make MCP redundant. (But I'm not saying this thread's article about fetching the latest Google Android docs needs an MCP server.)
E.g. you mentioned CLI already has discoverability e.g. "clitool --help". That's somewhat true but it's still not as standardized as the MCP specification for discovering available resources and actions. The problem is the CLI implementation for displaying syntax and help could be spelled differently such as "clitool -help" (1 hyphen not 2) or "clitool -h" or "/help" or "/?". Some CLI tools also have extra detailed help that requires a modifier such as "clitool -help all". Or the critical CLI usage to solve a random AI user prompt is actually described in the "README.MD". The text output from the CLI's help option is not standardized. The point is none of that is standardized among all developers of various CLI tools.
(Random note.. last week, my ffmpeg build with the AV1 codec broke because I upgraded from NASM 2.x to NASM 3.x. The Google's libaomav1 build script[0] did an interesting hack by calling "nasm.exe -hf" (2.x syntax) to parse that output and "discover" the available NASM optimization flags... but the new NASM 3.x changed the help syntax to "nasm.exe -h all" and removed the old "-hf" causing stdout to be empty. Thus, the build script couldn't "discover any optimization flags" and aborted the build. That's what happens when the discoverability mechanism itself is not standardized across all CLI tools.) (I'm not saying nasm needs a MCP server to avoid the "-hf" vs "-h all" problem. It's just an anecdote about CLI tools being inconsistent.)
Same variety of "no common standards" applies to existing APIs that weren't originally intended for AI consumption.
MCP makes things less open-ended and more structured by listing specific integration points. This makes it much easier to add quickly capabilities to Claud Desktop and other AI tools etc.
Yes, an AI tool could certainly burn a bunch of tokens and electricity by simply running random "clitool --help" and parse that output through the LLM context, then "learn" the likely actions that can do/answer whatever the AI user prompted in English. Or skip all that inefficiency and have people agree on how to specify the exact integration points (the "tools & resources" in MCP lingo). Everybody agreeing on how to do that is basically what MCP is.
Or put another way, the MCP protocol is itself "a well-scoped and discoverable API" that you're suggesting.
E.g. rather than give AI tool raw access to Python API of software HomeAssistant smarthome hub, people created MCP servers to give a whitelist of available actions to AI chatbots. AI doesn't "need" an MCP server in this case but it makes easier and more predictable than the raw Python API.
MCP ideas of standardizing the discovery and whitelisting of available actions are another implementation of the decades long quest in computer science to "catalog a universe of services/capabilities and have tools discover them". It has overlaps with previous ideas such as CORBA RPC to describe available functions (IDL interface descript language), Microsoft COM services IUnknown::QueryInterface, Roy Fielding's original REST HATEOAS where an entrypoint url (say a banking url) uses a standardized field to specify the next set of urls that are useful (url to create account, make a deposit, etc.)
MCP are not "better" than CLI/API tools. They solve a different problem. Standardized instead of adhoc discovery of capabilities, N+M instead of NxM combinatorial integrations, security, etc.
The last time I looked at MCPs closely, they appeared to pollute context and just hang there consuming context constantly. Whereas a self-documenting API or CLI tool enabled progressive discovery.
Has this changed?
My uncharitable interpretation is that MCP servers are NJ design for agents, and high quality APIs and CLIs are MIT design.
But at the end of the day, MCP is about making it easy/standard to pull in context from different sources. For example, to get logs from a CI run for my PR, or to look at jira tickets, or to interact with GitHub. Sure, a very simple
API baked into the model’s existing context is even better (Claude will just use the GH CLI for lots of stuff, no MCP there.)
MCP is literally just a way for end users to be able to quickly plug in to those ecosystems. Like, yeah, I could make some extra documentation about how to use my CI provider’s API, put an access token somewhere the agent can use… or I could just add the remote MCP and the agent has what it needs to figure out what the API looks like.
It also lets the provider (say, Jira) get some control over how models access your service instead of writing whatever API requests they feel like.
Like, MCP is really not that crazy. It’s just a somewhat standard way to make plugins for getting extra context. Sure, agents are good at writing with API requests, but they’re not so good at knowing why, when, or what to use.
People get worked up over the word “protocol” like it has to mean some kind of super advanced and clever transport-layer technology, but I digress :p
You're making the convenience argument, but I'm making the architecture argument. They're not the same thing.
You say "a very simple API baked into the model's existing context is even better". So we agree? MCP's design actively discourages that better path.
"Agents are good at writing API requests, but not so good at knowing why, when, or what to use". This is exactly what progressive discovery solves. A good CLI has --help. A good API has introspection. MCP's answer is "dump all the tool schemas into context and let the model figure it out," which is O(N) context cost at all times vs O(1) until you actually need something.
"It's just a standard way to make plugins" The plugin pattern of "here are 47 tool descriptions, good luck" is exactly the worse-is-better tradeoff I'm describing. Easy to wire up, expensive at runtime, and it gets worse as you add more servers.
The NJ/MIT analogy isn't about complexity, it's about where the design effort goes. MCP puts the effort into easy integration. A well-designed API puts the effort into efficient discovery. One scales, the other doesn't.
I tried using the Microsoft azure devops MCP and it immediately filled up 160k of my context window with what I can only assume was listing out an absurd number of projects. Now I just instruct it to make direct API calls for the specific resources, I don’t know maybe I’m doing something wrong in Cursor, or maybe Microsoft is just cranking out garbage (possible), but to get that context down I had to uncheck all the myriad features that MCP supplies.
How do you manage auth for services that use OAuth?
I’ve been wrapping the agent’s curl calls in a small cli that handles the auth but I’m wondering if other people have come up with something lighter/more portable.
Would this be any better than just pasting links to the appropriate documentation for the technology you want to use in your AGENTS.md file? I suppose it's better if it's a single giant text file so there are fewer agent iterations navigating links within the docs but then doc sites could just provide that, like https://docs.avohq.io/3.0/llm-support.html
I need to give this a try, but nowadays I am reluctant to fire up Gemini CLI due to its insane appetite for tokens.
It doesnt matter if your LLM in/out tokens are a bit cheaper than competitors when you use 3x of them on every prompt. Maybe Google should focus on addressing that first?
I can relate to this. Gemini 3 doesn’t know a thing about iOS 26 or Liquid Glass. It constantly assumes this is some custom view that I want it to develop and ends up building something out the previous gen apis like ultrathinmaterial.
Why do people have to make this stuff so complicated? An API that requires a key and enabling an MCP server and configuring your client to fetch markdown files on the fly? There's documentation on how to set things up to be able to get the documentation? Why not just a tar with all the docs? How big are they? A couple MB? Agents are really good at using grep on text files. So is my text editor.
Want it to be easy to update? Make it a git repo with all the docs. My agent already knows to always do a git fetch before interacting with a repo in a new session. Or you can fetch on a timer. Whatever.
I haven't yet figured out the point of this MCP stuff. Codex seems to have innate knowledge of how to curl jira and confluence and gitlab and prometheus and SQL databases and more. All you need to configure is a .netrc file and put the hostname in AGENTS.md. Are MCP tools even composable? Like can the model pipe the response to grep or jq or another MCP call without it entering/wasting context? Or is a normal CRUD API strictly more powerful and easier to use?
> Why do people have to make this stuff so complicated? An API that requires a key
If it didn't require a key, it would be marginally harder to track usage...
I can't help but feel that "read-only public knowledge Markdown-files MCP" should really just be a webpage. Authentication should be optional by default, for things like company IP. But maybe I'm missing the point too?
MCP servers are the correct way to offer this service. Webpages are for humans, these served documents are for agents.
You could argue that they could just let the agent curl an agent-optimized API, and that is what MCP is.
Sure, but Google isn't maintaining two sets of documentation here, the MCP server is just a thin wrapper around the webpage with a little search tool. So it's still the docs for humans just with a different delivery mechanism. Which is fine, but you can understand when hypertext exists largely for this exact purpose folks would find it odd and over complicated to reinvent the web over jsonrpc for robots.
The point of MCP is discoverability. A crud app is better, except you have to waste context telling your LLM a bunch of details. With MCP you only put into it's context what the circumstances are where it applies, and it can just invoke it. You could write a bunch of little wrapper scripts around each api you want to use and have basically reinvented MCP for yourself.
Most MCPs I've seen could be:
1. A cli script or small collection of scripts
2. A very short markdown file explaining how it works and when to use it.
3. Optionally, some other reference markdown files
Context use is tiny, nearly everything is loaded on demand.
And as I'm writing this, I realize it's exactly what skills are.
Can anyone give an example of something that this wouldn't work for, and which would require MCP instead?
But this is entirely besides the point. The point of MCP is bundling those exact things into a standardized plugin that’s easy for people to share with others.
MCP is useful because I can add one in a single click for an external service (say, my CI provider). And it gives the provider some control over how the agent accesses resources (for example, more efficient/compressed, agent-oriented log retrieval vs the full log dump a human wants). And it can set up the auth token when you install it.
So yeah, the agent could write some those queries manually (might need me to point it to the docs), and I could write helpers… or I could just one-click install the plugin and be done with it.
I don’t get why people get worked up over MCP, it’s just a (perhaps temporary) tool to help us get more context into agents in a more standard way than everyone writing a million different markdown files and helper scripts.
"The point of MCP is bundling those exact things into a standardized plugin that’s easy for people to share with others." Like... a CLI/API?
"MCP is useful because I can add one in a single click for an external service" Like... a CLI/API? [edit: sorry, not click, single 'uv' or 'brew' command]
"So yeah, the agent could write some those queries manually" Or, you could have a high-level CLI/API instead of a raw one?
"I don’t get why people get worked up over MCP" Because we tried them and got burned?
"to help us get more context into agents in a more standard way than everyone writing a million different markdown files and helper scripts." Agreed it's slightly annoying to add 'make sure to use this CLI/API for this purpose' in AGENTS.md but really not much. It's not a million markdown files tho. I think you're missing some existing pattern here.
Again, I fail to see how most MCPs are not lazy tools that could be well-scoped discoverable safe-to-use CLI/APIs.
That's literally what they are. It's a dead simple self describing JSONRPC API that you can understand if you spend 5 seconds looking at it. I don't get why people get so worked up over it as if it's some big over-engineered spec.
I can run an MPC on my local machine and connect it to an LLM FE in a browser.
I can use the GitHub MCP without installing anything on my machine at all.
I can run agents as root in a VM and give them access to things via an MCP running outside of the VM without giving them access to secrets.
It's an objectively better solution than just giving it CLIs.
All true except that CLI tools are composable and don't pollute your context when run via a script. The missing link for MCP would be a CLI utility to invoke it.
How does the agent know what clis/tools it has available? If there's an `mcpcli --help` that dumps the tool calls, we've just moved the problem.
The composition argument is compelling though. Instead of clis though, what if the agent could write code where the tools are made available as functions?
>Like... a CLI/API? [...] , I fail to see how most MCPs are not lazy tools that could be well-scoped discoverable safe-to-use CLI/APIs.
The "discoverable" action itself is specified in the MCP standard. The "well-scoped" is accomplished by creating a whitelist of tool resources in the MCP manifest.
In contrast, a general-purpose CLI/API that wasn't specialized for AI usage is more open-ended and less standardized than the explicit MCP protocol.
Yes, existing Claude can already use existing CLI/API tools without any MCP server but that doesn't make MCP redundant. (But I'm not saying this thread's article about fetching the latest Google Android docs needs an MCP server.)
E.g. you mentioned CLI already has discoverability e.g. "clitool --help". That's somewhat true but it's still not as standardized as the MCP specification for discovering available resources and actions. The problem is the CLI implementation for displaying syntax and help could be spelled differently such as "clitool -help" (1 hyphen not 2) or "clitool -h" or "/help" or "/?". Some CLI tools also have extra detailed help that requires a modifier such as "clitool -help all". Or the critical CLI usage to solve a random AI user prompt is actually described in the "README.MD". The text output from the CLI's help option is not standardized. The point is none of that is standardized among all developers of various CLI tools.
(Random note.. last week, my ffmpeg build with the AV1 codec broke because I upgraded from NASM 2.x to NASM 3.x. The Google's libaomav1 build script[0] did an interesting hack by calling "nasm.exe -hf" (2.x syntax) to parse that output and "discover" the available NASM optimization flags... but the new NASM 3.x changed the help syntax to "nasm.exe -h all" and removed the old "-hf" causing stdout to be empty. Thus, the build script couldn't "discover any optimization flags" and aborted the build. That's what happens when the discoverability mechanism itself is not standardized across all CLI tools.) (I'm not saying nasm needs a MCP server to avoid the "-hf" vs "-h all" problem. It's just an anecdote about CLI tools being inconsistent.)
Same variety of "no common standards" applies to existing APIs that weren't originally intended for AI consumption.
MCP makes things less open-ended and more structured by listing specific integration points. This makes it much easier to add quickly capabilities to Claud Desktop and other AI tools etc.
Yes, an AI tool could certainly burn a bunch of tokens and electricity by simply running random "clitool --help" and parse that output through the LLM context, then "learn" the likely actions that can do/answer whatever the AI user prompted in English. Or skip all that inefficiency and have people agree on how to specify the exact integration points (the "tools & resources" in MCP lingo). Everybody agreeing on how to do that is basically what MCP is.
Or put another way, the MCP protocol is itself "a well-scoped and discoverable API" that you're suggesting.
E.g. rather than give AI tool raw access to Python API of software HomeAssistant smarthome hub, people created MCP servers to give a whitelist of available actions to AI chatbots. AI doesn't "need" an MCP server in this case but it makes easier and more predictable than the raw Python API.
MCP ideas of standardizing the discovery and whitelisting of available actions are another implementation of the decades long quest in computer science to "catalog a universe of services/capabilities and have tools discover them". It has overlaps with previous ideas such as CORBA RPC to describe available functions (IDL interface descript language), Microsoft COM services IUnknown::QueryInterface, Roy Fielding's original REST HATEOAS where an entrypoint url (say a banking url) uses a standardized field to specify the next set of urls that are useful (url to create account, make a deposit, etc.)
MCP are not "better" than CLI/API tools. They solve a different problem. Standardized instead of adhoc discovery of capabilities, N+M instead of NxM combinatorial integrations, security, etc.
[0] https://aomedia.googlesource.com/aom/+/refs/tags/v3.13.1/bui...
I'm with you because we get to specify our context more precisely.
The last time I looked at MCPs closely, they appeared to pollute context and just hang there consuming context constantly. Whereas a self-documenting API or CLI tool enabled progressive discovery.
Has this changed?
My uncharitable interpretation is that MCP servers are NJ design for agents, and high quality APIs and CLIs are MIT design.
There has been some improvement in that area.
But at the end of the day, MCP is about making it easy/standard to pull in context from different sources. For example, to get logs from a CI run for my PR, or to look at jira tickets, or to interact with GitHub. Sure, a very simple API baked into the model’s existing context is even better (Claude will just use the GH CLI for lots of stuff, no MCP there.)
MCP is literally just a way for end users to be able to quickly plug in to those ecosystems. Like, yeah, I could make some extra documentation about how to use my CI provider’s API, put an access token somewhere the agent can use… or I could just add the remote MCP and the agent has what it needs to figure out what the API looks like.
It also lets the provider (say, Jira) get some control over how models access your service instead of writing whatever API requests they feel like.
Like, MCP is really not that crazy. It’s just a somewhat standard way to make plugins for getting extra context. Sure, agents are good at writing with API requests, but they’re not so good at knowing why, when, or what to use.
People get worked up over the word “protocol” like it has to mean some kind of super advanced and clever transport-layer technology, but I digress :p
You're making the convenience argument, but I'm making the architecture argument. They're not the same thing.
You say "a very simple API baked into the model's existing context is even better". So we agree? MCP's design actively discourages that better path.
"Agents are good at writing API requests, but not so good at knowing why, when, or what to use". This is exactly what progressive discovery solves. A good CLI has --help. A good API has introspection. MCP's answer is "dump all the tool schemas into context and let the model figure it out," which is O(N) context cost at all times vs O(1) until you actually need something.
"It's just a standard way to make plugins" The plugin pattern of "here are 47 tool descriptions, good luck" is exactly the worse-is-better tradeoff I'm describing. Easy to wire up, expensive at runtime, and it gets worse as you add more servers.
The NJ/MIT analogy isn't about complexity, it's about where the design effort goes. MCP puts the effort into easy integration. A well-designed API puts the effort into efficient discovery. One scales, the other doesn't.
I tried using the Microsoft azure devops MCP and it immediately filled up 160k of my context window with what I can only assume was listing out an absurd number of projects. Now I just instruct it to make direct API calls for the specific resources, I don’t know maybe I’m doing something wrong in Cursor, or maybe Microsoft is just cranking out garbage (possible), but to get that context down I had to uncheck all the myriad features that MCP supplies.
> Why not just a tar with all the docs? How big are they? A couple MB?
Yep... in fact there are already a lot of tooling for that, e.g. man obviously but also apropos.How do you manage auth for services that use OAuth?
I’ve been wrapping the agent’s curl calls in a small cli that handles the auth but I’m wondering if other people have come up with something lighter/more portable.
Having picked out an Oauth flow is one of the main selling points of MCP
> Why do people have to make this stuff so complicated?
Job security.
Would this be any better than just pasting links to the appropriate documentation for the technology you want to use in your AGENTS.md file? I suppose it's better if it's a single giant text file so there are fewer agent iterations navigating links within the docs but then doc sites could just provide that, like https://docs.avohq.io/3.0/llm-support.html
AWS has theirs as well: https://awslabs.github.io/mcp/servers/aws-documentation-mcp-...
As it turns out these are very helpful for obscure features and settings buried in the documentation.
Microsoft too:
https://learn.microsoft.com/training/support/mcp
https://github.com/MicrosoftDocs/mcp
https://devblogs.microsoft.com/dotnet/microsoft-learn-mcp-se...
I need to give this a try, but nowadays I am reluctant to fire up Gemini CLI due to its insane appetite for tokens.
It doesnt matter if your LLM in/out tokens are a bit cheaper than competitors when you use 3x of them on every prompt. Maybe Google should focus on addressing that first?
So an mcp server just for google specific public docs? Aren't there a dozen of them like Context7 (https://context7.com/) that already do this?
Also curious how this differentiates itself from Context7, which has been the go-to choice for something like this. Where's the benefit?
There’s something almost nostalgic about it: cutting-edge technology wrapped in layers of bureaucracy that feel lovingly inherited from another era.
Why not just an http server providing access to markdown files? Your llm can curl the files.
This must be what gwern meant when he said to write for AI.
I can relate to this. Gemini 3 doesn’t know a thing about iOS 26 or Liquid Glass. It constantly assumes this is some custom view that I want it to develop and ends up building something out the previous gen apis like ultrathinmaterial.