[HN Gopher] Introducing the Developer Knowledge API and MCP Server
___________________________________________________________________
Introducing the Developer Knowledge API and MCP Server
Author : gfortaine
Score : 82 points
Date : 2026-02-06 23:58 UTC (23 hours ago)
(HTM) web link (developers.googleblog.com)
(TXT) w3m dump (developers.googleblog.com)
| er4hn wrote:
| This must be what gwern meant when he said to write for AI.
| Esophagus4 wrote:
| 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.
| nlawalker wrote:
| Microsoft too:
|
| https://learn.microsoft.com/training/support/mcp
|
| https://github.com/MicrosoftDocs/mcp
|
| https://devblogs.microsoft.com/dotnet/microsoft-learn-mcp-se...
| ndriscoll wrote:
| 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 wrote:
| > Why do people have to make this stuff so complicated?
|
| Job security.
| superturkey650 wrote:
| 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 wrote:
| Having picked out an Oauth flow is one of the main selling
| points of MCP
| utopiah wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm with you because we get to specify our context more
| precisely.
| anon7000 wrote:
| 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.
| bravura wrote:
| "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.
| 0x696C6961 wrote:
| 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.
| philipp-gayret wrote:
| 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.
| 0x696C6961 wrote:
| 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())
| philipp-gayret wrote:
| > 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).
| jmalicki wrote:
| 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"
| jmalicki wrote:
| 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.
| bravura wrote:
| 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.
| anon7000 wrote:
| 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
| bravura wrote:
| 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.
| qwertox wrote:
| 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 wrote:
| 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.
| inshard wrote:
| 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.
| lemonish97 wrote:
| 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?
| bryanhogan wrote:
| Also curious how this differentiates itself from Context7,
| which has been the go-to choice for something like this.
| Where's the benefit?
| pulkas wrote:
| There's something almost nostalgic about it: cutting-edge
| technology wrapped in layers of bureaucracy that feel lovingly
| inherited from another era.
| throwa356262 wrote:
| 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?
| ako wrote:
| Why not just an http server providing access to markdown files?
| Your llm can curl the files.
| timwis wrote:
| 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
| skybrian wrote:
| This could probably be a downloadable skill, but they will get
| more data about which docs coding agents are reading if it's an
| API call.
___________________________________________________________________
(page generated 2026-02-07 23:02 UTC)