TRAECNclaw MCP

Set TraeCN Setting Toggle

traecn_set_setting_toggle

Idempotent

Enable or disable a specific toggle setting by section and label, then read back the applied state. Applying the current state succeeds as a no-op.

Instructions

Enable or disable one toggle setting identified by section and label, then read back the applied state. Applying the already-current state succeeds as a no-op.

Input Schema

Name	Required	Description
`label`	Yes	Setting label exactly as returned by traecn_list_settings.
`enabled`	Yes	Desired toggle state.
`section`	Yes	Section name exactly as returned by traecn_list_setting_sections.

Output Schema

Name	Required	Description
`code`	No	Stable machine-readable result or error code.
`error`	No	Error identifier or diagnostic when the operation failed.
`label`	No	Setting label that was written.
`value`	No	Value applied to the setting.
`result`	No	Driver-reported write outcome, including already-in-desired-state.
`status`	No	Stable operation or task status.
`taskId`	No	Stable gateway task identifier.
`changed`	No	Whether visible TraeCN state changed.
`message`	No	Human-readable outcome summary.
`success`	No	Whether the operation succeeded.
`verified`	No	True only when the observed UI value equals the requested value.
`retryable`	No	Whether retrying the same call can succeed later.
`nextAction`	No	Suggested next step after a failure.
`controlType`	No	UI control whose value was read back.
`conversationId`	No	Stable TraeCN conversation identifier.
`requestedValue`	No	Value requested by the caller.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.7.1-glama.1Nov 7, 2026

addedOutput schema / properties / controlType

Added value: +{
+  "description": "UI control whose value was read back.",
+  "enum": [
+    "toggle",
+    "option",
+    "text"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / requestedValue

Added value: +{
+  "description": "Value requested by the caller."
+}

addedOutput schema / properties / verified

Added value: +{
+  "description": "True only when the observed UI value equals the requested value.",
+  "type": "boolean"
+}

First observedAug 24, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered; the description adds that the tool reads back the applied state, which no annotation conveys. The no-op sentence largely restates idempotentHint, and no failure mode (unknown section/label, missing workspace context) is described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, the mutation is front-loaded ahead of the post-condition, and no words are wasted. Every clause carries information an agent can act on.

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?

An output schema exists, so the 'read back the applied state' clause is sufficient without detailing return values, and all three parameters are fully documented in the schema. The remaining gap is error behavior for unknown or non-toggle settings, which matters for a 20-sibling settings surface but is minor at this complexity.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter carries a cross-reference to the listing tool that supplies valid values, so the schema already carries the semantics. The description adds nothing about parameter values or how section and label are matched, leaving the baseline score appropriate.

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?

The description states a specific verb pair (enable/disable) on a specific resource (one toggle setting identified by section and label), which implicitly distinguishes it from traecn_set_setting_text and traecn_select_setting_option. It never names those siblings explicitly, so the differentiation relies on the reader inferring 'toggle' means boolean-valued settings.

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

Usage Guidelines3/5

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

Usage is only implied through the prerequisites embedded in the schema ('exactly as returned by traecn_list_settings' / 'traecn_list_setting_sections'), which tells the agent to discover section and label first. There is no explicit when-to-use-this-vs-traecn_set_setting_text guidance and no stated conditions under which a setting cannot be toggled.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.