Skip to main content
Glama

Get Deployable Server Models

get_deployable_server_models
Read-onlyIdempotent

Discover what infrastructure can be provisioned on this hub. Called with no arguments, it lists the enabled infrastructure-provider integrations. Pass 'providers' to also list the server models each offers — specs, datacenter locations, and estimated pricing — limited to one or two providers per call since some offer hundreds of models; narrow further with category, location, max_monthly_price_usd, and hypervisor_only. category matches each PROVIDER's own naming (values like 'bare-metal', 'general', 'high-frequency', 'high-performance', 'optimized-dedicated', 'vx1' — provider-specific, not a Cycle taxonomy), so list without it first and read the real categories off the results; a filter that matches nothing reports the categories that were actually available. To find hardware that can host virtual machines use hypervisor_only, NOT a category guess. Use it to answer questions like 'what infrastructure providers are enabled on my hub', 'what bare metal servers does offer', 'what servers are available under $50/mo', or 'which models can host virtual machines', and to verify a specific model and location exist before any server deployment is considered. All prices are estimates reported by the provider and are billed by that provider directly to the user's account there, not by Cycle. Read-only: this tool never provisions anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum models returned per provider, after sorting by estimated monthly price ascending. Default 50, max 200.
contextNoWhy are you calling this tool? Briefly describe the user's goal.
categoryNoOnly include models whose provider category (or class) matches. Case-insensitive substring match. Values are the PROVIDER's own category names and differ per provider (e.g. 'bare-metal', 'general', 'high-frequency', 'high-performance', 'optimized-dedicated', 'vx1') — they do not describe what a model can run, so do NOT filter on a guessed value like 'virtual-machine'. To find VM-capable hardware use hypervisor_only instead. Call without this filter first and read the categories back off the returned models.
locationNoOnly include models available in a matching provider location. Matches location ID, abbreviation, name, provider code, or geographic city/region/country (case-insensitive substring).
providersNoProvider integrations to list server models for. Each entry matches an integration by ID, identifier, name, or vendor (case-insensitive substring). Omit to just see which infrastructure-provider integrations are enabled. Limit to one or two providers per call — some offer hundreds of models.
conversation_idNoConversation tracking id. Omit on your first tool call; every result then includes a conversation_id line — pass that exact value on all later calls in this conversation.
hypervisor_onlyNoOnly include models that support virtual machines (hardware virtualization). Models whose provider does not report the capability are excluded. Default false.
include_incompatibleNoAlso include models marked incompatible with the Cycle platform. Default false.
max_monthly_price_usdNoOnly include models whose ESTIMATED monthly price is at or below this many US dollars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that prices are provider-reported estimates billed directly by the provider (not Cycle), that a non-matching filter reports the categories actually available, and that the tool never provisions anything. These are behavioral traits the annotations do not convey.

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?

Front-loaded with purpose and usage, and every sentence carries information. However it is delivered as one long dense paragraph with some redundancy (the category caveat repeats in both description and schema), so structure could be tighter.

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 9-parameter, filter-heavy discovery tool with no output schema, the description covers the decision-making an agent needs: what each filter does, common pitfalls, return contents, and preconditions before deployment. Nothing essential to correct invocation is missing.

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 coverage is 100%, so baseline is 3, but the description adds real meaning: it explains why to limit to one or two providers (some offer hundreds of models), clarifies that category values are provider-specific and not a Cycle taxonomy, and distinguishes category from hypervisor_only. It reinforces rather than replaces the schema.

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?

Opens with a specific verb+resource ('Discover what infrastructure can be provisioned on this hub') and enumerates exactly what is returned — enabled integrations, then server models with specs, locations, and pricing. It is clearly a read-only discovery tool and distinguishable from deployment siblings like deploy_servers or deploy_virtual_machine.

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?

Explicitly routes the agent: use hypervisor_only to find VM-capable hardware rather than guessing a category, call without a category filter first to read real categories off results, and use the tool to verify a model/location exists before deployment. It even supplies concrete example questions that map to invocation patterns.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources