Skip to main content
Glama
G-Core
by G-Core

cloud_insts_new

Create a cloud instance with specified flavor, network interfaces, and volumes. Configure user data, password, SSH keys, and placement policies for Linux or Windows.

Instructions

Create an instance with specified configuration.

How to get access:

For Linux,

  • Use the user_data field to provide a cloud-init script in base64 to apply configurations to the instance.

  • Specify the username and password to create a new user.

  • When only password is provided, it is set as the password for the default user of the image.

  • The user_data is ignored when the password is specified.

For Windows,

  • Use the user_data field to provide a cloudbase-init script in base64 to create new users on Windows.

  • Use the password field to set the password for the 'Admin' user on Windows.

  • The password of the Admin user cannot be updated via user_data.

  • The username cannot be specified in the request.

Args: project_id: Project ID

region_id: Region ID

flavor: The flavor of the instance.

interfaces: A list of network interfaces for the instance. You can create one or more interfaces - private, public, or both.

volumes: List of volumes that will be attached to the instance.

allow_app_ports: Set to true if creating the instance from an apptemplate. This allows application ports in the security group for instances created from a marketplace application template.

configuration: Parameters for the application template if creating the instance from an apptemplate.

name: Instance name.

name_template: If you want the instance name to be automatically generated based on IP addresses, you can provide a name template instead of specifying the name manually. The template should include a placeholder that will be replaced during provisioning. Supported placeholders are: {ip_octets} (last 3 octets of the IP), {two_ip_octets}, and {one_ip_octet}.

password: For Linux instances, 'username' and 'password' are used to create a new user. When only 'password' is provided, it is set as the password for the default user of the image. For Windows instances, 'username' cannot be specified. Use the 'password' field to set the password for the 'Admin' user on Windows. Use the 'user_data' field to provide a script to create new users on Windows. The password of the Admin user cannot be updated via 'user_data'.

security_groups: Specifies security group UUIDs to be applied to all instance network interfaces.

servergroup_id: Placement group ID for instance placement policy.

  Supported group types:

  - `anti-affinity`: Ensures instances are placed on different hosts for high
    availability.
  - `affinity`: Places instances on the same host for low-latency communication.
  - `soft-anti-affinity`: Tries to place instances on different hosts but allows
    sharing if needed.

ssh_key_name: Specifies the name of the SSH keypair, created via the /v1/ssh_keys endpoint.

tags: Key-value tags to associate with the resource. A tag is a key-value pair that can be associated with a resource, enabling efficient filtering and grouping for better organization and management. Some tags are read-only and cannot be modified by the user. Tags are also integrated with cost reports, allowing cost data to be filtered based on tag keys or values.

user_data: String in base64 format. For Linux instances, 'user_data' is ignored when 'password' field is provided. For Windows instances, Admin user password is set by 'password' field and cannot be updated via 'user_data'. Examples of the user_data: https://cloudinit.readthedocs.io/en/latest/topics/examples.html

username: For Linux instances, 'username' and 'password' are used to create a new user. For Windows instances, 'username' cannot be specified. Use 'password' field to set the password for the 'Admin' user on Windows.

extra_headers: Send extra headers

extra_query: Add additional query parameters to the request

extra_body: Add additional JSON properties to the request

timeout: Override the client-level default timeout for this request, in seconds

Note: Pass the numeric project_id. When a project name is provided, resolve it via cloud.projects.list/cloud.projects.get. If nothing is specified, fetch the account's default project first and use that ID. Pass the numeric region_id. Resolve region names with cloud.regions.list or cloud.regions.get. If no region is mentioned, obtain the default region ID before calling this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
region_idYes
flavorYes
interfacesYes
volumesYes
allow_app_portsNo
configurationNo
nameNo
name_templateNo
passwordNo
security_groupsNo
servergroup_idNo
ssh_key_nameNo
tagsNo
user_dataNo
usernameNo
extra_headersNo
extra_queryNo
extra_bodyNo
timeoutNo
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 explains parameter interactions (e.g., user_data vs password, name_template placeholders) and platform-specific behavior. It lacks information about failure modes, rate limits, or authentication needs, but the depth of explanation compensates.

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 verbose and contains repetition (e.g., password and user_data details appear both in the how-to section and parameter descriptions). While structured with headings and bullet-like args, it could be more concise without losing clarity.

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 20 parameters, no output schema, and no annotations, the description is fairly complete. It explains most parameters, covers edge cases, and provides resolution hints for project/region IDs. However, it omits a description of the return value and any prerequisites beyond parameter resolution.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all parameters. It does so extensively, often with conditional logic (Linux/Windows), examples (e.g., servergroup_id types), and cross-references (e.g., ssh_key_name via /v1/ssh_keys endpoint). This adds significant meaning beyond the schema's type definitions.

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 starts with 'Create an instance with specified configuration,' clearly stating the verb (create) and resource (instance). This distinguishes it from sibling tools like cloud_insts_ls (list), cloud_insts_del (delete), and cloud_insts_upd (update).

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

Usage Guidelines4/5

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

The description provides detailed guidance on parameter usage for Linux vs Windows, including inter-parameter dependencies (e.g., user_data ignored when password provided). It also advises resolving project_id and region_id using other tools. However, it does not explicitly state when not to use this tool or list alternatives for specific cases.

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

Install Server

Other Tools

Latest Blog Posts

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/G-Core/gcore-mcp-server'

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