4 ms·

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

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?

latchkey 9mo ago
> Why do people have to make this stuff so complicated? Job security.
superturkey650 9mo ago
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.
- acchow 9mo ago
  Having picked out an Oauth flow is one of the main selling points of MCP
utopiah 9mo ago
> Why not just a tar with all the docs? How big are they? A couple MB? fabien@debian2080ti:~$ du -sh /usr/share/man/ #all lang 52M /usr/share/man/ Yep... in fact there are already a lot of tooling for that, e.g. man obviously but also apropos.
tvink 9mo ago
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.
- wincy 9mo ago
  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.
- esperent 9mo ago
  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?
  - ra 9mo ago
    I'm with you because we get to specify our context more precisely.
  - anon7000 9mo ago
    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.
qwertox 9mo ago
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.
- Spivak 9mo ago
  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.
deleted 9mo ago
[deleted]
gwern 9mo ago
You don't even need to do git or a tarball! HTTP/HTML already has an "API" for serving Markdown to any agent like a LLM which wants it, because you can easily set a server to return Markdown with an accept-encoding (kinda why that functionality exists in the first place). I set my nginx to return the Markdown source (which is just $URL.md) for my website; any LLM which wants up-to-date docs from my website can do so as easily as `curl --header 'Accept: text/markdown' 'https://gwern.net/archiving https://gwern.net/archiving'`. One simple flag. Boom, done.

latchkey 9mo ago

> Why do people have to make this stuff so complicated? Job security.

superturkey650 9mo ago

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.

acchow 9mo ago
Having picked out an Oauth flow is one of the main selling points of MCP

utopiah 9mo ago

> Why not just a tar with all the docs? How big are they? A couple MB? fabien@debian2080ti:~$ du -sh /usr/share/man/ #all lang 52M /usr/share/man/ Yep... in fact there are already a lot of tooling for that, e.g. man obviously but also apropos.

tvink 9mo ago

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.

wincy 9mo ago
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.
esperent 9mo ago
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?
- ra 9mo ago
  I'm with you because we get to specify our context more precisely.
- anon7000 9mo ago
  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.

qwertox 9mo ago

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.

Spivak 9mo ago
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.

deleted 9mo ago

[deleted]

gwern 9mo ago

You don't even need to do git or a tarball! HTTP/HTML already has an "API" for serving Markdown to any agent like a LLM which wants it, because you can easily set a server to return Markdown with an accept-encoding (kinda why that functionality exists in the first place). I set my nginx to return the Markdown source (which is just $URL.md) for my website; any LLM which wants up-to-date docs from my website can do so as easily as `curl --header 'Accept: text/markdown' 'https://gwern.net/archiving https://gwern.net/archiving'`. One simple flag. Boom, done.