Provides search capabilities for Google ADK documentation, allowing AI agents to query and retrieve relevant documentation chunks from the Accessory Development Kit.
Click on "Deploy 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., "@ADK MCP Server search ADK docs for battery optimization"
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.
An offline-first Model Context Protocol (MCP) server for querying Google ADK (Accessory Development Kit) documentation. This server uses LanceDB for vector search and FastMCP for the MCP interface, allowing AI models to access and understand ADK documentation.
Offline-first: All documentation and vector indices are stored locally.
Fast Search: Uses LanceDB and FastEmbed for efficient vector search.
MCP Integration: Compatible with any MCP-enabled client (like Claude Desktop).
Easy Deployment: Can be installed as a local tool using uv.
Related MCP server: MCP Local Context
Python 3.13 or higher
uv for dependency management and running.
Clone the repository:
git clone <repository-url>
cd adk-mcp-docsInstall dependencies:
make install
# or
uv syncBefore running the server, you need to build the vector index from the documentation.
make build-index
# or
uv run src/adk_mcp/builder.pyTo run the server in development mode with hot-reloading:
make run
# or
uv run fastmcp run src/adk_mcp/server.pyTo install the server as a local tool accessible via uvx:
make deploy-local
# or
uv tool install . --forceAfter installation, you can run the server using:
uvx adk-mcpFor VS Code (with compatible MCP extensions) or Antigravity, create a file at .vscode/mcp-servers.json with the following content:
{
"mcpServers": {
"adk-mcp": {
"command": "uvx",
"args": ["adk-mcp"]
}
}
}Open Cursor Settings.
Go to Features > MCP.
Click + Add Bot.
Set Name to adk-mcp.
Set Type to command.
Set Command to uvx adk-mcp.
Add the following to your claude_desktop_config.json:
{
"mcpServers": {
"adk-mcp": {
"command": "uvx",
"args": ["adk-mcp"]
}
}
}src/adk_mcp/: Source code for the MCP server.
builder.py: Script to build the LanceDB index.
server.py: FastMCP server implementation.
data/: Directory for storing the LanceDB index (generated).
data/: (Optional) Source documentation files (if not embedded in the package).
Makefile: Convenient shortcuts for common tasks.
pyproject.toml: Project metadata and dependencies.
The documentation is indexed using a context-aware chunking strategy to ensure high-quality search results:
Header-based Splitting: Files are split by H1, H2, and H3 headers.
Contextual Headers: Each chunk is prefixed with its hierarchical context (e.g., Context: Getting Started > Installation > Python).
Language Tab Handling: Special handling for documentation with language tabs (e.g., === "Python", === "Go"). Content within these tabs is indexed separately and tagged with the respective language.
Embeddings: Uses the BAAI/bge-small-en-v1.5 model for generating vector embeddings.
search_adkSearch the Google ADK documentation for relevant information.
Arguments:
query (string): The search query.
language (string): The programming language to filter by. Supported values: "python", "go", "java", or "all".
Returns:
A formatted string containing the top 5 relevant chunks, including their source URLs and content.
Search the Google ADK documentation for relevant information.
Args: query: The search query. language: The programming language to filter by ("python", "go", "java", or "all").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| language | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the search requires authentication, what types of results are returned, or any limitations. The word 'search' implies read-only, but specific behaviors remain undisclosed.
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 concise and front-loaded, with the main purpose in the first sentence and a clean, structured argument list. Every sentence serves a purpose with no fluff.
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 search tool with two required parameters and an output schema, the description covers the essentials: what it does and how to specify parameters. It lacks usage guidelines and behavioral details, but the low complexity and existing output schema mitigate these gaps.
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 has no descriptions (0% coverage), so the description is essential. It clearly defines 'query' as the search query and 'language' as a filter with enumerated valid values ('python', 'go', 'java', 'all'), adding meaning beyond the bare schema.
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 searches Google ADK documentation for relevant information, using a specific verb and resource. However, without sibling tools to distinguish from, it cannot score 5 for sibling differentiation.
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?
No explicit guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description merely states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0search_adkScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clear and distinct, so disambiguation is not a concern.
The tool name 'search_adk' follows a clear verb_noun pattern, and with only one tool there are no inconsistencies. The naming is predictable and appropriate.
A single tool is on the borderline of being too thin, but for a documentation search server, it may be sufficient. However, it feels limited compared to typical MCP servers with a broader toolset.
The search tool covers the primary need of querying ADK documentation with language filtering. However, it lacks tools for retrieving full document content or browsing available topics, which are minor gaps.
An MCP server that gives your AI access to the source code and docs of all public github repos
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server for querying Forkast documentation
