Skip to main content
Glama
omnara-ai

omnara

Official
by omnara-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Update machine pool

pools_update
DestructiveIdempotent

Update a machine pool's configuration; tenant-managed pools accept all fields, while cluster-managed pools allow only CPU, memory, env, secrets, and idle deletion changes.

Instructions

Tenant-managed pools support every request field. Cluster-managed pools only allow changes to default CPU and memory, environment and secret environment variables, provider-supported per-machine CPU and memory limits, and the idle deletion policy. Other cluster-managed changes are rejected with 409 Conflict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-readable name. Spaces and punctuation are allowed; leading or trailing whitespace and invisible or control characters are not.
orgIDYes
poolIDYes
metadataNoUser-supplied metadata stored on a machine, provided directly or copied from the machine pool that provisions it. A restriction of Metadata that leaves room for one reserved pair - Omnara sets observed_platform on the machine to the platform reported by its daemon, so the key is reserved and at most 15 user pairs are accepted.
default_cwdNo
descriptionNo
max_total_cpuNo
max_machine_cpuNo
min_machine_cpuNo
provider_configNo
max_total_machinesNo
default_machine_cpuNo
default_machine_envNoDefault environment for pool machines. A machine's environment, including resolved secret_env values, is applied to the provider machine at provisioning, so the provider_options startup_script and the daemon run with it, and is resolved again for each process at launch.
max_total_memory_mbNo
max_machine_memory_mbNo
min_machine_memory_mbNo
provider_auth_secret_idNo
default_machine_memory_mbNo
delete_after_idle_minutesNoIdle minutes before deleting a machine from this pool. Null clears the pool default; omitted leaves it unchanged.
default_machine_secret_envNoDefault secret environment for pool machines, mapping env names to generic secret references. References are resolved to secret values wherever the machine environment is applied.
runtime_protection_enabledNoWhether Omnara should delete a pool machine when its provider remains running after its daemon becomes inactive.
default_machine_provider_optionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description goes beyond them by disclosing the cluster-managed restriction set and the exact failure mode (409 Conflict) for disallowed changes. That is genuinely additive behavioral context, though it says nothing about permission requirements or reversibility.

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?

Three tight sentences with the tenant-vs-cluster distinction front-loaded and the 409 consequence last. No filler, though the field enumeration could be trimmed and no example values are offered.

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

Completeness3/5

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

For a destructive mutation on a 22-parameter schema at 27% coverage, the description supplies the most important safety caveat (cluster-managed rejection) but leaves the bulk of parameters and any idempotency/merge semantics unexplained. No output schema, so return values need not be covered.

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

Parameters2/5

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

Schema coverage is only 27% across 22 parameters, so the description carries a heavy burden. It names a subset of editable fields (default CPU/memory, env and secret env vars, per-machine limits, idle deletion policy) but leaves most parameters (name, metadata, description, default_cwd, provider_config, *_total_* fields) undocumented in both schema and description.

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 name and title establish a specific verb+resource (update a machine pool), and the description adds meaningful scope by distinguishing tenant-managed vs cluster-managed pools. It never explicitly restates the update action or differentiates itself from siblings like pools_create/pools_delete, so a 4 rather than 5.

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?

It implies usage by describing which fields are editable per pool type, but never states when to reach for this tool over alternatives (e.g. pools_create for new pools), nor any prerequisite/auth context. Useful constraint info, but no real routing guidance.

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

Deploy Server

Other Tools