List or remove what the debugger left for your SAP user

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

Annotations already declare non-readonly, idempotent, non-destructive, open-world. The description adds real substance on top: leftovers exist because the capture's server process was killed or SAP refused removal, the next capture clears them anyway, a crashed capture leaves a listener for up to two minutes during which every capture is refused, and 'listener: true' removes the listener by SAP user, including Eclipse's or VS Code's if someone debugs as you. That is exactly the blast-radius info an agent needs before calling delete. Note it does soften the picture versus destructiveHint=false — delete ends the user's capture/session and can knock out another IDE's listener — but that is state cleanup rather than data destruction, so it is a nuance rather than a contradiction.

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?

Front-loaded with per-action labels and zero filler sentences; every clause carries information. The prose is densely packed with em-dashes and nested parentheticals, which makes it harder to scan than it needs to be, so it is efficient but not clean.

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?

No output schema exists, and the description does describe what 'list' returns (capture/session breakpoints, unremovable leftovers, listener presence). It also flags the external-scope caveat about Eclipse-local breakpoints. What is missing is anything about failure modes or required permissions for delete — e.g. what happens if the capture is already gone.

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% and the enum values are already documented in the schema with nearly the same wording, so the description is largely restating structured data. The 'listener' explanation (two-minute stale listener window, removal by user affects other IDEs) mirrors the schema text rather than extending it. Baseline 3 applies when 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 names the concrete resource (breakpoints a capture could not remove, plus debugger listener registration for the user) and separates the two actions with explicit 'list:' and 'delete:' prefixes. It also states a real limitation ('SAP has no request that lists every breakpoint of a user: Eclipse's own are in Eclipse'), which keeps an agent from expecting this tool to surface IDE-local breakpoints — something the sibling names (abap_debug, abap_debug_session) don't make obvious.

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 trigger conditions are explicit and operational: 'Use it when a capture is refused because a debugger listens, or the user's requests stop at odd places.' That maps a symptom to the tool. It does not explicitly say when NOT to use it or name sibling tools like abap_debug_session as the alternative once the leftovers are cleared, so it stops 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.