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

11–20 of 37 posts

Re: Introducing the Developer Knowledge API and MCP Server

#11

Post by tvink »

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…

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.

Re: Introducing the Developer Knowledge API and MCP Server

#12

Post by wincy »

tvink wrote: post #11
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…

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.

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.

Re: Introducing the Developer Knowledge API and MCP Server

#14

Post by esperent »

tvink wrote: post #11
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…

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?

Re: Introducing the Developer Knowledge API and MCP Server

#15

Post by throwa356262 »

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?

Re: Introducing the Developer Knowledge API and MCP Server

#16

Post by acchow »

superturkey650 wrote: post #8
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…

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

Re: Introducing the Developer Knowledge API and MCP Server

#17

Post by bravura »

tvink wrote: post #11
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…

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.

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.

Re: Introducing the Developer Knowledge API and MCP Server

#18

Post by anon7000 »

bravura wrote: post #17
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.

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

Re: Introducing the Developer Knowledge API and MCP Server

#19

Post by ra »

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'm with you because we get to specify our context more precisely.

Re: Introducing the Developer Knowledge API and MCP Server

#20

Post by anon7000 »

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…

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.

Post reply on HN