Skip to main content
Glama
omnara-ai

omnara

Official
by omnara-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Update configured model

models_update
DestructiveIdempotent

Update a configured model's provider settings, capabilities, token limits, and reasoning options to control how Omnara agents invoke it.

Instructions

Update configured model

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
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.
configuredModelIDYes
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.
modelProviderConfigIDYes
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. First observed

TDQS

C2/5.0
Behavior2/5

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

The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds no behavioral context: it does not explain what gets changed, what required IDs mean, whether omitted fields are preserved, or how destructive effects behave. With annotations carrying the safety burden, the near-total absence of additional context merits a low score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short, but it is under-specified rather than concisely informative. It contains no structure or front-loaded useful information beyond the tool title, so it fails the 'every sentence earns its place' standard by having no substantive sentence at all.

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

Completeness2/5

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

This is a destructive mutation tool with 16 parameters and a nested object schema. The description says nothing about required IDs, update semantics, nullable clearing behavior, or provider-specific restrictions. Although annotations and a detailed schema provide some scaffolding, the description is far too sparse for the tool's complexity.

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 81%, which is high, so the schema already documents most parameters in detail. The description adds no parameter meaning at all. When schema coverage is high, a baseline of 3 is appropriate even if the description contributes nothing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about what conditions make an update appropriate. The description offers nothing beyond the bare tool name.

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