Which integrations are available for this server?

Provides access to Google Cloud Platform documentation through search and content extraction tools, supporting 20+ GCP products including Compute Engine, Cloud Storage, BigQuery, GKE, Cloud Functions, and more. Enables querying documentation with natural language, fetching specific documentation pages, listing supported products, and accessing REST API references.

How do I use Google Cloud Docs MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Cloud Docs MCP Server how to set up a Cloud Storage bucket with CMEK encryption" 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.

Google Cloud Docs MCP Server

by longngo192

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Google Cloud Docs MCP Server

License: MIT Node.js Version MCP SDK

An MCP (Model Context Protocol) server that provides AI assistants with access to Google Cloud Platform documentation. This enables Claude and other MCP-compatible assistants to search, fetch, and understand GCP documentation in real-time.

Related MCP server: GCP MCP

Features

Free-form Search: Search GCP documentation with natural language queries
Content Extraction: Extract clean markdown content from documentation pages
80+ Topic Mappings: Pre-configured mappings for common GCP topics
Relevance Scoring: Smart ranking of search results by relevance
API Reference: Access REST API documentation for GCP services
20+ GCP Products: Support for major Google Cloud services

How It Works

┌─────────────┐     ┌─────────────────┐     ┌──────────────────┐
│   Claude    │────▶│  MCP Server     │────▶│  Google Cloud    │
│  (or other  │     │  (this project) │     │  Documentation   │
│  MCP client)│◀────│                 │◀────│  (cloud.google   │
└─────────────┘     └─────────────────┘     │   .com/docs)     │
                                           └──────────────────┘

Query Processing: When Claude receives a GCP-related question, it calls the MCP server tools
Search Strategy: The server uses a multi-step search approach:
- Google Search targeting site:cloud.google.com
- Google Cloud's internal search API (fallback)
- 80+ pre-configured topic mappings (fallback)
Content Extraction: Uses Cheerio to parse HTML and extract clean markdown
Relevance Scoring: Results are scored and sorted by query relevance
Response: Returns structured JSON with documentation content

Technical Details

Protocol: MCP (Model Context Protocol) over stdio transport
Content Parsing: HTML to Markdown conversion with Cheerio
Search: Combines Google Search scraping with fallback topic mappings
Output Format: Structured JSON with markdown content

Prerequisites

Node.js >= 18.0.0
npm or yarn
Claude Desktop, Claude Code, or other MCP-compatible client

Installation

From Source

# Clone the repository
git clone https://github.com/longngo192/gcpdoc-mcp
cd gcpdoc-mcp

# Install dependencies
npm install

# Build the project
npm run build

Quick Start

npm install && npm run build

Configuration

Claude Desktop

Add to your Claude Desktop config file:

Windows: %APPDATA%\Claude\claude_desktop_config.json macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "google-cloud-docs": {
      "command": "node",
      "args": [
        "/path/to/google-cloud-docs-mcp/dist/index.js"
      ]
    }
  }
}

Claude Code CLI

# Add the MCP server
claude mcp add google-cloud-docs -- node /path/to/dist/index.js

# Verify installation
claude mcp list

Usage

Once configured, Claude will automatically use the GCP documentation tools when you ask questions about Google Cloud services.

Example Queries

"How do I set up VPC peering between two GCP projects?"
"What are the steps to enable CMEK encryption for Cloud Storage?"
"How to configure Cloud SQL high availability?"
"Show me GKE autoscaling configuration options"
"How to set environment variables in Cloud Run?"

Direct Tool Usage

If using MCP protocol directly:

// Search documentation
{
  "method": "tools/call",
  "params": {
    "name": "search_google_cloud_docs",
    "arguments": {
      "query": "vpc peering between projects"
    }
  }
}

// Fetch specific documentation
{
  "method": "tools/call",
  "params": {
    "name": "fetch_google_cloud_doc",
    "arguments": {
      "path": "vpc/docs/vpc-peering"
    }
  }
}

Available Tools

1. `search_google_cloud_docs`

Search GCP documentation with free-form queries. Primary tool for GCP questions.

Parameter	Type	Required	Description
`query`	string	Yes	Natural language search query
`product`	string	No	Filter by GCP product (e.g., 'compute', 'storage')

Example:

{
  "query": "how to share encrypted bucket cross account",
  "product": "storage"
}

2. `fetch_google_cloud_doc`

Fetch content from a specific documentation page.

Parameter	Type	Required	Description
`path`	string	Yes	Documentation path after `cloud.google.com/`

Example:

{
  "path": "storage/docs/encryption/customer-managed-keys"
}

3. `list_google_cloud_products`

List all supported GCP products and their documentation paths.

No parameters required.

4. `get_api_reference`

Get REST API reference for a GCP service.

Parameter	Type	Required	Description
`service`	string	Yes	Service name (e.g., 'compute', 'storage')
`resource`	string	No	Specific API resource (e.g., 'instances', 'buckets')

Example:

{
  "service": "compute",
  "resource": "instances"
}

Supported Topics

The server includes 80+ topic mappings for accurate search results:

Category	Topics
Storage & Encryption	encrypt, bucket, cmek, kms, customer managed, object storage
IAM & Security	iam, role, service account, impersonation, workload identity
Networking	vpc, peering, shared vpc, firewall, load balancer, dns, nat
Database	cloud sql, high availability, mysql, postgres, replica, failover
BigQuery	partition, cluster, materialized view, schedule
GKE	gke, autoscaling, node pool, horizontal pod autoscaler, helm
Serverless	cloud run, environment variable, cloud function, deploy
Container	docker, artifact registry, cloud build
Pub/Sub	pubsub, topic, subscription
Data Processing	dataflow, dataproc, composer, airflow, spark
Monitoring	logging, monitoring, metric, alert, dashboard, trace
Infrastructure	terraform, deployment manager, gcloud

Supported GCP Products

ID	Name	Description
`compute`	Compute Engine	Virtual machines and infrastructure
`storage`	Cloud Storage	Object storage service
`bigquery`	BigQuery	Data warehouse and analytics
`kubernetes`	GKE	Managed Kubernetes service
`functions`	Cloud Functions	Serverless compute platform
`run`	Cloud Run	Serverless containers
`pubsub`	Pub/Sub	Messaging and event ingestion
`sql`	Cloud SQL	Managed relational databases
`firestore`	Firestore	NoSQL document database
`spanner`	Cloud Spanner	Globally distributed database
`ai`	Vertex AI	Machine learning platform
`iam`	IAM	Identity and Access Management
`vpc`	VPC	Virtual Private Cloud networking
`loadbalancing`	Cloud Load Balancing	Global load balancing
`logging`	Cloud Logging	Log management and analysis
`monitoring`	Cloud Monitoring	Infrastructure monitoring

Project Structure

google-cloud-docs-mcp/
├── src/
│   └── index.ts          # Main MCP server implementation
├── dist/                  # Compiled JavaScript (generated)
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
├── .gitignore           # Git ignore rules
├── LICENSE              # MIT License
└── README.md            # This file

Development

Running in Development Mode

# With hot reload
npm run dev

# Build and run
npm run build && npm start

Testing the Server

# Test MCP initialization
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' | node dist/index.js

# Test tools/list
echo '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' | node dist/index.js

Building

npm run build

Contributing

Contributions are welcome! Here's how you can help:

Getting Started

Fork the repository
Clone your fork: git clone https://github.com/yourusername/google-cloud-docs-mcp.git
Create a feature branch: git checkout -b feature/your-feature-name
Make your changes
Run tests and build: npm run build
Commit your changes: git commit -m "Add your feature"
Push to your fork: git push origin feature/your-feature-name
Open a Pull Request

Contribution Ideas

Add more topic mappings: Expand the topicMappings object in src/index.ts
Support more GCP products: Add entries to GOOGLE_CLOUD_PRODUCTS
Improve content extraction: Enhance the Cheerio parsing logic
Add caching: Implement response caching to reduce API calls
Add tests: Write unit tests for search and content extraction
Documentation: Improve README or add usage examples

Code Style

Use TypeScript
Follow existing code patterns
Add comments for complex logic
Test your changes before submitting

Reporting Issues

Found a bug or have a suggestion? Please open an issue with:

Clear description of the problem
Steps to reproduce
Expected vs actual behavior
Your environment (Node.js version, OS)

Acknowledgments

Model Context Protocol - The protocol that enables AI-tool communication
Cheerio - Fast HTML parsing
Google Cloud Documentation - The source of all documentation

License

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

Made with love for the GCP and AI community

Available Tools

4 tools

fetch_google_cloud_docA

Fetch and extract content from a specific Google Cloud documentation page.

WHEN TO USE: Use this tool when you already know the exact documentation path you need, or when you want to get detailed content from a specific GCP documentation page.

INPUT: Documentation path after cloud.google.com/ (e.g., 'compute/docs/instances/create-start-instance', 'storage/docs/creating-buckets')

OUTPUT: Returns JSON with:

title: Page title
url: Full URL
content: Markdown-formatted documentation content (max 20,000 chars)
contentLength: Total content length
truncated: Whether content was truncated

COMMON PATHS:

Compute: compute/docs/instances/create-start-instance
Storage: storage/docs/creating-buckets, storage/docs/encryption
BigQuery: bigquery/docs/partitioned-tables, bigquery/docs/clustered-tables
Cloud SQL: sql/docs/high-availability, sql/docs/replication
GKE: kubernetes-engine/docs/how-to/cluster-autoscaler
IAM: iam/docs/understanding-roles, iam/docs/service-accounts
VPC: vpc/docs/vpc-peering, vpc/docs/shared-vpc
Cloud Run: run/docs/configuring/environment-variables

TIP: If you don't know the exact path, use 'search_google_cloud_docs' first to find relevant documentation.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	The documentation path after cloud.google.com/ (e.g., 'compute/docs/instances/create-start-instance', 'storage/docs/creating-buckets')

TDQS

A4.4/5.0

Behavior4/5

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 effectively describes the tool's behavior: it fetches and extracts content, returns JSON with specific fields, mentions content truncation at 20,000 chars, and provides common path examples. The only minor gap is it doesn't mention error handling or rate limits.

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 well-structured with clear sections (WHEN TO USE, INPUT, OUTPUT, COMMON PATHS, TIP) and front-loaded with the core purpose. While somewhat lengthy due to the examples, every section serves a purpose and there's minimal redundancy. The TIP section is particularly efficient.

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

Completeness5/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 annotations and no output schema, the description provides excellent completeness. It explains the tool's purpose, when to use it, input format, detailed output structure with field descriptions, practical examples, and guidance on alternatives. The output description effectively substitutes for a missing output schema.

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 fully documents the single 'path' parameter. The description repeats the parameter explanation in the INPUT section and provides extensive examples in COMMON PATHS, but doesn't add significant semantic value beyond what the schema provides. This meets the baseline for high schema coverage.

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 specific verbs ('fetch and extract content') and resource ('Google Cloud documentation page'). It distinguishes from sibling tools by specifying it's for exact documentation paths, unlike 'search_google_cloud_docs' for unknown paths or 'list_google_cloud_products' for product listings.

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

Usage Guidelines5/5

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

The description includes an explicit 'WHEN TO USE' section that provides clear guidance: use when you know the exact documentation path. It also explicitly names an alternative tool ('search_google_cloud_docs') for when you don't know the path, creating a complete usage framework.

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

get_api_referenceA

Get REST API reference documentation for a specific Google Cloud service.

WHEN TO USE: Use this tool when:

User needs API endpoints, methods, or parameters
User is developing integrations with GCP APIs
User asks about REST API for a specific GCP service
User needs to know available API resources for a service

INPUT:

service (required): GCP service name (compute, storage, bigquery, pubsub, sql, kubernetes, functions, run, iam)
resource (optional): Specific API resource (instances, buckets, datasets, topics, etc.)

SUPPORTED SERVICES & RESOURCES:

compute: instances, disks, networks, firewalls, images, machineTypes
storage: buckets, objects, notifications
bigquery: datasets, tables, jobs, routines
pubsub: topics, subscriptions, snapshots
sql: instances, databases, users, backupRuns
kubernetes: clusters, nodePools, operations
functions: functions, operations, locations
run: services, configurations, routes, revisions
iam: roles, serviceAccounts, policies

OUTPUT: Returns JSON with:

service: Service name
description: Service description
apiReferenceUrl: Full URL to API reference
availableResources: List of available resources for this service
documentation: Actual API documentation content (if available)

EXAMPLE USAGE:

Get Compute Engine API overview: service="compute"
Get Storage buckets API: service="storage", resource="buckets"
Get BigQuery datasets API: service="bigquery", resource="datasets"

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	The Google Cloud service name (e.g., 'compute', 'storage', 'bigquery', 'pubsub', 'sql', 'kubernetes', 'functions', 'run', 'iam')
`resource`	No	Optional: Specific API resource (e.g., 'instances', 'buckets', 'datasets', 'topics')

TDQS

A4.7/5.0

Behavior4/5

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 effectively describes what the tool returns (JSON with specific fields), provides examples of supported services and resources, and includes example usage patterns. It doesn't mention rate limits, authentication requirements, or error handling, but provides substantial behavioral context.

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 well-structured with clear sections (purpose, when to use, input, supported services, output, examples). Every sentence adds value, and the information is front-loaded with the core purpose followed by practical guidance. No wasted words or redundant information.

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

Completeness5/5

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

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description provides complete context. It explains what the tool does, when to use it, detailed parameter semantics, supported values, output structure, and example usage. This is comprehensive given the tool's complexity and available structured data.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by providing a comprehensive list of supported services and resources for each service, which goes beyond the schema's generic descriptions. It also clarifies the relationship between service and resource parameters through examples.

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 specific verb ('Get') and resource ('REST API reference documentation for a specific Google Cloud service'). It distinguishes from sibling tools by focusing specifically on API reference documentation rather than general documentation, product listings, or search.

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

Usage Guidelines5/5

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

The description includes an explicit 'WHEN TO USE' section with four specific scenarios for using this tool, providing clear guidance about when it's appropriate. It differentiates from siblings by focusing on API endpoints, methods, and parameters rather than general documentation needs.

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

list_google_cloud_productsA

List all available Google Cloud products with their documentation paths.

WHEN TO USE: Use this tool when:

User wants to see what GCP services are available
User is exploring GCP products
You need to find the correct product ID for other tools
User asks "what GCP services are there?" or similar

OUTPUT: Returns JSON with:

totalProducts: Number of products listed
products: Array of products with id, name, docsPath, docsUrl, description

PRODUCTS INCLUDED (20+):

Compute: compute, kubernetes, functions, run, appengine
Storage: storage, firestore, spanner
Database: sql, bigquery
AI/ML: ai (Vertex AI), vision, speech, translate
Networking: vpc, loadbalancing, cdn, dns
Security: iam, kms
Messaging: pubsub
Monitoring: logging, monitoring

TIP: Use the returned 'docsPath' with 'fetch_google_cloud_doc' to get detailed documentation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/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 behavioral traits such as the output format (JSON with specific fields) and the scope of products included (listing 20+ categories). However, it lacks details on potential limitations like rate limits, pagination, or freshness of data, which would be helpful for a comprehensive list tool.

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 well-structured with clear sections (purpose, usage, output, products included, tip), making it easy to scan. Each sentence adds value, such as explaining the output format, listing product categories, and linking to sibling tools. There is no redundant or verbose content, and the information is front-loaded with the core purpose.

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

Completeness5/5

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

Given the tool's complexity (listing products with no parameters) and lack of annotations or output schema, the description is complete. It covers purpose, usage guidelines, output details, product scope, and integration with other tools. This provides sufficient context for an AI agent to understand when and how to use this tool effectively.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose and usage. A baseline of 4 is applied as it compensates well for the lack of parameters by providing rich context elsewhere.

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 verb ('List') and resource ('all available Google Cloud products with their documentation paths'), making the purpose specific. It distinguishes from sibling tools like 'fetch_google_cloud_doc' by focusing on listing products rather than fetching documentation, and from 'search_google_cloud_docs' by being comprehensive rather than filtered.

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

Usage Guidelines5/5

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

The 'WHEN TO USE' section provides explicit guidance with multiple scenarios (e.g., user wants to see GCP services, exploring products, finding product IDs). It also mentions an alternative tool ('fetch_google_cloud_doc') in the TIP, clarifying when to use this vs. others. The examples of user queries further reinforce appropriate contexts.

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

search_google_cloud_docsA

Search Google Cloud documentation with any free-form query. Returns relevant documentation with actual content.

WHEN TO USE: ALWAYS use this tool when the user asks about Google Cloud Platform (GCP) services, configurations, best practices, or how-to questions. This is the PRIMARY tool for GCP-related queries.

TRIGGERS - Use this tool when user asks about:

Any GCP service (Compute Engine, Cloud Storage, BigQuery, Cloud SQL, GKE, Cloud Run, IAM, VPC, etc.)
Configuration questions ("how to configure...", "how to setup...")
Best practices for GCP services
Troubleshooting GCP issues
Cross-project or cross-account scenarios
Security, encryption, permissions in GCP
Networking in GCP (VPC, peering, firewall, load balancer)
Database configurations (Cloud SQL HA, replicas, backups)
Container orchestration (GKE autoscaling, node pools)
Serverless (Cloud Run, Cloud Functions environment variables)

INPUT:

query (required): Free-form search query in natural language
product (optional): Filter by specific GCP product

EXAMPLE QUERIES:

"how to share encrypted bucket cross account"
"vpc peering between two projects"
"cloud sql high availability setup"
"gke autoscaling configuration"
"bigquery partition table"
"cloud run environment variables"
"iam service account impersonation"
"cloud storage cmek encryption"
"gke workload identity"

OUTPUT: Returns JSON with:

query: Original search query
totalResults: Number of results found
results: Array of top 3 docs with full content (title, url, content)
otherRelatedDocs: Additional related documentation URLs

SUPPORTED TOPICS (80+ mappings):

Storage & Encryption: encrypt, bucket, cmek, kms, customer managed, object storage
IAM & Security: iam, role, service account, impersonation, workload identity
Networking: vpc, peering, shared vpc, firewall, load balancer, dns, nat, private access
Database: cloud sql, high availability, mysql, postgres, replica, failover
BigQuery: partition, cluster, materialized view, schedule
GKE: gke, autoscaling, node pool, horizontal pod autoscaler, helm
Serverless: cloud run, environment variable, cloud function, deploy
Container: docker, artifact registry, cloud build
Pub/Sub: pubsub, topic, subscription
Data Processing: dataflow, dataproc, composer, airflow, spark
Monitoring: logging, monitoring, metric, alert, dashboard, trace
Infrastructure: terraform, deployment manager, gcloud

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-form search query in natural language (e.g., 'how to share encrypted bucket cross account', 'vpc peering between projects', 'cloud sql high availability')
`product`	No	Optional: Filter by Google Cloud product (e.g., 'compute', 'storage', 'bigquery', 'kubernetes', 'sql', 'run')

TDQS

A4.2/5.0

Behavior4/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 behavioral traits: it returns 'actual content' (not just links), specifies the output format (JSON with fields like results array and otherRelatedDocs), mentions it returns 'top 3 docs' (implying ranking/limiting), and notes it handles 'free-form query in natural language'. However, it doesn't mention rate limits, authentication needs, or error handling, leaving some gaps for a search tool.

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

Conciseness3/5

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

The description is well-structured with sections (WHEN TO USE, TRIGGERS, INPUT, EXAMPLE QUERIES, OUTPUT, SUPPORTED TOPICS), but it is overly verbose. Sections like 'SUPPORTED TOPICS' with 80+ mappings and extensive trigger lists could be condensed, as some details (e.g., specific service names) are redundant with the clear usage guidelines. It front-loads key info but includes excessive examples that don't all earn their place.

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 tool's complexity (search with natural language queries) and lack of annotations/output schema, the description is mostly complete. It covers purpose, usage, parameters, output format, and examples. However, without an output schema, it should ideally explain return values more thoroughly (e.g., content format, pagination), and it misses some behavioral aspects like error cases or performance hints, leaving minor gaps.

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 both parameters (query and product) with examples. The description adds minimal value beyond the schema: it repeats that query is 'free-form search query in natural language' and product filters by 'specific GCP product', but doesn't provide additional syntax, format details, or constraints. This meets the baseline of 3 when schema does the heavy lifting.

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: 'Search Google Cloud documentation with any free-form query. Returns relevant documentation with actual content.' This specifies the verb (search), resource (Google Cloud documentation), and output (documentation with content). It distinguishes from sibling tools like 'fetch_google_cloud_doc' (likely fetches a specific doc) and 'get_api_reference' (focuses on API docs).

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

Usage Guidelines5/5

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

The description includes an explicit 'WHEN TO USE' section stating this is the 'PRIMARY tool for GCP-related queries' and should 'ALWAYS' be used for GCP topics. It provides extensive 'TRIGGERS' with specific examples (e.g., services, configuration questions, best practices) and 'SUPPORTED TOPICS' with 80+ mappings, clearly differentiating when to use this over alternatives like 'list_google_cloud_products' (which likely lists products without searching content).

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. Dates show when Glama detected each change.

4 tool updatesv1.0.0Jan 1, 2026
- First observedfetch_google_cloud_doc
- First observedget_api_reference
- First observedlist_google_cloud_products
- First observedsearch_google_cloud_docs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: fetch_google_cloud_doc retrieves specific documentation pages, get_api_reference provides API details, list_google_cloud_products enumerates available services, and search_google_cloud_docs performs general searches. The descriptions explicitly differentiate when to use each tool, preventing confusion.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a clear verb_noun structure (fetch_google_cloud_doc, get_api_reference, list_google_cloud_products, search_google_cloud_docs). The naming is uniform and predictable across the set, making it easy for agents to understand and select tools.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of accessing Google Cloud documentation and APIs. Each tool serves a unique function (fetching, searching, listing, and API reference), and the count is neither too sparse nor overwhelming, fitting typical MCP server ranges.

Completeness5/5

The tool set comprehensively covers the domain of Google Cloud documentation access: it supports fetching specific docs, searching broadly, listing products for exploration, and retrieving API references. There are no obvious gaps, as the tools enable agents to find, access, and understand GCP resources effectively.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

developer-tools A
goog.workspace-developer
Provides tools for searching Google Workspace documentation and much more.
Developer Tools Documentation Access Search
22
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,164
Google GKE A
com.googleapis.container
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
Cloud Platforms Virtualization Observability
232

Related MCP Servers

GCP MCP Server
Cloud Platforms Developer Tools Observability
enesbol
A
license
B
quality
D
maintenance
Enables AI assistants to interact with and manage Google Cloud Platform resources including Compute Engine, Cloud Run, Storage, BigQuery, and other GCP services through a standardized MCP interface.
Updated 10 months ago (2025-11-09 15:31 UTC)
1
6
MIT
GCP MCP
Cloud Platforms Agent Orchestration
RadiumGu
A
license
C
quality
D
maintenance
Enables AI assistants to interact with Google Cloud Platform resources through natural language queries. Supports querying and managing GCP services like Compute Engine, Cloud Storage, BigQuery, and more across multiple projects and regions.
Updated a year ago (2025-08-29 03:23 UTC)
9
9,698
MIT
Multi-Source Documentation MCP
Documentation Access Search
florinel-chis
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search and query documentation from multiple sources including Voiceflow and Claude Code, with full-text search, code examples retrieval, and step-by-step tutorials access.
Updated 10 months ago (2025-11-12 18:20 UTC)
1
MIT
Google AI Search MCP
Search RAG Systems Documentation Access
shariqriazz
A
license
Not graded
quality
B
maintenance
Provides AI-powered search and documentation tools using Google Vertex AI or Gemini API with real-time web search grounding, enabling technical queries, code analysis, documentation retrieval, and architecture recommendations to overcome LLM knowledge gaps.
Updated 25 days ago (2026-08-11 23:02 UTC)
58
6
MIT

Appeared in Searches

Information about Google Intuitive features or search suggestions

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/longngo192/gcpdoc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Google Cloud Docs MCP Server

Table of Contents

Features

How It Works

Technical Details

Prerequisites

Installation

From Source

Quick Start

Configuration

Claude Desktop

Claude Code CLI

Usage

Example Queries

Direct Tool Usage

Available Tools

1. search_google_cloud_docs

2. fetch_google_cloud_doc

3. list_google_cloud_products

4. get_api_reference

Supported Topics

Supported GCP Products

Project Structure

Development

Running in Development Mode

Testing the Server

Building

Contributing

Getting Started

Contribution Ideas

Code Style

Reporting Issues

Acknowledgments

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

1. `search_google_cloud_docs`

2. `fetch_google_cloud_doc`

3. `list_google_cloud_products`

4. `get_api_reference`