Introducing the Developer Knowledge API and MCP Server

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?

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.

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?

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?

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

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.