Omnara

Update model provider config

model_providers_update

DestructiveIdempotent

Updates a model provider config's connection settings, such as its credential and headers, and returns the updated config; omitted fields keep their values. The credential secret is checked to exist and match auth_kind, but the provider isn't contacted, so a credential the provider rejects isn't caught here.

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

Input Schema

Name	Required	Description
`orgID`	Yes	Organization ID (org_...).
`headers`	No	Extra HTTP headers sent with every request to this provider. Values are stored and returned as plain text; use secret_headers for keys and tokens. Replaces all headers when provided.
`base_url`	No	Provider endpoint base URL.
`auth_kind`	No	How the credential is sent: bearer_token, api_key_header, or sigv4 (AWS).
`auth_options`	No	Non-secret authentication settings. Use an empty object with bearer_token. With api_key_header, set {"header_name":"..."}. With sigv4, set the AWS signing service and region.
`endpoint_path`	No	URL path under base_url. This changes where requests are sent, not which API format Omnara speaks.
`secret_headers`	No	Extra HTTP headers whose values come from org-owned generic secrets, mapping header names to secret references. Replaces all secret headers when provided.
`idle_timeout_ms`	No	Maximum wait for response headers or the next response bytes, in milliseconds. Heartbeats count as activity. Local response processing does not consume this idle budget.
`request_timeout_ms`	No	Total deadline for one provider attempt, including reasoning and response streaming, in milliseconds. Retries have separate deadlines.
`credential_secret_id`	No	Secret ID (sec_...).
`modelProviderConfigID`	Yes	Model provider config ID (mpc_...).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

changedInput schema / properties / base_url / description

Previous value: -"Provider endpoint base URL. Normal API mode requires a public HTTPS endpoint; localhost and loopback endpoints are accepted only when the API is running in insecure dev mode."New value: +"Provider endpoint base URL."

Changed5 schema fields changedOct 17, 2026
- addedInput schema / $defs / SecretID / description
```
Added value: +"Secret ID (sec_...)."
```
- addedInput schema / properties / auth_kind / description
```
Added value: +"How the credential is sent: bearer_token, api_key_header, or sigv4 (AWS)."
```
- addedInput schema / properties / credential_secret_id / description
```
Added value: +"Secret ID (sec_...)."
```
- addedInput schema / properties / modelProviderConfigID / description
```
Added value: +"Model provider config ID (mpc_...)."
```
- addedInput schema / properties / orgID / description
```
Added value: +"Organization ID (org_...)."
```
AddedOct 13, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Adds real information beyond the annotations: it returns the updated config, it uses partial-update merge semantics, and it explicitly frames the validation boundary — the credential is checked for existence and auth_kind match, but the provider is not contacted, so a rejected credential passes silently. That is exactly the kind of thing an agent needs to set expectations. It stops short of stating the destructive side effect (headers/secret_headers being fully replaced) that justifies destructiveHint=true, and it says nothing about permissions.

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: the first states the action, return value, and merge behavior; the second states the validation caveat. Nothing is redundant and the most load-bearing facts come first.

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 an 11-parameter mutation with nested objects and no output schema, the description covers the essentials — merge semantics, return value, and the surprising validation gap. It would be stronger if it flagged that provided headers/secret_headers replace rather than merge, since that is the main destructive risk.

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 coverage is 100%, so the schema already documents all 11 parameters in depth, including enums, patterns, and the auth_options shapes. The description only alludes to "credential and headers" as examples and adds no format or interaction detail beyond the schema, so 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?

A specific verb and resource: "Updates a model provider config's connection settings" plus a note that it returns the updated config. It is clearly the mutation counterpart to model_providers_get/create, though it never names a sibling to route against 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?

"Omitted fields keep their values" gives useful patch-semantics guidance for how to invoke it, but there is no statement of when to prefer this over model_providers_create or what prerequisites exist (e.g., the config must already exist). Usage is implied rather than spelled out.

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.