Odile Gate

Set an app's allowed models

gate_set_models

Idempotent

For a project in front of a model API: limit which models one app may ask for (the request body's "model", including each batch request, a model form or query field, or a /models/ path; a body Gate cannot read strictly counts as another model). Other models are refused with 403 model_not_allowed before the provider sees them. models: null removes the limit.

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": {
      "project_id": "<project_id>",
      "admin_key": "<admin_key>",
      "app": "<app>",
      "models": "<models>"
    },
    "name": "gate_set_models"
  }
}

Input Schema

Name	Required	Description
`app`	Yes	The app id (app_...)
`models`	Yes	Exact names or prefixes ending in *; null for no limit
`admin_key`	Yes	The project admin key (ga_...). Read it from the .env; never print it.
`project_id`	Yes	The project id from gate_create_project, e.g. p1a2b3...

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds real behavior beyond the annotations: a fail-closed rule (an unreadable body counts as another model), the exact refusal code and that it happens before the provider sees the request, and that null removes the limit. Annotations only supply safety/idempotency hints; the description supplies the semantics.

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?

Front-loaded with the core action, then elaboration; no filler sentences. The long parenthetical listing request locations is dense but earns its space; slightly awkward to parse in one pass.

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?

Covers scope, refusal behavior, and limit removal for a 4-required-parameter mutation with no output schema. What is missing is minor: the shape of a successful response or whether the admin key must belong to the same project, though the schema already points at project_id and admin_key.

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 meaningfully deepens the 'models' parameter by defining what counts as a requested model across all request shapes. It only lightly restates the null behavior already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: limit which models one app may ask for, scoped to a project. It goes further and enumerates exactly where the requested model is read from (body, batch entries, form/query field, /models/<name> path), which no sibling tool covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives the operating context ('a project in front of a model API') and the effect on non-allowed models (403 model_not_allowed before the provider). It does not name alternatives such as gate_set_app_runs or gate_update_app, so the agent must infer that model restriction is separate from app-level settings.

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

All Odile Gate 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.

Resources

Need Help?