Skip to main content
Glama

Omnara

by com.omnara
OverviewDiscussions(1)Admin

Update configured model

models_update
DestructiveIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
nameNoHuman-readable name. Spaces and punctuation are allowed; leading or trailing whitespace and invisible or control characters are not.
orgIDYesOrganization ID (org_...).
supports_toolsNoWhether this configured model can receive tool definitions and emit tool calls. Agent configs with enabled tools are rejected when this is false. Omitted keeps the current value.
input_modalitiesNoInput types this configured model accepts. Omnara recognizes text, image, and file; an empty list leaves capabilities unspecified.
configuredModelIDYesConfigured model ID (mdl_...).
max_output_tokensNoKnown output-token ceiling for this model. Omitted keeps the current value. Null clears it to unknown for every API format.
output_modalitiesNoOutput types this configured model can return. Omnara currently consumes text output.
supports_reasoningNoWhether Omnara should use this model's reasoning features. For OpenAI Responses, this also enables encrypted reasoning replay for stateless calls. Omitted keeps the current value.
api_variant_optionsNoExtra top-level JSON fields to include in provider requests for this configured model. Use this for provider-specific settings that Omnara does not expose as typed fields, such as OpenRouter `provider` routing or sampling parameters. Omnara still controls the fields it needs to run the agent correctly, including the model, prompt/messages, streaming, tools, output-token limit, and selected reasoning policy. Provider passthrough values for those fields are ignored. For OpenRouter routing options, see https://openrouter.ai/docs/guides/routing/provider-selection and general request parameters at https://openrouter.ai/docs/api/reference/parameters. Omnara-managed OpenRouter providers accept only sampling, reasoning, and per-model routing options here.
provider_model_slugNoExact provider model slug sent to the provider endpoint. Free-pool, `:online`, and preset model ids are not accepted on Omnara-managed OpenRouter providers.
context_window_tokensNoContext budget for input and output tokens. Triggers compaction when estimated input exceeds the remaining budget after output and safety reserves. The turn fails if compaction cannot make it fit.
modelProviderConfigIDYesModel provider config ID (mpc_...).
default_cache_retentionNoPrompt-cache preference for model requests; `short` when omitted. `short` applies the route's default caching (explicit cache breakpoints where the provider requires them) and, where the route accepts one, a stable conversation key for cache-aware routing. `long` prefers the route's extended cache lifetime where one exists (currently Anthropic's one-hour cache, which on Bedrock requires Claude 4.5 or newer) and behaves like `short` elsewhere. `none` sends no Omnara-managed cache controls or conversation key; providers may still cache prefixes on their own.
default_reasoning_effortNoDefault reasoning effort to send for models/API formats that support effort-style reasoning controls. Requires supports_reasoning=true. When supported_reasoning_efforts is present, this value must be listed there.
default_max_output_tokensNoOptional per-request output allowance unless a project or agent overrides it. Without a default or known ceiling, Messages uses 64000 tokens; other formats omit the allowance.
supported_reasoning_effortsNoReasoning effort values this configured model accepts. Requires supports_reasoning=true when non-empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / configuredModelID / description
      Added value: +"Configured model ID (mdl_...)."
    • addedInput schema / properties / modelProviderConfigID / description
      Added value: +"Model provider config ID (mpc_...)."
    • addedInput schema / properties / orgID / description
      Added value: +"Organization ID (org_...)."
  2. Changed1 schema field changed
    • changedInput schema / properties / context_window_tokens / description
      Previous value: -"Total token window for this model, including input and output."New value: +"Context budget for input and output tokens. Triggers compaction when estimated input exceeds the remaining budget after output and safety reserves. The turn fails if compaction cannot make it fit."
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Well beyond the annotations: it discloses partial-update semantics ('omitted fields keep their values'), live propagation timing, the fact that no grant/agent-config validation runs, and the concrete failure mode when a limit or capability is lowered. Annotations only signal destructive/idempotent; the description explains the blast radius.

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 sentences, front-loaded with the action and its return, followed by propagation and hazard. The final sentence is long but each clause carries distinct consequence information rather than padding.

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?

For a 16-parameter mutation with no output schema, it covers the return value, propagation behavior, and failure consequences. Combined with idempotentHint/destructiveHint annotations and full schema coverage, little is missing, though the interaction with grants is mentioned only as an absence.

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 description coverage is 100%, so the baseline is 3. The description's only parameter-level addition, 'omitted fields keep their values', largely duplicates per-field text already in the schema ('Omitted keeps the current value'), so it adds little new meaning.

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?

States a specific verb and resource ('Updates a configured model's settings and returns the updated model'), and the resource wording ('configured model') distinguishes it from siblings like models_create, models_delete, and model_providers_update. An agent can tell what entity this mutates without opening the schema.

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?

Gives clear operating context: changes propagate on the agent's next model call, and lowering limits or disabling tools/reasoning can break dependent agents. It never explicitly routes the agent to an alternative tool (e.g. models_create vs models_update), so exclusions are absent, but the risk framing is strong.

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

All Omnara toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources