Google Compute Engine

get_instance_template_properties

Read-onlyIdempotent

Get instance properties of a Compute Engine instance template. This includes properties such as description, tags, machine type, network interfaces, disks, metadata, service accounts, scheduling options, labels, guest accelerators, reservation affinity, and shielded/confidential instance configurations. Requires project and instance template name as input.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	Required. Identifier. Name of the instance template to return.
`project`	Yes	Required. Project ID for this request.

Output Schema

TableJSON Schema

Name	Required	Description
`tags`	No	A list of tags to apply to the instances that are created from these properties. The tags identify valid sources or targets for network firewalls. The setTags method can modify this list of tags. Each tag within the list must comply with RFC1035 <https://www.ietf.org/rfc/rfc1035.txt>.
`disks`	No	An array of disks that are associated with the instances that are created from these properties.
`labels`	No	Labels to apply to instances that are created from these properties.
`metadata`	No	The metadata key/value pairs to assign to instances that are created from these properties. These pairs can consist of custom metadata or predefined keys. See Project and instance metadata </compute/docs/metadata#project_and_instance_metadata> for more information.
`scheduling`	No	Specifies the scheduling options for the instances that are created from these properties.
`description`	No	An optional text description for the instances that are created from these properties.
`machineType`	No	The machine type to use for instances that are created from these properties. This field only accepts a machine type name, for example `n2-standard-4`. If you use the machine type full or partial URL, for example `projects/my-l7ilb-project/zones/us-central1-a/machineTypes/n2-standard-4`, the request will result in an `INTERNAL_ERROR`.
`canIpForward`	No	Enables instances created based on these properties to send packets with source IP addresses other than their own and receive packets with destination IP addresses other than their own. If these instances will be used as an IP gateway or it will be set as the next-hop in a Route resource, specify true. If unsure, leave this set to false. See the Enable IP forwarding </vpc/docs/using-routes#canipforward> documentation for more information.
`minCpuPlatform`	No	Minimum cpu/platform to be used by instances. The instance may be scheduled on the specified or newer cpu/platform. Applicable values are the friendly names of CPU platforms, such as minCpuPlatform: "Intel Haswell" or minCpuPlatform: "Intel Sandy Bridge". For more information, read Specifying a Minimum CPU Platform </compute/docs/instances/specify-min-cpu-platform>.
`serviceAccounts`	No	A list of service accounts with specified scopes. Access tokens for these service accounts are available to the instances that are created from these properties. Use metadata queries to obtain the access tokens for these instances.
`resourcePolicies`	No	Resource policies (names, not URLs) applied to instances created from these properties. Note that for MachineImage, this is not supported yet.
`guestAccelerators`	No	A list of guest accelerator cards' type and count to use for instances created from these properties.
`networkInterfaces`	No	An array of network access configurations for this interface.
`reservationAffinity`	No	Specifies the reservations that instances can consume from. Note that for MachineImage, this is not supported yet.
`resourceManagerTags`	No	Input only. Resource manager tags to be bound to the instance. Tag keys and values have the same definition as resource manager tags <https://cloud.google.com/resource-manager/docs/tags/tags-overview>. Keys and values can be either in numeric format, such as `tagKeys/{tag_key_id}` and `tagValues/{tag_value_id}` or in namespaced format such as `{org_id\|project_id}/{tag_key_short_name}` and `{tag_value_short_name}`. The field is ignored (both PUT & PATCH) when empty.
`localSsdEncryptionMode`	No	Specifies which method should be used for encrypting the Local SSDs attached to the VM.
`shieldedInstanceConfig`	No	Note that for MachineImage, this is not supported yet.
`workloadIdentityConfig`	No
`advancedMachineFeatures`	No	Controls for advanced machine-related behavior features. Note that for MachineImage, this is not supported yet.
`keyRevocationActionType`	No	KeyRevocationActionType of the instance. Supported options are "STOP" and "NONE". The default value is "NONE" if it is not specified.
`privateIpv6GoogleAccess`	No	The private IPv6 google access type for VMs. If not specified, use INHERIT_FROM_SUBNETWORK as default. Note that for MachineImage, this is not supported yet.
`networkPerformanceConfig`	No	Note that for MachineImage, this is not supported yet.
`confidentialInstanceConfig`	No	Specifies the Confidential Instance options. Note that for MachineImage, this is not supported yet.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety and side-effect profile. The description adds the return content (list of properties) but does not disclose additional behavioral traits such as authentication requirements, rate limits, or any potential error conditions. While informative, it does not go beyond what annotations imply.

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: two sentences, with the action and resource front-loaded. The list of properties is useful and not overly verbose; it is directly relevant to the tool's purpose. It avoids unnecessary detail while providing a clear overview, making it efficient and structured.

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 presence of an output schema (per context signals), the description does not need to explain return formats. It covers the tool's scope, inputs, and output types, making it functionally complete for an agent to call correctly. The only missing element is explicit guidance on when to prefer this over get_instance_template_basic_info, which is a minor gap.

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%—both parameters (project and name) have descriptions. The description repeats this requirement without adding new semantic details, such as format constraints or special values. Since the schema already documents the parameters, the baseline is 3, and the description does not enhance it.

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 retrieves instance properties of a Compute Engine instance template and enumerates the specific properties covered (description, tags, machine type, network interfaces, etc.). This makes its purpose precise and distinct from the sibling get_instance_template_basic_info, which implies a subset of these properties. The verb and resource are explicit.

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 provides context by stating the required inputs (project and instance template name) and enumerates the returned properties, implying when to use it (when comprehensive properties are needed). However, it does not explicitly contrast with the alternative get_instance_template_basic_info or state when not to use this tool, leaving usage guidance mostly implied.

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

All Google Compute Engine 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.6/5.0

Disambiguation5/5

Each tool targets a distinct resource-action combination. For resources with both basic and detailed getters (reservations, templates), the suffixes clearly differentiate them, and list vs get distinctions are unambiguous. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_instance, list_disks, get_zone_operation). Getters consistently use descriptive suffixes like basic_info, details, or properties. No mixed naming conventions or vague verbs.

Tool Count4/5

29 tools is slightly above the ideal range but justified given the breadth of Google Compute Engine resources covered (instances, disks, templates, reservations, commitments, MIGs, snapshots, images, machine types, accelerator types). Each tool serves a specific purpose and contributes to the overall scope.

Completeness2/5

The toolset is heavily read-oriented. While instances have full lifecycle coverage (create, delete, start, stop, reset, set machine type), most other resources lack write operations: disks, templates, reservations, commitments, snapshots, and MIGs only have get/list tools. This creates dead ends for agents needing to create or modify these resources, which is a significant gap for a GCE management server.

Resources

Need Help?