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

31–37 of 37 posts

Re: Introducing the Developer Knowledge API and MCP Server

#31

Post by 0x696C6961 »

philipp-gayret wrote: post #26
0x696C6961 wrote: post #23

Earlier quoted context omitted.

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.

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?

   tools.get_foo(tools.get_bar())

Re: Introducing the Developer Knowledge API and MCP Server

#32

Post by [deleted] »

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…

[deleted]

Re: Introducing the Developer Knowledge API and MCP Server

#33

Post by philipp-gayret »

0x696C6961 wrote: post #31
philipp-gayret wrote: post #26

Earlier quoted context omitted.

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? tools.get_foo(tools.get_bar())

> what if the agent could write code where the tools are made available as functions?

Exactly, that would be of great help.

> If there's an `mcpcli --help` that dumps the tool calls, we've just moved the problem.

I see I worded my comment completely wrong... My bad. Indeed MCP tool definitions should probably be in context. What I dislike about MCP is that the IO immediately goes into context for the AI Agents I've seen.

Example: Very early on when Cursor just received beta MCP support I tried a Google Maps MCP from somewhere on the net; asked Cursor "Find me boxing gyms in Amsterdam". The MCP call then dumped a HATEOAS-annotated massive JSON causing Cursor to run out of context immediately. If it had been a CLI tool instead, Cursor could have wrapped it in say a `jq` to keep the context clean(er).

Re: Introducing the Developer Knowledge API and MCP Server

#34

Post by jmalicki »

esperent wrote: post #14
tvink wrote: post #11

Earlier quoted context omitted.

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…

I mean, one could argue skills are sort of MCP 2.0 fixing some of the mistakes.

The big pluses for MCPs are when:

1. They live remotely and update themselves 2. You install the skill and the scripts it uses together locally, so it can be more convenient packaging

MCPs aren't really all that complicated inherently, a lot of mistakes around them happened because they came early.

Re: Introducing the Developer Knowledge API and MCP Server

#35

Post by jmalicki »

philipp-gayret wrote: post #33
0x696C6961 wrote: post #31

Earlier quoted context omitted.

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? tools.get_foo(tools.get_bar())

> what if the agent could write code where the tools are made available as functions? Exactly, that would be of great help. > If there's an `mcpcli --help` that dumps the tool calls, we've just moved the problem. I see I worded my comment completely wrong... My bad. Indeed MCP tool definitions should probably be in context. What I dislike about MCP is that the IO immediately goes into context for the AI Agents I've s…

I mean what was keeping Cursor from running jq there? It's just a matter of being integrated poorly - which is largely why there was a rethink of "we just made this harder on ourselves, let's accomplish this with skills instead"

Re: Introducing the Developer Knowledge API and MCP Server

#37

Post by gwern »

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…

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'`. One simple flag. Boom, done.

Post reply on HN