Skip to main content
Glama
omnara-ai

omnara

Official
by omnara-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Create configured model

models_create

Register a configured model with its provider, context window, and capabilities so agents can use it. Set token limits, modalities, and reasoning options.

Instructions

Create configured model

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-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.
input_modalitiesNoInput types this configured model accepts. Omnara recognizes text, image, and file; an empty list leaves capabilities unspecified.
max_output_tokensNoOptional 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_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.
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_slugYesExact 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_tokensYesContext 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 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_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.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds nothing on top: no mention of required auth/org scoping, validation failure modes, what is created or returned, or whether the operation is idempotent. For a 15-parameter creation tool, this is a real gap.

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?

Four words with no waste, but the brevity is under-specification rather than conciseness. There is no front-loaded intent beyond the title, and no sentence earns additional informational value.

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

Completeness1/5

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

For a tool with 15 parameters, a nested object parameter, five required fields, and no output schema, the description is completely inadequate. Nothing tells the agent about dependencies between fields (e.g., supported_reasoning_efforts requiring supports_reasoning), which the schema only partially encodes, and no return expectation is set.

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 87%, so the schema itself already documents nearly every parameter in depth (including constraints like provider_model_slug rejection of free-pool ids and reasoning-effort coupling). The description provides zero parameter meaning beyond that, which lands at the baseline of 3 when the schema carries the load.

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 Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent cannot tell from this text whether a model must first be registered via model_providers_create, or when to prefer models_update over recreating. No guidance is offered at all.

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