Omnara

Create configured model

models_create

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.

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": {
      "context_window_tokens": "<context_window_tokens>",
      "modelProviderConfigID": "<modelProviderConfigID>",
      "name": "<name>",
      "orgID": "<orgID>",
      "provider_model_slug": "<provider_model_slug>"
    },
    "name": "models_create"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	User-assigned configured model name used by agent YAML as model.name. Names are unique within an active model provider config and can be renamed without changing 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.
`input_modalities`	No	Input types this configured model accepts. Omnara recognizes text, image, and file; an empty list leaves capabilities unspecified.
`max_output_tokens`	No	Optional known output-token ceiling. Omitted capacity remains unknown; selecting a discovered model can supply its published ceiling. Explicit values must not exceed the provider's supported limit.
`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.
`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`	Yes	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`	Yes	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 normal per-request output allowance. Discovery never populates this field. When omitted, requests use the known output ceiling. If both are absent, Messages uses 64000 tokens; other formats omit the allowance. Runtime allowances are fitted to available context.
`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. Names are unique within an active model provider config and can be renamed without changing existing agents."

Changed2 schema fields changedOct 17, 2026
- 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

A3.6/5.0

Behavior4/5

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

Annotations declare the safety profile (readOnly=false, destructive=false, idempotent=false), so the description is free to add what they cannot: the slug is not validated against the provider catalog, the tool returns the created object, and no project can use the model until further action. The non-validation caveat is a genuinely useful risk disclosure that an agent could not learn from structured fields. It does not mention auth/permission requirements or uniqueness conflict behavior on name, which keeps it below 5.

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?

Two sentences, front-loaded with the action and immediately followed by the two caveats that matter most to an agent. The first sentence is somewhat convoluted ('under the name agent configs use as model.name') but no sentence is wasted.

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 15-parameter creation tool with no output schema, the description covers intent and two behavioral caveats but says nothing about the returned object despite claiming to return it, nor about which parameters are required or how validation failures surface. It is adequate as a summary but thin relative to 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 100%, so the schema already carries the semantics of all 15 parameters, including the name/model.name relationship and the api_variant_options passthrough rules. The description's only additional parameter-adjacent information is the model.name naming linkage, which the schema's name property already states. Baseline 3 applies.

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 gives a specific verb and resource ('Adds a provider model to this provider config') and scopes it to a named parent entity, which separates it from model_providers_create and models_list/update. It stops short of naming any sibling explicitly, so the create-vs-update boundary is only inferable from the verb.

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?

'No project can use the model yet' implicitly signals a follow-up step (granting access) and that creation alone is not sufficient provisioning. However, there is no explicit when-to-use statement, no prerequisite (an existing mpc_... provider config), and no pointer to the sibling tools that complete the workflow.

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.