Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the Developer Knowledge API and MCP Server

developers.googleblog.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Introducing the Developer Knowledge API and MCP Server

#21

Post by bravura »

anon7000 wrote: post #18
bravura wrote: post #17

Earlier quoted context omitted.

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 literall…

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.

Re: Introducing the Developer Knowledge API and MCP Server

#22

Post by bravura »

anon7000 wrote: post #20
esperent wrote: post #14

Earlier quoted context omitted.

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…

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…

"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.

Re: Introducing the Developer Knowledge API and MCP Server

#23

Post by 0x696C6961 »

bravura wrote: post #22
anon7000 wrote: post #20

Earlier quoted context omitted.

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…

"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? "…

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.

Re: Introducing the Developer Knowledge API and MCP Server

#25

Post by bryanhogan »

lemonish97 wrote: post #9

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?

Re: Introducing the Developer Knowledge API and MCP Server

#26

Post by philipp-gayret »

0x696C6961 wrote: post #23
bravura wrote: post #22

Earlier quoted context omitted.

"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? "…

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 an…

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.

Re: Introducing the Developer Knowledge API and MCP Server

#27

Post by timwis »

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

Re: Introducing the Developer Knowledge API and MCP Server

#28

Post by [deleted] »

bravura wrote: post #22
anon7000 wrote: post #20

Earlier quoted context omitted.

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…

"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? "…

[deleted]

Re: Introducing the Developer Knowledge API and MCP Server

#29

Post by qwertox »

ndriscoll wrote: post #4

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…

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.

Re: Introducing the Developer Knowledge API and MCP Server

#30

Post by Spivak »

qwertox wrote: post #29
ndriscoll wrote: post #4

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…

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.
Post reply on HN