Skip to main content
Glama
Sign In
agent-bridge

agent-bridge

by merlinh0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_model_policy

Configure allowed-model glob patterns and tier-specific model pins to control which models agents may use under user-defined rules.

Instructions

Set which models agents may use. Call it when the user states model rules in their instructions.

allowed_models: glob patterns; omp models match their selector ("openai-codex/", "anthropic/claude-sonnet-", "/gpt-6", "litellm/"), Claude Code models match "claude-code/" ("claude-code/"). [] allows everything. tiers: pin a model per tier, e.g. {"frontier": "openai-codex/gpt-6.1-sol"}. {} unpins all. Only the fields you pass change. The rules last until the MCP server restarts (usually with the app); the user's permanent defaults are the same two keys in ~/.agent-bridge/config.json.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_model_policy"
  }
}

Input Schema

NameRequiredDescriptionDefault
tiersNo
allowed_modelsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses partial-update semantics ("Only the fields you pass change"), that rules are volatile (until the MCP server restarts), and where the permanent equivalent lives. It omits whether already-running agents pick up the change immediately and whether any authorization is needed.

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?

Purpose and trigger are front-loaded, then parameters are explained bullet-style with concrete examples that earn their space. The config-file path sentence is useful but slightly dense for the value it adds.

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 two-parameter, all-optional mutation tool with no annotations and no output schema, the description covers start state, merge behavior, sentinel values, and lifetime. The main gap is the return/effect signal — what happens after the call and to in-flight agents.

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 0%, so the description must compensate, and it does: it explains that allowed_models takes glob patterns with worked examples per provider, that [] means allow-all, that tiers pins a model per tier with an example, and that {} unpins all. The remaining ambiguity is whether passing tiers replaces the whole tier map or merges into it.

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?

"Set which models agents may use" gives a specific verb and resource, and the two option keys make the scope concrete. It never names get_model_policy as the read counterpart, so the sibling boundary is implied rather than stated.

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?

"Call it when the user states model rules in their instructions" is a clear trigger condition. There is no explicit when-not guidance (e.g. don't use for one-off per-agent overrides) and no mention of the read counterpart for inspecting current state.

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