Skip to main content
Glama

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.

Input Schema

NameRequiredDescriptionDefault
nameYesHuman-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.
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.
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 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. Changed2 schema fields changed
    • 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

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds genuine behavioral context beyond them: the slug is NOT validated against the provider's catalog, and the new model is not yet usable by any project (implying further grants/config are needed). It also notes it returns the created model.

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?

Two tight sentences with the core verb+resource front-loaded and the two important caveats (no catalog validation, not yet usable) trailing. Every clause carries information; nothing is wasted.

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 15-parameter mutation with a nested object and no output schema, the description is compact but covers the key behavioral consequences, and the schema carries full parameter detail. What is thin is return-value description ('returns it') in the absence of an output schema, plus no mention of required permissions.

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 every one of the 15 parameters is already documented in the schema. The description adds no parameter-level detail (e.g., about context_window_tokens or api_variant_options) beyond what the schema provides, so baseline 3 is correct.

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 clarifies the naming role ('the name agent configs use as model.name'). It implicitly separates this from model_providers_create (which creates the config itself) and models_update, though it never names a sibling explicitly.

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 only implied: the model is added 'to this provider config,' so a provider config must already exist. There is no explicit statement of when to choose this tool over model_providers_create or models_update, and no exclusions are given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.