Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
OMNARA_API_KEYNoOmnara personal access token or org API key
OMNARA_API_URLNoAPI URL for self-hosted instances (default https://api.omnara.com/v1)

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
agents_archiveA

Archives the agent: requests cancellation of its active runtime, cancels queued inputs and affected processes, removes its pending wakeup, releases explicit machine bindings, deletes pooled machines created for the agent, and deletes cron triggers targeting the agent. The agent and its full event history stay readable by id; archived agents leave listings. The agent's profile and configuration are retained, as are explicitly attached BYO machines. Archiving an already-archived agent is a no-op that returns the agent unchanged.

agents_cancelA

Stops the agent's current turn: cancels its unfinished tool calls and open interactions, stops processes whose run_command hasn't returned yet, and discards pending steering messages. The agent stays active and keeps its queued messages, and processes whose run_command already returned keep running. Returns affected false and changes nothing when no turn is in progress.

agents_events_listA

Returns one page of agent events, chronological within the page. Forward pagination (after_sequence) walks from a known boundary toward the present using next_after_sequence. Backward pagination (before_sequence) starts at the latest events and walks toward the beginning using next_before_sequence; passing before_sequence takes precedence over after_sequence.

agents_getA

Returns one agent's state, model, profile, current config ID, activity (running, waiting_on_interaction, idle, or archived), attached machines, and MCP connection states. The conversation isn't included.

agents_inputA

Sends a message to an agent and returns the stored input. Queued messages (the default) wait until the agent is ready for new work; steering messages reach it at its next model call.

agents_interactions_listA

Lists an agent's permission prompts and ask_question questions, oldest first, with each one's form and answers. state filters by open, resolved, or canceled.

agents_interactions_resolveA

Answers an open permission prompt or question so the paused agent resumes, and returns the resolved interaction. Send one answer per question with zero-based option_indices; permission prompts use 0 for Allow and 1 for Deny.

agents_launchA

Launch from a pinned config, optionally adding agent-local integration tools, subscriptions and interaction handlers and admitting an attributed initial text input in the same transaction. Adding integration capabilities requires project management permission; launching an existing config requires agent operate permission. Reusing an idempotency key returns the current agent even if the retry body differs. The retry body is not applied and integration references are not resolved again.

agents_listA

Lists the project's agents with their current activity, newest first by default. Archived agents and subagents are excluded unless requested.

agents_updateA

Replaces an active agent's config without restarting its conversation and returns the new agent_config. Model, instruction, and tool changes apply at the agent's next model call; machine changes apply immediately, stopping processes on removed machines and deleting the agent's machines from removed pools. Send the complete config, not a patch.

configs_createA

Compiles and saves an immutable agent config (instruction, model, tools, machine_sources, and more) from YAML or JSON and returns it. Sending the same source again returns the existing config, as long as its names still resolve to the same resources.

configs_getA

Returns one agent config: its compiled definition with names resolved to IDs, and its source if it was saved with one. Configs Omnara derives on its own, such as those for subagents and integration launches, have no source.

crons_createA

Creates a cron trigger that fires on a schedule. A trigger targeting an agent profile launches a new agent from the profile's current config on each firing; a trigger targeting an agent sends an input to that agent. Missed firings are coalesced, matching standard cron behavior: if one or more scheduled times pass while firing is delayed, the trigger fires once for the oldest missed time and then resumes its schedule from the current time, without retroactively firing for the other missed times.

crons_deleteA

Deletes a cron trigger so it never fires again; there is no undo. Agents it already launched keep running.

crons_getA

Returns one cron trigger: its target, schedule, timezone, message template, enabled flag, and firing state (last_fired_at, next_fire_at, and any failure since the last successful firing).

crons_listA

Lists the project's cron triggers, newest first by default, filterable by name, agent, profile, or integration. Each item includes its schedule and next_fire_at.

crons_updateA

Updates the schedule, message template, or enabled state. The target is immutable; delete the trigger and create a new one to retarget.

grant_machines_addA

Lets a project's agent configs use one BYO machine by name and returns the grant with the machine's record. Pooled machines can't be granted this way and return 404.

grant_machines_deleteA

Removes the project's access to the machine. Processes that depended on the grant are stopped. The machine itself is retained, and there are no dependency blockers.

grant_machines_listA

Lists explicit machine grants that can be deleted directly. Pool-derived machine access is managed through project machine pool grants.

grant_models_addA

Lets a project's agent configs use a configured model and returns the new grant. Optional overrides can narrow the model for that project (lower token limits, tools or reasoning turned off, fewer reasoning efforts or modalities) and set its per-request defaults within those limits.

grant_models_deleteA

Removes the project's access to the configured model. The grant is live policy: new launches can no longer select the model, and agents already using it lose access on their next model call. The model itself is retained, and there are no dependency blockers.

grant_models_editA

Updates the project's overrides for the configured model. Omitted fields keep their current values; null, or [] for supported_reasoning_efforts, input_modalities, and output_modalities, clears an override so the project inherits from the configured model. Agents already using the model apply the updated overrides on their next model call. Updates are validated against the configured model's current revision but not against agent configs, so narrowing below a config's model settings, such as its context_window_tokens or reasoning effort, makes that agent's next model call fail.

grant_models_listA

Lists the configured models a project can use, most recently granted first by default, with each grant's overrides and the model's name and provider config.

grant_pools_addA

Lets a project create machines from a machine pool, optionally with its own defaults and usage caps within the pool's limits, and returns the grant. No machines are created by this call.

grant_pools_deleteA

Removes the project's access to the machine pool, revokes machine grants generated through it, and stops processes that depended on those grants. The pool itself is retained, and there are no dependency blockers.

grant_pools_editA

Updates the grant's overrides and limits. Omitted fields keep their current values; null clears an override so the grant follows the machine pool again. Overlay objects and metadata are replaced whole when present. Existing machines keep their configuration; the updated defaults and limits apply to new launches.

grant_pools_getA

Returns one project's grant for a machine pool, with the defaults and limits it sets on top of the pool's own. Null fields set no override, so the pool's value applies.

grant_pools_listA

Lists the machine pools a project can create machines from, one grant per pool, most recently granted first by default.

grant_secrets_addA

Shares a secret with another project so that project's resources can use it, and returns the grant; ownership doesn't change.

grant_secrets_deleteA

Deletes only this project grant. The secret, its versions, the target project, and other grants are retained, and there are no dependency blockers.

grant_secrets_listA

Lists the projects a secret is shared with, one grant per project, most recently shared first by default.

grant_skills_addA

Shares a skill with another project so its agent configs can attach it, and returns the grant; ownership doesn't change.

grant_skills_deleteA

Deletes only this project grant. The skill, its revisions, the target project, and other grants are retained, and there are no dependency blockers.

grant_skills_listB

Lists the projects a skill is shared with, one grant per project, most recently shared first by default.

machines_createA

Registers a machine you run yourself and returns its daemon token for installing omnarad on it; the token is shown only in this response. The machine stays offline until its daemon connects. project_ids grants it to those projects in the same call, and their agent configs reference it by display_name.

machines_deleteA

Deletes a BYO machine, ends its active daemon runtimes and work, revokes its daemon tokens and project grants, and releases agent bindings. Pooled machines are managed through their machine pool and cannot be deleted through this route. There are no dependency blockers for a BYO machine.

machines_getA

Returns one active machine's full record: connection state, execution defaults (secret IDs only, never values), metadata, and the latest failure report. Machines in other lifecycle states, such as pool machines still provisioning, aren't returned.

machines_listA

Lists the machines the caller can see, both BYO and pooled, newest first by default, with each one's connection state. Items are summaries without execution defaults or metadata.

machines_updateA

Updates a machine's execution defaults: working directory, environment variables, and secret environment variables. env and secret_env replace the whole map, and changes apply to processes started afterward.

model_providers_catalogA

Fetches the provider's live model catalog by validating the configured credential and probing the provider's /models endpoint. The call waits on the upstream provider, so it is slower than the other model provider config routes and can report failure as data.

model_providers_createA

Create a model provider config, validate the configured credential where the provider exposes a validation endpoint, then probe the provider's /models endpoint. The result is returned as model_catalog; a failed probe does not fail creation.

model_providers_deleteA

Deletes only the model provider config. Deletion is blocked while it has configured models. Cluster-managed provider configs cannot be deleted through this route.

model_providers_getA

Returns one model provider config's stored settings; secret values are never returned. The provider isn't contacted, so the response doesn't list its models.

model_providers_listA

List model provider configs with server-side filtering, sorting, and cursor pagination.

model_providers_updateA

Updates a model provider config's connection settings, such as its credential and headers, and returns the updated config; omitted fields keep their values. The credential secret is checked to exist and match auth_kind, but the provider isn't contacted, so a credential the provider rejects isn't caught here.

models_createA

Adds a provider model to this provider config under the name agent configs use as model.name, and returns it. The model slug isn't checked against the provider's catalog, and no project can use the model yet.

models_deleteA

Deletes only the configured model. Deletion is blocked while it has active project grants. Cluster-managed configured models cannot be deleted through this route.

models_listA

Lists the models configured under one model provider config, newest first, with each model's slug, token limits, and reasoning support.

models_updateA

Updates a configured model's settings and returns the updated model; omitted fields keep their values. Agents already using the model pick up the change on their next model call. The update isn't checked against project grants or agent configs, so lowering a limit below their overrides or turning off tools or reasoning they rely on makes those agents' next model call fail.

orgs_createA

Creates the organization and its local default resources atomically. An idempotency key determines the proposed organization ID; replaying it returns the existing organization. Without a key, each request is a fresh attempt. Optional default-provider provisioning begins after commit and retries asynchronously without failing organization creation.

orgs_listA

Users get every organization they belong to; org API keys get the organization that issued them. Items are ordered by organization name ascending.

pools_createB

Creates a machine pool in the organization. The body carries the pool name, the provider (agent37, arker, blaxel, boxd, createos, daytona, e2b, freestyle, modal, superserve, tenki, or unikraft), the provider auth secret, default machine settings, and the per-machine and total CPU, memory, and machine-count limits the provider supports; the required fields depend on the provider. See the createMachinePool operation in the Omnara API reference at https://docs.omnara.com/api-reference for the full request schema.

pools_deleteA

Deletes the machine pool and its pooled machines, revokes generated machine grants and project machine-pool grants, and stops processes that depended on those grants. Deleting a cluster-managed machine pool is rejected with 409 Conflict; there are no other dependency blockers.

pools_getA

Returns one machine pool's configuration and current usage: provider, default machine settings, CPU, memory, and machine-count limits, and idle deletion policy.

pools_listA

List machine pools with server-side filtering, sorting, and cursor pagination.

pools_updateA

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.

profiles_createB

Creates a named profile that points at an agent config and returns the profile with its current config.

profiles_deleteA

Deletes the profile, all of its profile versions, and any cron triggers targeting the profile. Agents launched from the profile are retained and keep running: each agent holds an immutable snapshot of the configuration it was launched with, so its reference to the profile becomes historical provenance only. Integration settings may retain the public profile ID; future launches fail as unavailable until those settings reference an available profile.

profiles_getA

Returns one agent profile with its current config, current_config_id, and current_generation.

profiles_listA

Lists the project's agent profiles, newest first by default, filterable by name. Items include a summary of each profile's current config, not its full compiled definition.

profiles_renameA

Renames an agent profile without changing its config. Agents and cron triggers reference the profile by ID and keep working, but configs that name the profile under subagents must use the new name the next time they're compiled.

profiles_updateA

Points a profile at a different agent config. Existing agents keep their current config; agents launched from the profile afterward use the new one. Fails with 409 unless expected_current_config_id matches the profile's current config.

projects_createA

Creates a project, makes the caller its admin, and returns it. The new project has no grants to organization models, machines, skills, or secrets.

projects_listB

Lists the projects the caller can access in the organization, newest first, with the caller's permissions on each.

secrets_createA

Creates an encrypted secret holding one credential and returns its metadata; the value is never returned. owner sets whether the organization, a project, or the caller owns it.

secrets_deleteA

Deletes the secret and permanently destroys all of its versions and project grants; the ciphertext cannot be recovered. Deletion is blocked while the secret is the credential of a model provider config, machine pool, or integration.

secrets_getA

Returns a secret's owner, kind, name, and current version; the secret value is never returned.

secrets_listA

Items are ordered by created_at descending, then id descending. Without an owner filter, returns the deduplicated union of organization secrets the caller may list, project secrets the caller may list, and the caller's own user secrets.

secrets_updateA

Renames a secret or replaces its metadata, and returns the updated secret without its value. The value, kind, and owner can't be changed here. References use the secret ID, so renaming doesn't break them.

skills_deleteA

Deletes the skill together with all of its revisions and project grants; uploaded archive content is destroyed. No other resources are deleted. Deletion is blocked while an active agent's configuration references the skill.

skills_getA

Returns one skill with its latest SKILL.md text and file listing.

skills_listA

Items are ordered by created_at descending, then id descending. Without an owner filter, returns the deduplicated union of organization skills the caller may list, project skills the caller may list, and the caller's own user skills. Grants are managed separately and do not change ownership.

tools_catalogA

Lists the built-in tools agent configs can use, with each tool's description and permission settings, plus the permission modes for custom and MCP tools.

whoamiA

Get the authenticated user and their organizations

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 75 tools

Disambiguation4/5

Tools are generally scoped to a distinct resource and action, and descriptions clarify subtle distinctions such as grants vs. direct resource updates. A few pairs remain easy to confuse, especially grant_pools_edit vs. pools_update and grant_models_edit vs. models_update, but the overall surface is well differentiated.

Naming Consistency4/5

Most names follow a predictable snake_case resource_action pattern, e.g. agents_list, crons_create, secrets_update, and grant_pools_add. Minor deviations such as whoami, tools_catalog, model_providers_catalog, and the use of edit for grant updates instead of update keep it from being fully consistent.

Tool Count2/5

At 75 tools, the server is far beyond a practical MCP tool surface and will create significant selection and context overhead for agents. The broad platform scope explains some of the size, but many domains could be consolidated or split into narrower servers.

Completeness3/5

Core agent, cron, machine, pool, model, secret, and grant workflows are well covered, with strong lifecycle support in several areas. However, notable gaps remain, such as no skills_create/update, limited org/project lifecycle operations beyond create/list, and some resources lacking full get/update coverage.

Maintenance

ActivityActive
ResponsivenessUnresponsive