Developer Knowledge API + MCP Server
February 10, 2026
By Shivam Gautam
Google Just Fixed the #1 Reason AI Coding Assistants Fail: Outdated Docs
Every AI coding assistant has the same failure mode:
It answers like it’s confident.
It’s wrong because the docs changed last week.
Google’s new Developer Knowledge API + official MCP server is a direct counterpunch: your agent can fetch canonical Google developer documentation (as Markdown) at runtime — without scraping, without brittle parsers, without stale indexes. (Google Developers Blog)
If you’re building IDE copilots, internal developer assistants, agent workflows, or “help me implement this” experiences around Google products (Cloud, Firebase, Android, Maps), this is not a minor release. This is docs becoming a first-class tool. (Source)
The enemy: HTML scraping + stale embeddings
Let’s call it what it is:
Most “RAG over docs” pipelines are a house of cards:
- scrape HTML
- clean + chunk
- embed + index
- hope it’s not outdated
- pray the DOM didn’t change
That system fails quietly. And nothing kills trust faster than a dev tool that’s wrong in a confident voice.
Google’s pitch is simple: stop guessing. Use a canonical, machine-readable gateway to official documentation. (Google Developers Blog)
What Google shipped
1) Developer Knowledge API (public preview)
Google says the Developer Knowledge API is designed to be a canonical source for machine-readable access to Google developer documentation. It supports:
- SearchDocumentChunks to find relevant URIs + snippets
- GetDocument / BatchGetDocuments to retrieve full doc content (returned as unstructured Markdown)
Reference: Developer Knowledge API overview
Google also notes docs are re-indexed frequently (during preview, they describe re-indexing within ~24 hours), which is the whole point: freshness. (Source)
2) An official Developer Knowledge MCP Server
They didn’t stop at an API. They also shipped an MCP server for it—so any MCP-compatible assistant/tool can call it like a standard tool. (Google Developers Blog)
This is the bigger story: tool-first documentation retrieval beats “model memory” every time.
Getting started guide: Connect to the Developer Knowledge MCP server
Why Markdown output is the cheat code
Markdown is the difference between “it technically works” and “it works reliably.”
Markdown means:
- consistent chunking
- clean quoting/citation
- simpler summaries
- fewer layout surprises vs HTML parsing
Google explicitly positions this as high-quality unstructured Markdown with plans to add more structure over time. (Source)
What this unlocks immediately (real-world use cases)
Google highlights three killer categories for AI dev tools: (Source)
1) Implementation guidance
“How do I do X in Firebase/Android/Cloud?” becomes “fetch relevant canonical docs → generate steps → cite sources”.
2) Troubleshooting
Errors become: “read official error docs → propose fix + verify”.
3) Comparative analysis
“Cloud Run vs Cloud Functions?” becomes: “retrieve current docs for both → compare constraints + pricing notes → summarize”.
The point: your assistant can read reality before it speaks.
Getting started (fast path)
Google’s “Connect to the Developer Knowledge MCP server” guide boils down to: (Guide)
- Create a Google Cloud project + API key
- Enable the Developer Knowledge API
- Enable the remote MCP server via gcloud
- Configure your MCP client/tool with the API key
Google recommends enabling only the MCP servers you actually need (least privilege). (Source)
Where this fits in a modern agent stack
A clean mental model:
LLM/Agent → MCP client → Developer Knowledge MCP server → canonical docs (Markdown)
Reference (MCP server concept + proxy model): MCP reference for developerknowledge.googleapis.com
MCP spec: Model Context Protocol specification
MCPfy POV: “Official MCP servers are step 1. Production is step 2.”
Google’s managed server is a huge win: canonical input, standardized interface, less glue.
But if you’re shipping a real product, you still need the production layer:
1) Observability (the missing superpower)
- What doc did the agent fetch?
- Which query triggered it?
- What citations did it use?
- Did the retrieval actually match user intent?
If you can’t answer those, you can’t debug.
2) Caching + dedupe
Docs calls shouldn’t be repeated 20 times per conversation. Cache by URI + checksum/timestamp. Make “freshness policy” explicit (e.g., cache 6h unless error).
3) Routing (tool choice is everything)
Most dev copilots need multiple servers:
- Google docs (Developer Knowledge MCP)
- internal runbooks (your MCP server)
- GitHub code search
- support tickets
- incident dashboards
Routing is what separates a demo from a system.
4) Guardrails against “retrieved prompt injection”
Treat retrieved content as untrusted input. Your agent should summarize docs, cite them, and never execute instructions embedded in retrieved text.
Need help building your own server? Start with the MCPfy guide: docs.mcpfy.ai/create-server.
What you should do this week (builder checklist)
If you build anything around Google APIs:
- Replace doc scraping with Developer Knowledge retrieval
- Make doc retrieval a tool call, not a “memory test”
- Log + store citations (debuggable answers win)
- Add caching and a freshness policy
- Keep internal + external knowledge separate, but composable via MCP
That’s the path to assistants that feel reliable, not “impressive when lucky.”
TL;DR
- Developer Knowledge API = canonical, machine-readable access to Google developer docs, including search + Markdown retrieval. (Docs)
- Developer Knowledge MCP server = a standard MCP tool interface so agents/IDEs can “read the docs” live. (Docs)
- Outcome: fewer hallucinations, less scraping debt, more trust. (Blog)