Which integrations are available for this server?

Provides examples of how to interact with the MCP server's HTTP transport using curl commands for initializing connections, making requests, and accessing server-sent events. Provides access to Google Cloud services including Logging, Spanner, Monitoring, and Cloud Trace. Enables querying logs, executing Spanner database queries, retrieving monitoring metrics, analyzing trace data, and discovering Google Cloud resources. Enables executing SQL queries on Spanner databases, listing databases and instances, retrieving schema information, and obtaining query execution metrics. Used for package management in the project, allowing installation of dependencies, building, and running the MCP server.

How do I use Google Cloud 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 MCP Server show me recent errors from the production logs" 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 MCP Server

by andyl25

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Google Cloud MCP Server

A Model Context Protocol (MCP) server for Google Cloud services including Logging, Spanner, Monitoring, and Cloud Trace.

Features

Google Cloud Logging: Query logs, list log entries, and search across different log sources
Google Cloud Spanner: Execute queries, list databases and instances, get schema information
Google Cloud Monitoring: Query metrics, list metric descriptors, get monitoring data
Google Cloud Trace: Retrieve trace data and analyze distributed system performance
Resource Discovery: Automatically discover and list available Google Cloud resources
Project Management: Tools for managing Google Cloud project settings

Related MCP server: Cloud Logging API Server

Transport Support

This server supports two transport modes:

1. Stdio Transport (Default)

The traditional MCP stdio transport for use with MCP clients like Claude Desktop.

2. HTTP Transport (New!)

A web-based HTTP transport implementing the MCP Streamable HTTP specification.

Installation

# Clone the repository
git clone <repository-url>
cd google-cloud-mcp

# Install dependencies
pnpm install

# Build the project
pnpm build

Configuration

Environment Variables

GOOGLE_APPLICATION_CREDENTIALS: Path to your Google Cloud service account key file
GOOGLE_CLOUD_PROJECT: Your default Google Cloud project ID
GOOGLE_CLIENT_EMAIL: Service account email (alternative to credentials file)
GOOGLE_PRIVATE_KEY: Service account private key (alternative to credentials file)
LAZY_AUTH: Set to 'false' to initialize auth immediately (default: 'true')
DEBUG: Set to 'true' for debug logging
MCP_TRANSPORT: Transport type - 'stdio' (default) or 'http'
MCP_HTTP_PORT: Port for HTTP transport (default: 3000)

Google Cloud Authentication

You can authenticate in several ways:

Service Account Key File (Recommended):

export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json

Environment Variables:

export GOOGLE_CLIENT_EMAIL=your-service-account@project.iam.gserviceaccount.com
export GOOGLE_PRIVATE_KEY="-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n"

Application Default Credentials: If running on Google Cloud, ADC will be used automatically.

Usage

Using Stdio Transport (Default)

# Start with stdio transport
pnpm start

# Or explicitly specify stdio
MCP_TRANSPORT=stdio pnpm start

Using HTTP Transport

# Start with HTTP transport
MCP_TRANSPORT=http pnpm start

# Or with custom port
MCP_TRANSPORT=http MCP_HTTP_PORT=8080 pnpm start

When using HTTP transport, the server will be available at:

MCP Endpoint: http://127.0.0.1:3000/mcp
Health Check: http://127.0.0.1:3000/health

HTTP Transport Features

The HTTP transport implements the MCP Streamable HTTP specification with:

Session Management: Automatic session ID assignment and tracking
Server-Sent Events (SSE): For real-time communication and server-initiated messages
Request/Response Handling: Proper JSON-RPC 2.0 message handling
Security: Origin validation to prevent DNS rebinding attacks
CORS Support: Cross-origin requests support for web applications
Connection Management: Automatic cleanup of stale connections

HTTP Transport Usage Examples

Initialize Connection

curl -X POST http://127.0.0.1:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": {
        "name": "test-client",
        "version": "1.0.0"
      }
    }
  }'

The response will include a Mcp-Session-Id header that should be used in subsequent requests.

Make Requests with Session

curl -X POST http://127.0.0.1:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Mcp-Session-Id: <session-id>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list",
    "params": {}
  }'

Server-Sent Events Stream

curl -X GET http://127.0.0.1:3000/mcp \
  -H "Accept: text/event-stream" \
  -H "Mcp-Session-Id: <session-id>"

Available Tools

Logging Tools

gcp-logging-query: Query Google Cloud Logs
gcp-logging-list-entries: List log entries with filters

Spanner Tools

gcp-spanner-execute-query: Execute SQL queries on Spanner databases
gcp-spanner-list-databases: List Spanner databases
gcp-spanner-list-instances: List Spanner instances
gcp-spanner-get-schema: Get database schema information
gcp-spanner-query-count: Get query execution metrics

Monitoring Tools

gcp-monitoring-query: Query monitoring metrics
gcp-monitoring-list-metrics: List available metric descriptors
gcp-monitoring-get-resource-metrics: Get metrics for specific resources

Trace Tools

get-trace: Retrieve trace data by trace ID
search-traces: Search for traces with filters
get-trace-summary: Get summary statistics for traces

Project Tools

gcp-get-project-info: Get current project information
gcp-list-enabled-services: List enabled APIs and services

Available Resources

Logging Resources

gcp://logging/logs/{logName}: Individual log resources
gcp://logging/entries: Recent log entries

Spanner Resources

gcp://spanner/instances: List of Spanner instances
gcp://spanner/databases/{instanceId}: Databases in an instance
gcp://spanner/schema/{instanceId}/{databaseId}: Database schema

Monitoring Resources

gcp://monitoring/metrics: Available monitoring metrics
gcp://monitoring/resources: Monitored resource types

Trace Resources

gcp://trace/traces: Recent trace data

Available Prompts

analyze-logs: Analyze log patterns and errors
query-optimization: Optimize Spanner queries
troubleshoot-performance: Troubleshoot application performance issues
security-analysis: Analyze security-related logs and traces

Development

# Install dependencies
pnpm install

# Run in development mode with stdio transport
pnpm dev

# Run in development mode with HTTP transport
MCP_TRANSPORT=http pnpm dev

# Build the project
pnpm build

# Run tests
pnpm test

# Lint the code
pnpm lint

# Format the code
pnpm format

Troubleshooting

Authentication Issues

Check your credentials:
```
gcloud auth application-default login
```
Verify service account permissions:
- Logging Viewer
- Spanner Database User
- Monitoring Viewer
- Cloud Trace User
Test authentication:
```
DEBUG=true pnpm start
```

HTTP Transport Issues

Port conflicts: If port 3000 is in use, specify a different port:
```
MCP_HTTP_PORT=8080 MCP_TRANSPORT=http pnpm start
```
CORS issues: The server only accepts requests from localhost, 127.0.0.1, and .local domains for security.
Session management: Make sure to include the Mcp-Session-Id header in requests after initialization.

Performance Issues

Enable lazy authentication:
```
LAZY_AUTH=true pnpm start
```
Reduce logging verbosity: Remove DEBUG=true from production environments.

Security Considerations

HTTP Transport Security

The server binds only to 127.0.0.1 (localhost) by default
Origin header validation prevents DNS rebinding attacks
Sessions are automatically cleaned up
Request timeouts prevent resource exhaustion

Google Cloud Security

Use service accounts with minimal required permissions
Regularly rotate service account keys
Monitor access logs for unusual activity
Use VPC-native clusters when possible

License

MIT License - see LICENSE file for details.

Available Tools

17 tools

execute-spanner-queryD

ParametersJSON Schema

Name	Required	Description
`sql`	Yes	The SQL query to execute
`instanceId`	No	Spanner instance ID (defaults to SPANNER_INSTANCE env var)
`databaseId`	No	Spanner database ID (defaults to SPANNER_DATABASE env var)
`params`	No	Query parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

find-traces-from-logsD

ParametersJSON Schema

Name	Required	Description
`projectId`	No	Optional Google Cloud project ID
`filter`	Yes	Filter for logs (e.g., "severity>=ERROR AND timestamp>"-1d"")
`limit`	No	Maximum number of logs to check

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-project-idD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get-traceD

ParametersJSON Schema

Name	Required	Description	Default
`traceId`	Yes	The trace ID to retrieve
`projectId`	No	Optional Google Cloud project ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-metric-typesD

ParametersJSON Schema

Name	Required	Description
`filter`	No	Simple search term (e.g., "spanner") or full filter expression (e.g., "metric.type = starts_with(\"spanner\")")
`pageSize`	No	Maximum number of metric types to return
`timeout`	No	Timeout in seconds for the request

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-spanner-databasesD

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	Yes	Spanner instance ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-spanner-instancesD

ParametersJSON Schema

Name	Required	Description	Default
`_dummy`	No	Not used, just to ensure parameter compatibility

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-spanner-tablesD

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	No	Spanner instance ID (defaults to SPANNER_INSTANCE env var)
`databaseId`	No	Spanner database ID (defaults to SPANNER_DATABASE env var)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list-tracesD

ParametersJSON Schema

Name	Required	Description
`projectId`	No	Optional Google Cloud project ID
`filter`	No	Optional filter for traces (e.g., "status.code != 0" for errors)
`limit`	No	Maximum number of traces to return
`startTime`	No	Start time in RFC3339 format (e.g., "2023-01-01T00:00:00Z") or relative time (e.g., "1h", "2d")

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

logs-time-rangeD

ParametersJSON Schema

Name	Required	Description
`startTime`	Yes	Start time in ISO format or relative time (e.g., "1h", "2d")
`endTime`	No	End time in ISO format (defaults to now)
`filter`	No	Additional filter criteria
`limit`	No	Maximum number of log entries to return

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

natural-language-metrics-queryD

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural language description of the query you want to execute
`startTime`	No	Start time in ISO format or relative time (e.g., "1h", "2d")
`endTime`	No	End time in ISO format (defaults to now)
`alignmentPeriod`	No	Alignment period (e.g., "60s", "300s")

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

natural-language-spanner-queryD

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Natural language description of the query you want to execute
`instanceId`	No	Spanner instance ID (defaults to SPANNER_INSTANCE env var)
`databaseId`	No	Spanner database ID (defaults to SPANNER_DATABASE env var)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

natural-language-trace-queryD

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Natural language query about traces (e.g., "Show me failed traces from the last hour")
`projectId`	No	Optional Google Cloud project ID

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

query-logsD

ParametersJSON Schema

Name	Required	Description	Default
`filter`	Yes	The filter to apply to logs
`limit`	No	Maximum number of log entries to return

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

query-metricsD

ParametersJSON Schema

Name	Required	Description
`filter`	Yes	The filter to apply to metrics
`startTime`	Yes	Start time in ISO format or relative time (e.g., "1h", "2d")
`endTime`	No	End time in ISO format (defaults to now)
`alignmentPeriod`	No	Alignment period (e.g., "60s", "300s")

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

set-project-idD

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	The Google Cloud project ID to set as default

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

spanner-query-countD

ParametersJSON Schema

Name	Required	Description	Default
`instanceId`	No	Spanner instance ID (optional, if not provided will show all instances)
`databaseId`	No	Spanner database ID (optional, if not provided will show all databases)
`queryType`	No	Type of queries to count (ALL, READ, QUERY)	ALL
`status`	No	Status of queries to count (ALL, OK, ERROR)	ALL
`startTime`	No	Start time for the query (e.g., "1h", "2d", "30m")	1h
`endTime`	No	End time for the query (defaults to now)
`alignmentPeriod`	No	Alignment period for aggregating data points (e.g., "60s", "5m", "1h")	60s

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

17 tool updatesAug 15, 2025
- First observedexecute-spanner-query
- First observedfind-traces-from-logs
- First observedget-project-id
- First observedget-trace
- First observedlist-metric-types
- First observedlist-spanner-databases
- First observedlist-spanner-instances
- First observedlist-spanner-tables
- First observedlist-traces
- First observedlogs-time-range
- First observednatural-language-metrics-query
- First observednatural-language-spanner-query
- First observednatural-language-trace-query
- First observedquery-logs
- First observedquery-metrics
- First observedset-project-id
- First observedspanner-query-count

Install Server

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

TDQS

D1.8/5.0

Disambiguation4/5

Most tools have distinct purposes targeting different Google Cloud services (Spanner, Cloud Trace, Cloud Monitoring, Cloud Logging), though some overlap exists between query tools like 'query-logs' and 'find-traces-from-logs' which might cause confusion. The natural language query tools for different services are clearly differentiated by their target domains.

Naming Consistency3/5

The naming follows a mostly consistent verb-noun pattern with hyphens, but there are inconsistencies: 'get-project-id' and 'set-project-id' use a different structure than others, and some tools use compound nouns (e.g., 'natural-language-metrics-query') while others are simpler. The overall pattern is readable but mixed.

Tool Count4/5

With 17 tools, the count is slightly high but reasonable for covering multiple Google Cloud services like Spanner, Trace, Logging, and Monitoring. It provides a comprehensive surface without being overwhelming, though it borders on the heavy side for a single server.

Completeness3/5

The tool set covers querying and listing operations for Spanner, Trace, Logging, and Monitoring, but lacks obvious CRUD operations (e.g., create/update/delete resources) and management functions. This creates gaps for full lifecycle management, though core query workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

Google Big Query A
com.googleapis.bigquery
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Databases Cloud Platforms Search
63
Google Compute Engine A
com.googleapis.compute
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
Cloud Platforms Virtualization Agent Orchestration
292
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
LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3

Related MCP Servers

Google Cloud MCP Server
Cloud Platforms Databases Monitoring
krzko
A
license
C
quality
D
maintenance
A Model Context Protocol server that connects to Google Cloud services, allowing users to query logs, interact with Spanner databases, and analyze Cloud Monitoring metrics through natural language interaction.
Updated 9 months ago (2025-12-15 02:23 UTC)
40
54
82
Apache 2.0
Cloud Logging API Server
Observability Cloud Platforms
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP server that enables interaction with Google Cloud Logging API, allowing users to write, read, and manage log entries and configurations through natural language.
Updated a year ago (2025-07-16 13:59 UTC)
-
Cloud Monitoring API Server
Cloud Platforms Monitoring
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP server that provides access to Google Cloud Monitoring API, enabling interaction with cloud resources monitoring data through natural language commands.
Updated a year ago (2025-07-16 14:00 UTC)
-
Resource Settings MCP Server
Cloud Platforms Developer Tools
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP Server that provides a natural language interface to Google Cloud Resource Settings API, enabling users to view and manage settings for Google Cloud resources through conversation.
Updated a year ago (2025-07-16 14:03 UTC)
-

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/andyl25/googlecloud-mcp'

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