mcp

update_cluster

DestructiveIdempotent

Updates a specific GKE cluster.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Required. The name (project, location, cluster) of the cluster to update. Specified in the format `projects//locations//clusters/*`.
`update`	Yes	Required. A description of the update represented as a string using JSON format. The full update request object can be found at https://cloud.google.com/container-engine/reference/rest/v1/projects.locations.clusters/update https://docs.cloud.google.com/kubernetes-engine/docs/reference/rest/v1/ClusterUpdate

Output Schema

TableJSON Schema

Name	Required	Description	Default
`errors`	No	Errors encountered during the operation.
`operation`	No	JSON string of the GKE Operation object. See: https://docs.cloud.google.com/kubernetes-engine/docs/reference/rest/v1/projects.locations.operations

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedApr 19, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds no behavioral context beyond 'updates'. It doesn't disclose what kind of updates are supported, potential side effects, or required permissions. The description simply restates the annotation's implication without additional value.

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 a single concise sentence, front-loaded with the main verb and resource. It avoids unnecessary words, but is perhaps too terse to be fully informative. Still, it earns its place as a minimal description.

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

Completeness2/5

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

Given the tool's complexity (updating a GKE cluster with a JSON update object) and the presence of annotations and output schema, the description is too minimal. It doesn't explain what can be updated, how the 'update' string should be structured, or any caution about destructiveness. The agent must rely entirely on external references in the 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%, with both parameters having detailed descriptions (e.g., 'name' format and 'update' JSON format). The tool description itself adds no extra parameter meaning, so the baseline of 3 applies because the schema fully carries the parameter semantics.

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 'Updates a specific GKE cluster' clearly identifies the verb (updates) and resource (GKE cluster). It distinguishes from sibling tools like create_cluster or delete_k8s_resource, though it doesn't explicitly differentiate from update_node_pool beyond the resource type.

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 provided on when to use this tool versus alternatives (e.g., update_node_pool for node pool changes). It doesn't mention prerequisites, common use cases, or exclusions, leaving the agent without context for tool selection.

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

All mcp tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct resource and action, with clear separation between GKE cluster management (create/get/update/list clusters, node pools, operations) and Kubernetes resource operations (apply/get/patch/delete/describe, etc.). Even potentially similar tools like get_k8s_resource and describe_k8s_resource have distinct purposes, and descriptions clarify any ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case. GKE operations use cluster/node_pool/operation nouns, while in-cluster operations consistently use the k8s_ prefix (e.g., get_k8s_resource, describe_k8s_resource). The naming is predictable and uniform across the entire set.

Tool Count4/5

At 23 tools, the server is slightly above the typical well-scoped range (3-15), but it covers two related domains: GKE cluster lifecycle and Kubernetes resource management. Each tool has a clear purpose, so the count feels justified rather than excessive. It is a comprehensive suite for a GKE-focused server.

Completeness3/5

The Kubernetes resource operations are fairly complete (apply, get, describe, patch, delete, logs, events, etc.). However, the GKE cluster management side lacks delete operations for clusters and node pools. There are create/update/get/list, but no delete_cluster or delete_node_pool, which are essential lifecycle operations. This is a notable gap that agents would need to work around.

Resources

Need Help?