switch_profileChange the active model endpoint by switching to a named profile. All subsequent tool calls use that profile's endpoint until you switch again.
Make a named profile the active one. All subsequent model tools use its endpoint until switched again.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key side effect: the active profile persists and changes the endpoint used by all subsequent model tools. It does not mention failure behavior or profile validation, but the core behavioral trait is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and the second sentence adds a necessary consequence. There is no filler and no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter stateful setter, the description covers the action, scope, and persistence. It does not describe return values or error handling, but there is no output schema and those details are less critical for this kind of tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, `name`, and schema description coverage is 0%, so the description must compensate. It explains that the name identifies a profile, but it does not explicitly say the profile must already exist or how it relates to create_profile/list_profiles. The meaning is adequate but not fully elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Make a named profile the active one.' It also states the lasting consequence ('All subsequent model tools use its endpoint until switched again'), which distinguishes it from read-only siblings like get_active_profile and from create_profile/update_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: switching is a persistent, global change that affects subsequent model tool calls until another switch. It does not explicitly name alternatives or when-not-to-use conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.