Skip to main content
Glama
Sign In
Cortex Intelligent

Cortex Intelligent

by adyoi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_model

Override the model used for this session by providing a model name, enabling per-session model switching without changing global settings.

Instructions

Override the model for this session (env-level hint).

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": {
      "model": "<model>"
    },
    "name": "set_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose two real behavioral traits: the change is session-scoped and is an 'env-level hint' rather than a hard configuration mutation. However, it says nothing about permissions, persistence, reversibility, or effect on concurrently running tools, which matters for a state-changing call.

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?

A single front-loaded sentence with the action and scope stated first and no filler. The parenthetical is useful but left vague rather than expanded, so it is efficient without being fully crisp.

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

Completeness2/5

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

For a state-changing tool with no annotations, no output schema, and a completely undocumented parameter, this is too thin. An agent cannot tell valid model values, whether the override persists past the session, or what feedback (if any) confirms the change took effect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single required 'model' parameter, so the schema supplies no format guidance. The description only implies the parameter is the model to override; it never states accepted identifier syntax (provider prefix, aliases, case) or failure behavior for unknown models.

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?

States a specific verb (override) and resource (the model for this session), so an agent can distinguish it from sibling reads like detect_model or get_model_profile. The parenthetical 'env-level hint' slightly muddies whether an actual switch occurs, but the core action is identifiable.

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

Usage Guidelines2/5

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

The phrase 'for this session' implies a scoping condition, but the description never says when to prefer this over detect_model, get_model_profile, or model_decision, nor whether it must be called before other tools. No when-not guidance at all.

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