This server provides search and retrieval tools for Google Gemini API documentation through an MCP (Model Context Protocol) interface.
Available Tools:
search_documentation: Performs keyword-based, full-text searches across all Gemini documentation pages using short queries (1-3 keywords maximum, max 3 queries at once)
get_capability_page: Retrieves the complete content of a specific documentation page by its exact title, or call without arguments to get a master list of all available page titles
get_current_model: Quickly accesses the dedicated "Gemini Models" documentation page with details about model variants (Pro, Flash, etc.), their capabilities, versioning, and context window sizes
Key Features:
Automatic documentation updates on server startup by scraping from ai.google.dev
Local SQLite database with FTS5 full-text search indexing for efficient querying and offline access
Supports Python and TypeScript SDK documentation
Provides tools for searching and retrieving Google Gemini API documentation, including full-text search across documentation pages, listing available capabilities, and accessing current model documentation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gemini Docs MCP Server search for how to use embeddings with Gemini"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A remote HTTP MCP server that provides tools to search and retrieve Google Gemini API documentation. The server exposes the MCP protocol at the /mcp endpoint and can be deployed to Cloud Run or other containerized platforms. It also supports local stdio mode for development.
Search Documentation: Full-text search across all Gemini documentation pages.
Get Capabilities: List available documentation pages or retrieve content for a specific page.
Get Current Model: Quickly access documentation for current Gemini models.
Automatic Updates: Scrapes and updates documentation on server startup.
sequenceDiagram
participant Client as MCP Client / IDE
participant Server as FastMCP Server
participant DB as SQLite Database
Client->>Server: call_tool("search_documentation", queries=["embeddings"])
Server->>DB: Full-Text Search for "embeddings"
DB-->>Server: Return matching documentation
Server-->>Client: Return formatted resultsIngestion: On startup, the server fetches https://ai.google.dev/gemini-api/docs/llms.txt to get a list of all available documentation pages.
Processing: It then concurrently fetches and processes each page, extracting the text content.
Indexing: The processed content is stored in a local SQLite database with a Full-Text Search (FTS5) index for efficient querying.
Searching: When you use the search_documentation tool, the server queries this SQLite database to find the most relevant documentation pages.
Related MCP server: Gemini Docs MCP Server
uvx (Recommended)You can use uvx to run the server directly without explicit installation. This is the easiest way to get started.
uvx --from git+https://github.com/philschmid/gemini-api-docs-mcp gemini-docs-mcpYou can install the package directly from GitHub using pip:
pip install git+https://github.com/philschmid/gemini-api-docs-mcp.gitgit clone https://github.com/philschmid/gemini-api-docs-mcp.git
cd gemini-api-docs-mcp
pip install -e .
cd ..
rm -rf gemini-api-docs-mcpThe server runs as an HTTP server and exposes the MCP protocol at the /mcp endpoint. It respects the PORT environment variable (defaults to 8080).
# Set port (optional, defaults to 8080)
export PORT=8080
# Run the server
gemini-docs-mcpThe server will be accessible at http://localhost:8080/mcp (or your configured port).
Build and run the Docker container:
# Build the image
docker build -t gemini-docs-mcp .
# Run the container
docker run -p 8080:8080 gemini-docs-mcpDeploy to Google Cloud Run:
# Build and deploy
gcloud run deploy gemini-docs-mcp \
--source . \
--platform managed \
--region us-central1 \
--allow-unauthenticatedThe server will be accessible at https://<your-service-url>/mcp.
If you don't set the PORT environment variable, the server runs in stdio mode for local MCP clients:
# Don't set PORT - runs in stdio mode
gemini-docs-mcpThe database is stored at:
/tmp/gemini-api-docs/database.db in containerized environments
~/.mcp/gemini-api-docs/database.db in local environments
You can override this by setting the GEMINI_DOCS_DB_PATH environment variable.
For remote HTTP servers, configure your MCP client to connect via HTTP:
{
"mcpServers": {
"gemini-docs": {
"url": "https://<your-service-url>/mcp"
}
}
}For local development with stdio (if supported by your client):
{
"mcpServers": {
"gemini-docs": {
"command": "gemini-docs-mcp"
}
}
}search_documentation(queries: list[str]): Performs a full-text search on Gemini documentation for the given list of queries (max 3).
get_capability_page(capability: str = None): Get a list of capabilities or content for a specific one.
get_current_model(): Get documentation for current Gemini models.
MIT
We run a comprehensive evaluation harness to ensure the MCP server provides accurate and up-to-date code examples. The tests cover both Python and TypeScript SDKs.
Metric | Value |
Total Tests | 117 |
Passed | 114 |
Failed | 3 |
Last updated: 2025-11-03 13:29:01
You can find the detailed test results in tests/result.json.
Retrieves the full content of a specific documentation page by its exact title. You can call can this tool WITHOUT arguments first to see a master list of all available page titles. Then, call it again with the exact title you need.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | The EXACT title of the documentation page to retrieve (case-sensitive). If you do not know the exact title, OMIT this argument to receive a master list of all available titles. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the calling pattern and that omitting the argument returns a list, but does not mention side effects, authentication, or data volume. Adequate but could be more detailed on what the output contains beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, usage pattern, and further instruction. No fluff, well-structured, and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the main use case and provides a clear workflow. Output format is not described but is covered by the output schema. Leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description. The description reiterates the schema's guidance on omitting the argument if title unknown, adding no new information beyond the schema. With high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Retrieves' and specific resource 'documentation page by exact title'. Distinguishes from sibling tools like search_documentation by focusing on exact title retrieval. The two-step usage pattern further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call without arguments (to get a list) and when to call with the exact title. Provides a clear usage workflow that guides the agent on optimal invocation order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortcut tool to explicitly retrieve the canonical 'Gemini Models' documentation page. Use this to fast-track finding details about available model variants (Pro, Flash, etc.), their capabilities, versioning, and context window sizes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description explains that the tool retrieves a documentation page, which implies read-only behavior. It adds context by calling it a 'shortcut tool' but does not disclose any additional behavioral traits like caching or network requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second gives usage advice. Every sentence is necessary and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema is present (context signal), and siblings provide contrast, the description is fairly complete. It covers the tool's purpose and what to expect. Minor omission: could mention if output is HTML or text, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (no params). The description adds meaning beyond the schema by explaining what the retrieved documentation page contains (model variants, capabilities, versioning).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the canonical 'Gemini Models' documentation page. It uses specific verbs and resource, and distinguishes from siblings like 'search_documentation' by calling itself a 'shortcut tool'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to fast-track finding details about available model variants...' which gives clear context for when to use. However, it does not explicitly state when not to use or mention alternatives beyond the implicit sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a standard keyword search on Gemini API documentation. CRITICAL: This is a naive keyword search, NOT semantic. Long queries will FAIL. You MUST use VERY SHORT keyword based queries (max 1-3 keywords) focusing only on the most unique terms. Break complex questions into separate, simple queries. It will return the full documentation page for a capability or feature.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of up to 3 SHORT keyword queries. Keep each query under 3 words. BAD: 'google genai python generate image save bytes' (too specific, will fail). GOOD: ['function calling', 'imagen parameters', 'save bytes'] (broad, likely to hit). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals that the search is naive keyword-based, that long queries fail, and that it returns full documentation pages. However, it does not mention response format, pagination, or what happens if no results are found, which are gaps for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and follows with critical usage warnings in capitals. It could be slightly more concise, but every sentence adds value and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers purpose, usage guidelines, and key behavioral traits. The tool is simple (1 parameter), and the description is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description for the 'queries' parameter, but the description adds critical context: limit to 1-3 keywords, focus on unique terms, break complex questions. This goes well beyond the schema, teaching effective usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a standard keyword search on Gemini API documentation, distinguishing it from siblings like get_capability_page (returns a specific page) and get_current_model (model info). The verb 'search' and resource 'documentation' are specific, and the mention of 'keyword search' differentiates it from semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use short keyword queries (1-3 words), avoid long queries, break complex questions into separate simple queries. It does not explicitly state when not to use this tool versus alternatives, but the context implies it's for keyword-based documentation lookup, not for retrieving specific pages or model details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct: get_capability_page retrieves any page by title (and can list all titles), get_current_model is a shortcut for the models page (overlapping with get_capability_page), and search_documentation does keyword search. The overlap between get_current_model and get_capability_page causes minor ambiguity.
All tools use snake_case and follow a verb_noun pattern (get_ or search_). The nouns are descriptive but not uniformly structured (capability_page vs current_model vs documentation). Naming is mostly consistent with minor variation.
Three tools is on the low side for a documentation server, but the tools are versatile: get_capability_page doubles as a list tool, and get_current_model is a convenience. The count feels thin but not severely inadequate.
The set covers key actions: listing pages, retrieving a specific page, searching. Minor gaps like missing page hierarchy or section-level navigation exist, but the ability to list all pages via get_capability_page without arguments mitigates the need for an explicit list tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provides tools for searching Google Workspace documentation and much more.
Provides access to Google's public developer documentation.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/philschmid/gemini-api-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
