Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_ai_route

Create or replace an AI gateway alias that lets apps route model requests through the gateway and keeps provider keys out of containers.

Instructions

Create or replace a machine AI gateway alias (submitter or admin).

    Apps then declare ``[ai.default] provider = "gateway"`` and
    ``model = "<alias>"``: the daemon injects the gateway URL and a per-app
    virtual key, and the provider key never enters a container. Answers
    ``enabled: false`` while ``[ai_gateway]`` is off (the alias is stored
    and serves once it is enabled). Refusals: 422 ``ai_gateway.alias_invalid``,
    ``ai_gateway.base_url_invalid`` (not https, private address, userinfo),
    ``ai_gateway.secret_ref_invalid``.

Input Schema

NameRequiredDescriptionDefault
aliasYesMachine alias an app names in ``[ai.<name>] model`` with ``provider = "gateway"``: a lowercase letter, then up to 31 of a-z, 0-9, '_' or '-'.
modelYesProvider model the alias maps to (an ollama model name for provider 'ollama').
base_urlNoProvider ``api`` only: OpenAI-compatible base URL, usually ending in ``/v1``; https to a public host, or http to loopback or the models bridge.
providerNo``api`` (an OpenAI-compatible provider) or ``ollama`` (a model served on this machine).api
api_key_refNoProvider ``api`` only: a ``${secrets.shared.KEY}`` reference to the provider key, set beforehand with ``set_secret`` on scope ``shared``. Never the key itself.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does so well: it discloses that this is an upsert (replace, not just create), that submitter or admin privileges are required, that the daemon injects the gateway URL and a per-app virtual key so the provider key never enters a container, and that a disabled gateway yields enabled: false while still storing the alias. It even enumerates the specific 422 refusal codes (alias_invalid, base_url_invalid, secret_ref_invalid), which is exactly the kind of failure-mode context annotations would otherwise provide.

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?

The primary action is front-loaded in the first clause, and the remaining sentences earn their place by covering the app-side contract, the disabled-gateway behavior, and refusal codes. It is dense and slightly prose-heavy, but no sentence is redundant.

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

Completeness5/5

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

For a six-parameter mutation tool with no annotations and no output schema, the description supplies the missing pieces an agent needs: mutation semantics, authorization, the substitute response shape (enabled: false), and enumerated error codes. Nothing material is left to inference.

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 documents all six parameters including alias naming rules, base_url constraints, and the ${secrets.shared.KEY} reference form; baseline is 3. The description reinforces two things the schema also states (alias/model pairing, secret refs via set_secret on the shared scope) but adds no syntax or edge-case detail beyond the structured fields.

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+resource with upsert semantics: 'Create or replace a machine AI gateway alias', plus the actor scope '(submitter or admin)'. An agent can distinguish this from list_ai_routes and remove_ai_route purely from the verb, without opening a schema.

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?

Explains the downstream use case (apps then declare provider = "gateway" and model = "<alias>") and the disabled-gateway condition, so the agent knows the context in which this is the right call. It stops short of naming alternatives explicitly (e.g. 'use list_ai_routes to inspect, remove_ai_route to delete'), so it lacks a true when-not clause.

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