Adjust reasoning effort for an existing thread to control response depth. Use it when a coding agent session needs more or less analysis, without losing provider context.
Set the reasoning effort for an existing thread when supported.
| Name | Required | Description | Default |
|---|---|---|---|
| effort | Yes | ||
| threadId | Yes |
Changes observed during successful MCP inspections.
v0.2.18Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint: false) with no destructive flag. The description adds only the vague qualifier 'when supported,' which doesn't disclose concrete behavior such as whether the change takes effect immediately, whether it requires specific permissions, or whether it can be reversed. With annotations present, some credit is given, but the description adds minimal behavioral context.
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?
The description is a single, efficient sentence that front-loads the primary action. It avoids fluff and is appropriately sized for a simple operation. The brevity is a positive trait, though it sacrifices necessary detail.
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 tool with two required parameters and no output schema, the description is woefully incomplete. It omits what reasoning effort means, how to select appropriate values, when the operation succeeds or fails, and how it relates to sibling tools like set_model. An agent would have to infer most of the necessary context from parameter names alone.
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?
Schema description coverage is 0%, so the description must compensate for the lack of parameter meaning. It does not explain what 'effort' values are valid, what 'threadId' refers to beyond being a thread identifier, or the relationship between the two. The schema only provides types (string|null for effort), leaving the agent to guess allowed values or formats. The description fails to add any semantic value.
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 states a clear action: 'Set the reasoning effort' on a thread. It identifies the resource (thread) and the specific attribute (reasoning effort), which distinguishes it from sibling tools like set_model or send_message. However, it doesn't explicitly differentiate from alternatives, so it's clear but not fully distinguishing.
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?
No guidance on when to use this tool versus alternatives. The phrase 'when supported' hints at conditional applicability, but it doesn't explain which threads or models support it, nor does it mention when to prefer set_reasoning over set_model or other thread-management tools. An agent has to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.