Persist user-specific debugger settings for system and update debugging, plus table read limits. Preferences remain active until changed.
Change how the debugger behaves for this user: system debugging, update debugging, how much of a table it reads. They are user settings and stay until changed back.
| Name | Required | Description | Default |
|---|---|---|---|
| settings | Yes | The debugger settings. |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation. The description adds transparency by stating the settings are user-specific and persistent ('stay until changed back'), which clarifies the side-effect profile beyond the annotation hints. It doesn't contradict annotations and provides useful 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 two concise sentences with no filler. It front-loads the primary purpose (changing debugger behavior) and immediately follows with the scope ('for this user') and persistence trait. Every sentence contributes information, and it is appropriately sized for a simple tool.
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 one simple string parameter and no output schema, this is moderately complete. It conveys the purpose, scope, and persistence, but lacks detail on how to structure the settings string (format, allowed values, examples). An agent could struggle to construct a valid 'settings' value without further guidance. Given the simplicity, some missing format details are a notable gap.
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?
The sole parameter 'settings' has a generic schema description ('The debugger settings.'). The tool description adds some context by naming the configurable aspects (system debugging, update debugging, table read amount), which hints at the content, but it doesn't specify the expected format (e.g., JSON, key-value) or usage syntax. Since schema coverage is 100%, baseline is 3, and the description adds limited but non-trivial meaning.
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 verb 'Change' and a specific resource 'how the debugger behaves for this user', and enumerates specific aspects (system debugging, update debugging, table read amount). This distinguishes it from other debugger tools like debuggerSetVariableValue or debuggerSetBreakpoints, making the purpose unambiguous.
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 provides clear context: it's for user-level persistent settings ('stay until changed back'). This implies when to use it (when adjusting persistent debugger behavior) and distinguishes from transient debugger operations. It doesn't explicitly mention alternatives, but the uniqueness of the tool within the sibling list makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.