# google/adk-docs: the documentation repository behind Google's Agent Development Kit

> google/adk-docs is the MkDocs source tree that publishes adk.dev, the documentation home for the Agent Development Kit. It is a docs repo, not the agent runtime, and that distinction decides whether you should clone it.

**google/adk-docs** — An open-source, code-first toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.

- Repository: https://github.com/google/adk-docs
- Website: https://adk.dev
- Stars: 1,508 · Forks: 1,322
- Language: Shell
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-adk-docs

## What google/adk-docs actually contains

The repository is the source of the adk.dev website. Its top level holds docs/, examples/, overrides/, site/, scripts/, tools/, hooks/, mkdocs.yml, netlify.toml, lychee.toml, requirements.txt, llms.txt and llms-full.txt. That layout is a static documentation site, not a library. There is no agent runtime code here, no package manifest for a Python or TypeScript distribution, and no release artefacts.

The README describes Agent Development Kit itself as "an open-source, code-first toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control", optimized for Gemini and the Google ecosystem while remaining model-agnostic and deployment-agnostic. The docs repository is where that description, plus the per-language get-started guides and the tool and orchestration references, is written and published. If you want the framework, you install google-adk from PyPI or @google/adk from npm; if you want the words that explain the framework, you are in the right repository.

## MkDocs, pagefind and the generated llms.txt files

The site is built with MkDocs and the Material theme. requirements.txt pins mkdocs-material==9.7.0, mkdocs-redirects==1.2.2, mkdocs-linkcheck==1.0.6, mkdocs-llmstxt==0.5.0, mkdocs-macros-plugin==1.4.1, click==8.2.1 and pagefind[bin]==1.5.2. Each entry maps to a visible behaviour: mkdocs-redirects handles moved pages, mkdocs-linkcheck validates links, pagefind provides client-side search, and mkdocs-llmstxt generates the two AI-facing files.

That last plugin explains why llms.txt and llms-full.txt sit at the repository root. The README calls llms.txt "a structured index of ADK documentation, designed to help LLMs navigate and locate specific topics and guides" and llms-full.txt "the comprehensive documentation reference". Because a plugin produces them, editing those files directly is the wrong move; the change belongs in the docs source and the files are regenerated. The same logic applies to site/, which is build output. The lychee.toml and .lycheeignore pair points to a second, separate link checker alongside mkdocs-linkcheck, which is worth knowing before you assume a single tool owns link validation.

## Building the docs locally and reading your first page

The README does not give install steps for the docs repository itself; it points readers to adk.dev and to the per-language get-started pages. What the repository does provide is requirements.txt, so the build path is the standard MkDocs one. Install the pinned dependencies first.

```bash
pip install -r requirements.txt
```

Then serve the site. mkdocs.yml is the configuration file at the repository root, and the Material theme plus the macros plugin are already declared there, so no extra flags are needed.

```bash
mkdocs serve
```

MkDocs prints a local URL, by default http://127.0.0.1:8000, and rebuilds as you edit files under docs/. Open the get-started page for the language you care about and change a sentence; the browser should refresh with your edit. To produce the static output that netlify.toml deploys, run the build command instead.

```bash
mkdocs build
```

The generated site lands in site/. If you are working on the AI-facing files, remember they come from the llmstxt plugin during the build, so check llms.txt after a build rather than editing it by hand. The examples/ directory is organised by language (go, java, kotlin, python, typescript), and each of those subdirectories is currently just a .gitkeep placeholder, so do not expect runnable sample agents to be checked in here.

## The maintenance question this repository cannot answer

The GitHub metadata for google/adk-docs records no last push date and no releases. The repository is not archived, but with no push timestamp available there is no basis for calling it actively maintained, and no basis for calling it stale either. Anyone evaluating the project on repository activity alone is working with a blank field.

That matters less than it first appears, because the thing most readers actually want to evaluate is ADK itself, and ADK ships through PyPI, npm, pkg.go.dev and Maven Central, where version history is visible. The docs repository is a distribution channel for prose. Its health is best judged by whether adk.dev reflects the current framework behaviour, which is a content question, not a commit-frequency question. Treat the missing timestamp as a reason to check the site rather than as a signal in either direction.

## Where this repository is the wrong thing to clone

Cloning google/adk-docs gives you no way to run an agent. There is no agent runtime, no CLI entry point for building agents, and no package to import. A developer who wants to try ADK should follow the README's links to the Python, TypeScript, Go, Java or Kotlin get-started pages on adk.dev and install the corresponding package from its registry.

The second trap is contribution scope. The repository's CONTRIBUTING.md governs changes here, and the README frames contributions as bug reports, feature requests, documentation improvements and code contributions. But a framework bug belongs with the framework package, not with the docs tree, and no mapping between the two is published. If you file a runtime defect against adk-docs, expect it to be redirected. The third trap is the generated artefacts: site/, llms.txt and llms-full.txt look editable and are not, so a patch against them will conflict with the next build.

## How this differs from writing docs inside a framework repo

The obvious alternative is the common pattern of keeping documentation inside the main framework repository, as a docs/ folder next to the source. ADK splits them: google/adk-docs holds the documentation site, and the installable packages live elsewhere on PyPI, npm, pkg.go.dev and Maven Central. The difference is not cosmetic. A separate docs repository lets the site build, link checking and search indexing run independently of the framework's test and release pipeline, and it lets the llms.txt generation be pinned to a specific mkdocs-llmstxt version rather than to whatever the framework's dependency resolver picks.

The cost is coordination. When a framework release changes an API, nothing in this repository's requirements.txt or mkdocs.yml will tell you the prose is now wrong. There is no version pin between the docs and the packages they describe. Projects that keep docs in-tree get that coupling for free, at the price of a heavier build. ADK chose the lighter build and accepted the manual sync. That is a defensible trade, but it means the docs repository cannot be trusted to be current on its own; the reader has to check the package version they installed against the page they are reading.

## Licence and the cost of keeping a fork

The repository is Apache-2.0, per the README and the LICENSE file at the root. Apache-2.0 permits commercial use, modification and redistribution with the usual conditions around notices and the patent grant; the README points to LICENSE for the terms. This is a permissive licence on documentation content, which is a more comfortable position for corporate forks than a documentation-specific copyleft licence would be. Nothing here constitutes legal advice, and if you plan to republish substantial parts of adk.dev you should read LICENSE and CONTRIBUTING.md rather than rely on the summary.

The upgrade cost is the real ongoing expense. Dependencies are pinned exactly, so bumping mkdocs-material or pagefind is a deliberate act. mkdocs-llmstxt==0.5.0 is the pin most likely to bite, because a version change there can alter the structure of llms.txt and llms-full.txt, which are consumed by AI coding tools rather than by people. A fork that tracks upstream will spend its time on merge conflicts in docs/ and regenerated output, not on code. If you only need the published site, read adk.dev and skip the fork.

## Conclusion

Adopt google/adk-docs if you need to fix or extend the ADK documentation itself, or if you want the docs served from your own infrastructure. Do not clone it hoping to get the ADK runtime; the Python, TypeScript, Go, Java and Kotlin packages live on their own registries, and the README links to per-language get-started pages on adk.dev. Before opening a pull request, verify the exact mkdocs-material and mkdocs-llmstxt pins in requirements.txt still match what CI installs, because the llms.txt outputs are generated rather than hand-edited and a version drift there will show up as a diff in files you did not touch.

## FAQ

### What does ADK stand for?

Agent Development Kit. The README uses the full name and describes it as an open-source, code-first toolkit for building, evaluating and deploying AI agents.

### What is Google ADK used for?

It is used to develop and deploy AI agents. The README lists code-first development, a tool ecosystem, modular multi-agent systems, tracing and monitoring, and deployment to Cloud Run, GKE or Agent Runtime.

### Where can I find documentation for Google ADK?

The documentation is published at adk.dev, and this repository, google/adk-docs, is the source that builds it. The README also links llms.txt and llms-full.txt for AI coding tools.

### What is the difference between an SDK and an ADK?

The README does not draw that distinction. It describes ADK as a toolkit for developing and deploying AI agents and points readers to per-language get-started guides rather than comparing it to an SDK.

## Sources

- [Official documentation](https://adk.dev)
- [Official README](https://github.com/google/adk-docs#readme)
- [Project repository](https://github.com/google/adk-docs)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-adk-docs