Omnara

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "configuredModelID": "<configuredModelID>",
      "modelProviderConfigID": "<modelProviderConfigID>",
      "orgID": "<orgID>"
    },
    "name": "models_update"
  }
}

Input Schema

Name	Required	Description
`name`	No	User-assigned configured model name used by agent YAML as model.name. Renaming affects future YAML resolution but does not change existing agents.
`orgID`	Yes	Organization ID (org_...).
`supports_tools`	No	Whether 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_modalities`	No	Input types this configured model accepts. Omnara recognizes text, image, and file; an empty list leaves capabilities unspecified.
`configuredModelID`	Yes	Configured model ID (mdl_...).
`max_output_tokens`	No	Known output-token ceiling for this model. Omitted keeps the current value. Null clears it to unknown for every API format.
`output_modalities`	No	Output types this configured model can return. Omnara currently consumes text output.
`supports_reasoning`	No	Whether 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_options`	No	Extra 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_slug`	No	Exact 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_tokens`	No	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.
`modelProviderConfigID`	Yes	Model provider config ID (mpc_...).
`default_cache_retention`	No	Prompt-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_effort`	No	Default 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_tokens`	No	Optional 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_efforts`	No	Reasoning effort values this configured model accepts. Requires supports_reasoning=true when non-empty.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / name / description

Previous value: -"Human-readable name. Spaces and punctuation are allowed; leading or trailing whitespace and invisible or control characters are not."New value: +"User-assigned configured model name used by agent YAML as model.name. Renaming affects future YAML resolution but does not change existing agents."

Changed3 schema fields changedOct 17, 2026
- 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_...)."
```

Changed1 schema field changedOct 15, 2026

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."

AddedOct 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already mark this destructive and idempotent, but the description goes well beyond them: it discloses partial-update semantics, propagation timing to live agents, and the precise failure mode (lowering a limit below an agent override or disabling tools/reasoning breaks that agent's next call because grants and agent configs are not re-validated). That is exactly the consequence-level context an agent needs before mutating shared configuration.

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

Conciseness5/5

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

Three sentences, front-loaded with the action and the partial-update rule, followed by propagation timing and the risk note. No restatement of the title, no filler, and the most consequential warning is placed last where it reads as a caveat rather than being buried.

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 16-parameter, nested-object, destructive mutation with no output schema, the description covers the operation, the merge semantics, the downstream blast radius on agents, and the return value ("returns the updated model"). Combined with the fully documented schema, an agent has enough to call this safely.

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 the baseline is 3, but the description adds a cross-cutting semantic rule that the schema states only per-field: omitted fields retain current values, making this a PATCH-style partial update across all 16 parameters. That is genuine meaning beyond the individual property descriptions.

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 description opens with a specific verb and resource ("Updates a configured model's settings") and immediately states the patch semantics ("omitted fields keep their values") plus the return ("returns the updated model"). It does not explicitly differentiate from the neighboring models_create/models_delete or model_providers_update, but the "configured model" framing maps unambiguously to the mdl_ resource.

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?

Usage is implied rather than stated: the agent learns that changes propagate to running agents on their next call and that nothing is validated against grants or agent configs. There is no explicit "use this instead of X" or precondition routing to models_create or grant_models_edit, so the when-to-use decision is left to inference.

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

All Omnara tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.