Skip to main content
Glama
shariqriazz

Google AI Search MCP

by shariqriazz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Google AI Search MCP

Smithery

This project implements a Model Context Protocol (MCP) server that provides a comprehensive suite of Google AI-powered search and documentation tools specifically designed to help AI coders overcome LLM knowledge gaps and information limitations.

Implementation notes

Provider selection and credentials are resolved at runtime, so a tool being listed does not prove that its upstream provider is configured or reachable. Treat model-produced comparisons, architecture guidance, and security analysis as material to verify against the cited primary sources rather than deterministic findings.

For a source-linked comparison of the design pressures across this project and six other public MCP implementations, see What building seven MCP servers taught me about production MCP.

Related MCP server: Google Cloud Docs MCP Server

Features

  • Provides access to Google AI models (Vertex AI and Gemini API) via specialized MCP tools.

  • Focuses on real-time information retrieval and documentation-based analysis.

  • Supports web search grounding for current information that LLMs lack.

  • Configurable model ID, temperature, streaming behavior, max output tokens, and retry settings via environment variables.

  • Uses streaming API by default for potentially better responsiveness.

  • Includes basic retry logic for transient API errors.

  • Minimal safety filters applied (BLOCK_NONE) to reduce potential blocking (use with caution).

Tools Provided

Core Search & Documentation Tools

  • answer_query_websearch: Developer-focused natural language queries with automatic technical detection, enhanced search methodology, and comprehensive code formatting using Google AI with real-time search results.

  • explain_topic_with_docs: Streamlined technical explanations with improved debugging scenarios, synthesizing information from official documentation with reduced verbosity and enhanced troubleshooting guidance.

  • get_doc_snippets: Enhanced code snippet retrieval with progressive complexity examples, advanced search patterns, version-specific targeting, and comprehensive context for technical queries from official documentation.

  • generate_project_guidelines: Generates comprehensive structured project guidelines documents based on specified technologies, using web search for current best practices and industry standards.

Advanced Analysis Tools

  • code_analysis_with_docs: Evidence-based code analysis with standardized citations, severity categorization, and actionable recommendations by comparing code against official documentation best practices.

  • technical_comparison: Produces technology comparisons across requested criteria using current search context where available. Verify quantitative or market claims against the cited primary sources.

  • architecture_pattern_recommendation: Produces architecture options, tradeoffs, and implementation considerations for a described use case. Validate the recommendation against the system's actual constraints before adopting it.

(Note: Input/output schemas for each tool are defined in their respective files within src/tools/ and exposed via the MCP server.)

Prerequisites

  • Node.js (v18+)

  • Bun (npm install -g bun)

  • Google Cloud Project with Billing enabled (if using Vertex AI).

  • Vertex AI API enabled in the GCP project (if using Vertex AI).

  • Google Cloud Authentication configured in your environment (Application Default Credentials via gcloud auth application-default login is recommended, or a Service Account Key) OR Gemini API key.

Setup & Installation

  1. Clone/Place Project: Ensure the project files are in your desired location.

  2. Install Dependencies:

    bun install

  3. Configure Environment:

    • Create a .env file in the project root (copy .env.example).

    • Set the required and optional environment variables as described in .env.example.

      • Set AI_PROVIDER to either "vertex" or "gemini".

      • If AI_PROVIDER="vertex", GOOGLE_CLOUD_PROJECT is required.

      • If AI_PROVIDER="gemini", GEMINI_API_KEY is required.

  4. Build the Server:

    bun run build

    This compiles the TypeScript code to build/index.js.

Usage (Standalone / NPX)

The package is published to npm and can be run directly with npx:

# Ensure required environment variables are set (e.g., GOOGLE_CLOUD_PROJECT or GEMINI_API_KEY)
bunx google-ai-search-mcp

Alternatively, install it globally:

bun install -g google-ai-search-mcp
# Then run:
google-ai-search-mcp

Note: Running standalone requires setting necessary environment variables (like GOOGLE_CLOUD_PROJECT, GOOGLE_CLOUD_LOCATION, GEMINI_API_KEY, authentication credentials if not using ADC) in your shell environment before executing the command.

Docker

Build the local container image:

docker build -t google-ai-search-mcp .

Run with the Gemini API provider:

docker run --rm -i \
  -e AI_PROVIDER=gemini \
  -e GEMINI_API_KEY \
  google-ai-search-mcp

For Vertex AI, pass AI_PROVIDER=vertex, GOOGLE_CLOUD_PROJECT, and optionally GOOGLE_CLOUD_LOCATION. Application Default Credentials must also be available inside the container, normally through a read-only credential mount. Do not bake API keys or service-account files into the image.

Running with Cline

  1. Configure MCP Settings: Add/update the configuration in your Cline MCP settings file (e.g., .roo/mcp.json). You have two primary ways to configure the command:

    Option A: Using Node (Direct Path - Recommended for Development)

    This method uses node to run the compiled script directly. It's useful during development when you have the code cloned locally.

    {
  "mcpServers": {
    "google-ai-search-mcp": {
      "command": "node",
      "args": [
        "/full/path/to/your/google-ai-search-mcp/build/index.js" // Use absolute path or ensure it's relative to where Cline runs node
      ],
      "env": {
        // --- General AI Configuration ---
        "AI_PROVIDER": "vertex", // "vertex" or "gemini"
        // --- Required (Conditional) ---
        "GOOGLE_CLOUD_PROJECT": "YOUR_GCP_PROJECT_ID", // Required if AI_PROVIDER="vertex"
        // "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY", // Required if AI_PROVIDER="gemini"
        // --- Optional Model Selection ---
        "VERTEX_MODEL_ID": "gemini-2.5-pro", // If AI_PROVIDER="vertex" (Example override)
        "GEMINI_MODEL_ID": "gemini-2.5-pro", // If AI_PROVIDER="gemini"
        // --- Optional AI Parameters ---
        "GOOGLE_CLOUD_LOCATION": "us-central1", // Specific to Vertex AI
        "AI_TEMPERATURE": "0.0",
        "AI_USE_STREAMING": "true",
        "AI_MAX_OUTPUT_TOKENS": "65536", // Default from .env.example
        "AI_MAX_RETRIES": "3",
        "AI_RETRY_DELAY_MS": "1000",
        // --- Optional Vertex Authentication ---
        // "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/your/service-account-key.json" // If using Service Account Key for Vertex
      },
      "disabled": false,
      "alwaysAllow": [
         // Add tool names here if you don't want confirmation prompts
         // e.g., "answer_query_websearch"
      ],
      "timeout": 3600 // Optional: Timeout in seconds
    }
    // Add other servers here...
  }
}

    • Important: Ensure the args path points correctly to the build/index.js file. Using an absolute path might be more reliable.

    Option B: Using NPX (Requires Package Published to npm)

    This method uses npx to automatically download and run the server package from the npm registry. This is convenient if you don't want to clone the repository.

    {
  "mcpServers": {
    "google-ai-search-mcp": {
      "command": "bunx", // Use bunx
      "args": [
        "-y", // Auto-confirm installation
        "google-ai-search-mcp" // The npm package name
      ],
      "env": {
        // --- General AI Configuration ---
        "AI_PROVIDER": "vertex", // "vertex" or "gemini"
        // --- Required (Conditional) ---
        "GOOGLE_CLOUD_PROJECT": "YOUR_GCP_PROJECT_ID", // Required if AI_PROVIDER="vertex"
        // "GEMINI_API_KEY": "YOUR_GEMINI_API_KEY", // Required if AI_PROVIDER="gemini"
        // --- Optional Model Selection ---
        "VERTEX_MODEL_ID": "gemini-2.5-pro", // If AI_PROVIDER="vertex" (Example override)
        "GEMINI_MODEL_ID": "gemini-2.5-pro", // If AI_PROVIDER="gemini"
        // --- Optional AI Parameters ---
        "GOOGLE_CLOUD_LOCATION": "us-central1", // Specific to Vertex AI
        "AI_TEMPERATURE": "0.0",
        "AI_USE_STREAMING": "true",
        "AI_MAX_OUTPUT_TOKENS": "65536", // Default from .env.example
        "AI_MAX_RETRIES": "3",
        "AI_RETRY_DELAY_MS": "1000",
        // --- Optional Vertex Authentication ---
        // "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/your/service-account-key.json" // If using Service Account Key for Vertex
      },
      "disabled": false,
      "alwaysAllow": [
         // Add tool names here if you don't want confirmation prompts
         // e.g., "answer_query_websearch"
      ],
      "timeout": 3600 // Optional: Timeout in seconds
    }
    // Add other servers here...
  }
}

    • Ensure the environment variables in the env block are correctly set, either matching .env or explicitly defined here. Remove comments from the actual JSON file.

  2. Restart/Reload Cline: Cline should detect the configuration change and start the server.

  3. Use Tools: You can now use the comprehensive list of Google AI-powered search and documentation tools via Cline.

Development

  • Watch Mode: bun run watch

  • Build: bun run build

  • Inspector: bun run inspector

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

7 tools
answer_query_websearchB

Answers a natural language query using the configured Vertex AI model (gemini-2.5-pro) enhanced with Google Search results for up-to-date information. Requires a 'query' string.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe natural language question to answer using web search.

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the model name, the search enhancement, and the required input, which is meaningful. However, it omits behavioral traits such as external API dependence, potential latency of model+search calls, cost implications, or failure behavior if the search or model call errors out. Adequate but incomplete for a zero-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with the core purpose front-loaded. The second sentence ('Requires a query string') is slightly redundant with the schema but costs little. Overall efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema and no nested objects, the description is reasonably complete about what it does and its input. However, since there is no output schema, it could have described the expected output shape or the nature of the answer, and it gives no failure or freshness guidance for a tool that makes live web searches.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the single 'query' parameter fully ('The natural language question to answer using web search'). The description's mention of requiring a 'query' string adds nothing beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Answers') and resource (a natural language query via the Vertex AI gemini-2.5-pro model enhanced with Google Search). The web-search enhancement naturally distinguishes it from the doc-centric siblings (explain_topic_with_docs, get_doc_snippets, code_analysis_with_docs), though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to prefer this tool over its siblings or vice versa. Given the sibling set is heavily documentation/analysis-oriented, the description could have noted when web search is appropriate (e.g., current events, facts not in local docs) versus when doc-based tools are better. Nothing is stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

architecture_pattern_recommendationA

Suggests architecture patterns for specific use cases based on industry best practices. Provides implementation examples and considerations for the recommended patterns. Includes diagrams and explanations of pattern benefits and tradeoffs. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'requirements' and 'tech_stack'.

ParametersJSON Schema
NameRequiredDescriptionDefault
industryNoOptional. Industry or domain context (e.g., 'healthcare', 'finance', 'e-commerce').
tech_stackYesTechnologies to be used (e.g., ['Node.js', 'React', 'PostgreSQL']).
requirementsYesRequirements and constraints for the system.
existing_architectureNoOptional. Description of existing architecture if this is an evolution of an existing system.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool 'Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search', which is a significant behavioral trait, and mentions it 'Provides implementation examples and considerations' and 'Includes diagrams and explanations', giving output expectations. Since no annotations are provided, this description carries the transparency burden, and it covers key aspects, though it does not explicitly state that the tool is read-only or has no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It leads with the core purpose, then lists the outputs (examples, considerations, diagrams), and ends with the required parameters. Every sentence adds informative value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the nested schema and lack of output schema, the description provides a reasonable overview of what the tool delivers (examples, diagrams, tradeoffs). However, it does not detail the exact structure of the returned recommendation, and the absence of an output schema means the description could have been more explicit about the return format. Still, it covers the essential context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add extra semantic weight to parameters beyond what the schema already provides; it only repeats that 'requirements' and 'tech_stack' are required. No additional constraints, usage examples, or relationships between parameters are explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Suggests architecture patterns for specific use cases based on industry best practices.' This is a specific verb ('suggests') with a resource ('architecture patterns') and a clear differentiator from sibling tools like code_analysis_with_docs or technical_comparison, which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus sibling tools. It only mentions it 'Requires requirements and tech_stack', which is parameter guidance, not usage context. There is no mention of alternatives like 'use this for architectural decisions, not for code analysis' making the boundary ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

code_analysis_with_docsA

Analyzes code snippets by comparing them with best practices from official documentation found via web search. Identifies potential bugs, performance issues, and security vulnerabilities. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'code', 'language', and 'analysis_focus'.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe code snippet to analyze.
versionNoOptional. Specific version of the language or framework to target (e.g., 'ES2022', 'Python 3.11', 'React 18.2').
languageYesThe programming language of the code (e.g., 'JavaScript', 'Python', 'Java', 'TypeScript').
frameworkNoOptional. The framework or library the code uses (e.g., 'React', 'Django', 'Spring Boot').
analysis_focusYesAreas to focus the analysis on. Use 'all' to cover everything.

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It transparently discloses that it uses a Vertex AI model (gemini-2.5-pro) and Google Search, which implies network calls and external dependencies. However, it does not mention potential inaccuracies, rate limits, or that it is a read-only operation, though the 'analyzes' verb makes non-destructive behavior evident.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, covering the main purpose, analysis areas, and underlying technology in three sentences. However, the final sentence about required parameters is redundant because the schema already marks them as required, which slightly reduces efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description adequately explains what the tool does and its input requirements. It does not explicitly state the output format (e.g., a list of issues or a report), but for an analysis tool, the output is implicitly a descriptive analysis. The description is sufficient for an agent to decide when to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter details beyond the schema; it simply repeats the required parameters ('code', 'language', 'analysis_focus') without elaborating on their semantics or relationships. The 'analysis_focus' enum values are not explained in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Analyzes code snippets') and resource ('code snippets'), and it distinguishes itself from sibling tools by focusing on code analysis against official documentation. It uniquely identifies bug detection, performance, and security analysis, which no other sibling tool claims.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you have a code snippet and need analysis against best practices) but does not explicitly contrast it with alternatives like get_doc_snippets or explain_topic_with_docs. No when-not guidance is provided, so the usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_topic_with_docsA

Provides a detailed explanation for a query about a specific software topic by synthesizing information primarily from official documentation found via web search. Focuses on comprehensive answers, context, and adherence to documented details. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'topic' and 'query'.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe specific question to answer based on the documentation.
topicYesThe software/library/framework topic (e.g., 'React Router', 'Python requests').

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the transparency burden. It mentions that it uses web search and a Vertex AI model, which gives some insight into behavior, but it does not disclose potential limitations, latency, or that it performs no side effects. The description is neither misleading nor overly opaque, but it leaves some behavioral details unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two focused sentences. It front-loads the core purpose and then adds context about the source and model. There is no redundant or vague wording, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While there is no output schema, the description implies the return value ('detailed explanation'), which gives enough context for the agent to know what to expect. It does not detail output format or any additional response fields, but for an explanation tool the implicit textual output is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully covers both parameters (topic and query) with clear descriptions, so the coverage is 100%. The description adds no extra nuance beyond the schema, but the parameter meanings are already self-evident. The baseline of 3 is appropriate because no additional semantic information is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: providing a detailed explanation for a query about a specific software topic, with the scope of synthesizing information from official documentation. It distinguishes itself from sibling tools by emphasizing 'official documentation found via web search' and 'detailed explanation,' making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives implicit usage guidance by specifying that it focuses on comprehensive, doc-based answers and requires both a topic and a query. It does not explicitly contrast with every sibling tool, but the 'official documentation' and 'detailed explanation' keywords signal when this tool is more appropriate than a general web search or snippet retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_project_guidelinesA

Generates a structured project guidelines document (e.g., Markdown) based on a specified list of technologies and versions (tech stack). Uses web search to find the latest official documentation, style guides, and best practices for each component and synthesizes them into actionable rules and recommendations. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'tech_stack'.

ParametersJSON Schema
NameRequiredDescriptionDefault
tech_stackYesAn array of strings specifying the project's technologies and versions (e.g., ['React 18.3', 'TypeScript 5.2', 'Node.js 20.10', 'Express 5.0', 'PostgreSQL 16.1']).

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses that web search and the Vertex AI model (gemini-2.5-pro) are used, and that it synthesizes information. It does not mention potential latency or cost, but the key behavior is adequately described with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise, but it repeats 'Uses' twice and includes some redundancy (e.g., 'Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search' could be trimmed). Still, it is direct and not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must hint at the return value. It states that the output is a 'structured project guidelines document (e.g., Markdown)' containing 'actionable rules and recommendations,' which gives a sufficient mental model for the agent. Format details are not exhaustive but are adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes 'tech_stack' as an array of strings, so the baseline is 3. The description adds meaningful context by clarifying that it is a list of technologies and versions, provides an example, and states that it is required. This elevates it above mere schema repetition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: generating a structured project guidelines document based on a specified tech stack. It uses a specific verb ('Generates') and a specific resource ('project guidelines document'), and it is distinct from sibling tools like technical comparison or code analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when guidelines are needed for a tech stack) but does not explicitly contrast it with sibling tools or state when not to use it. No alternative tool is named, leaving the choice to the agent's inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_doc_snippetsB

Provides precise, authoritative code snippets or concise answers for technical queries by searching official documentation. Focuses on delivering exact solutions without unnecessary explanation. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'topic' and 'query'.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe specific question or use case to find a snippet or concise answer for.
topicYesThe software/library/framework topic (e.g., 'React Router', 'Python requests', 'PostgreSQL 14').
versionNoOptional. Specific version of the software to target (e.g., '6.4', '2.28.2'). If provided, only documentation for this version will be used.
include_examplesNoOptional. Whether to include additional usage examples beyond the primary snippet. Defaults to true.

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool uses the Vertex AI model (gemini-2.5-pro) with Google Search, which is useful behavioral context. However, it does not describe the output format, error behavior, or any limitations such as what happens if no documentation is found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loading the purpose and then adding focus and method. It is concise and free of fluff, though it could be slightly more structured with explicit sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description gives a general sense that snippets or answers are returned but does not detail the response structure or handle edge cases like no results. For a relatively simple tool with four parameters, this is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no new semantic information beyond restating that 'topic' and 'query' are required. This meets the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides code snippets or concise answers by searching official documentation, emphasizing precision and lack of unnecessary explanation. This distinguishes it from explanation-focused siblings like explain_topic_with_docs, though it does not explicitly name any alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for exact solutions without explanation, which gives a sense of when to use it, but it does not explicitly state when not to use it or name alternative tools like answer_query_websearch. The requirement for 'topic' and 'query' is stated but is redundant with the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

technical_comparisonA

Compares multiple technologies, frameworks, or libraries based on specific criteria. Provides detailed comparison tables with pros/cons and use cases. Includes version-specific information and compatibility considerations. Uses the configured Vertex AI model (gemini-2.5-pro) with Google Search. Requires 'technologies' and 'criteria'.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoOptional. Format of the comparison output.detailed
criteriaYesAspects to compare (e.g., ['performance', 'learning curve', 'ecosystem', 'enterprise adoption']).
use_caseNoOptional. Specific use case or project type to focus the comparison on.
technologiesYesArray of technologies to compare (e.g., ['React 18', 'Vue 3', 'Angular 15', 'Svelte 4']).

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool uses a configured Vertex AI model and Google Search, and indicates outputs like comparison tables and pros/cons. It does not mention side effects or limitations, but for a comparison tool none are obviously expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. It lists additional output details in short sentences. A few phrases ('Provides detailed comparison tables', 'Includes version-specific information') are slightly redundant but overall the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a solid overview of what the tool returns (comparison tables, pros/cons, use cases, version info, compatibility). Since there is no output schema, this helps set expectations. It could mention more about how the comparison is presented, but it is sufficient for a typical agent call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all four parameters thoroughly. The description adds minimal parameter-specific insight beyond restating that technologies and criteria are required. Since schema coverage is 100%, a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Compares') and identifies the subject (technologies, frameworks, libraries) and the key inputs (criteria). It is easily distinguished from sibling tools like answer_query_websearch or generate_project_guidelines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the required parameters ('Requires technologies and criteria') but does not explicitly explain when to use this tool versus alternatives such as architecture_pattern_recommendation or explain_topic_with_docs. It gives the basic usage condition but lacks comparative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updates
    • First observedanswer_query_websearch
    • First observedarchitecture_pattern_recommendation
    • First observedcode_analysis_with_docs
    • First observedexplain_topic_with_docs
    • First observedgenerate_project_guidelines
    • First observedget_doc_snippets
    • First observedtechnical_comparison
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 7 tools

Disambiguation4/5

Most tools have distinct purposes, but answer_query_websearch and explain_topic_with_docs overlap semantically enough that an agent may hesitate between them. The shared boilerplate descriptions also reduce clarity across several tools.

Naming Consistency3/5

Several tools follow a verb_object pattern, but code_analysis_with_docs, technical_comparison, and architecture_pattern_recommendation are noun-phrase names. This mixed convention is still readable but not consistently applied.

Tool Count5/5

Seven tools is a well-scoped count for a domain-specific AI search and documentation assistant. Each tool covers a meaningful high-level task without unnecessary redundancy or bloat.

Completeness4/5

The toolset covers Q&A, documentation explanation, snippets, code analysis, comparisons, architecture planning, and guideline generation. A raw search or retrieval tool is absent, but not a major gap given the AI-assisted focus.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches