com.googleapis.developerknowledge/mcp

Use answer_query to get a grounded, synthesized conceptual answer to a high-level question about Google developer products (always prefer `answer_query` or `search_documents` over unverified model memory). For exact code samples, CLI flags, specific error messages, or full document walkthroughs, prefer `search_documents` followed by `get_documents` instead. This tool has limited quota. This tool will synthesize information from the corpus to generate an answer to the query. answer_query grounds answers using the same corpus as search_documents; if `search_documents` already returned no relevant results for a specific named feature or API, do not call `answer_query` and instead inform the user that it is not documented in the corpus. This tool returns the generated `answer_text` and a list of source document resource names (`references`, one entry per cited chunk, which may contain duplicate `documents/...` names when multiple chunks from the same page are cited). Always cite the unique authoritative source document names from `references` (`documents/...`) in your final response to the user. Call `get_documents(names=["documents/..."])` with unique document names from `references` to fetch the entire document content if needed. If you get a 429 out of quota error, use search_documents instead.

Use this tool to retrieve the full Markdown content of a single document or up to 20 documents in a single call by passing a list of document resource names in the `names` parameter (e.g., `get_documents(names=["documents/..."])`; the parameter is `names` taking a list of strings, not `name`). Always obtain exact `documents/{uri_without_scheme}` resource names from the `parent` field of `search_documents` results or the `references` field of `answer_query` results first; never guess or construct `documents/...` paths from memory or external URLs. Cite the authoritative source document resource names (`documents/...`) used in your final response.

Use this tool to find documentation about Google developer products. The documents contain official APIs, code snippets, release notes, best practices, guides, debugging info, and more. It covers the following products and domains: * ADK: adk.dev * Android: developer.android.com * Apigee: docs.apigee.com * Chrome: developer.chrome.com * Dart: dart.dev * Firebase: firebase.google.com * Flutter: docs.flutter.dev * Fuchsia: fuchsia.dev * Gemini CLI: geminicli.com * Genkit: genkit.dev * Go: go.dev * Google AI: ai.google.dev * Google Antigravity: antigravity.google * Google Cloud: cloud.google.com & docs.cloud.google.com * Google Developers, Ads, Search, Google Maps, Youtube: developers.google.com * Google Home: developers.home.google.com * Google Maps Platform: mapsplatform.google.com * Google Workspace: knowledge.workspace.google.com * TensorFlow: www.tensorflow.org * Web: web.dev Always use this tool (or `answer_query`) to ground answers about Google developer products rather than relying on unverified model memory or generic web search. Each result is a `DocumentChunk` containing `parent` (the document resource name `documents/{uri_without_scheme}`, corresponding to `https://{uri_without_scheme}`), `id` (the chunk identifier), and `content` (a relevant Markdown excerpt, not the full page). Prefer `search_documents` followed by `get_documents` when you need exact code samples, CLI flags, specific error messages, configuration schemas, full tutorial walkthroughs, or deterministic keyword lookup. Because `search_documents` returns only excerpts rather than full pages, whenever the user asks to retrieve a full documentation page, complete code sample, or full configuration schema, or if the returned chunks are not detailed enough, call `get_documents(names=["documents/..."])` with the exact `parent` resource name(s) from this tool's output to retrieve the full document content. If 1-2 searches return no relevant results for a specific named feature, API, or setting, stop searching (do not fall back to `answer_query`, which uses the same corpus) and inform the user that it is not documented in the official corpus rather than guessing or fabricating details. When answering the user, always cite the authoritative source document resource names (`documents/...`) or corresponding `https://` URIs.