detach_stim_backend

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool closes and removes a backend but doesn't disclose what happens to ongoing stimulation (e.g., whether it forces disarm), error conditions, whether the session must be stopped first, or idempotency behavior if called on an already-detached backend. For a state-mutating tool with zero annotation coverage, this is a meaningful gap.

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?

A single, complete sentence with zero waste. Both the action and scope are conveyed efficiently. There is no redundant framing such as 'This tool is used for...' or repetition of information already in the schema/title.

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?

The output schema exists but the description doesn't explain what it returns. More critically, for a state-mutating tool (detaching a backend) with no annotations, the description should cover behavioral aspects like prerequisites (attached backend exists), side effects (stimulation halted), and error behavior. The pairing with attach_stim_backend and related stim tools (arm_stim, disarm_stim, send_stim_train) suggests a lifecycle that the description fails to contextualize.

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 100%, so the schema documents both parameters (session_id and backend) well. The description adds the word 'attached' to clarify that backend refers to a previously attached backend, adding some meaning beyond the schema. However, it doesn't specify the backend name format, whether it must match exactly, or what happens if the backend name is invalid. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Close and remove a stimulation backend from a session' clearly identifies the verb (detach/close/remove), the resource (stimulation backend), and the scope (from a session). It distinguishes from the sibling detach_processor and attach_stim_backend tools by using consistent terminology (backend, session). Clear but could specify the state change more explicitly.

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. It doesn't mention prerequisites (e.g., backend must be attached first, stream stopped), nor does it name counterpart attach_stim_backend or contrast with disarm_stim for the parent-child relationship of operations. Context is implied by the 'detach' name but no explicit usage conditions are given.

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