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.

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

Goes well beyond the annotations: budgets (20 breakpoints, 50 stops), how hits in a loop replay one run, that the program is released and breakpoints removed after return, the 50 s call timeout with a running:true handoff, step-trace compaction, and the safety limits (never mutates variables or flow, never debugs system code). Nothing here contradicts readOnlyHint=false / destructiveHint=false.

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: the first sentence states the entire arm-run-inspect-release cycle, and the paragraphs move from model to limits to result to the timeout handoff. It is dense and a few clauses restate schema content (e.g. the abap_source line-numbering rule), but for a 17-parameter tool with no output schema the length is largely earned.

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, so the description compensates with a full "Result:" breakdown (hit, breakpoints, debuggee, stops, stack/variables, steps vs trace, release, trigger, warnings) plus the no-stop failure shape and the running:true partial-result contract. Combined with 100% schema coverage, an agent has everything needed to call and interpret it.

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 coverage is 100%, so field-level meaning is already carried; the description still adds cross-parameter semantics the schema cannot, e.g. that variables must be declared up front because the run is released, how steps/until/maxSeconds/maxResultKB interact, and that breakpoint hits are what produce multiple stops. It stops short of explaining every field, which the schema already does.

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?

Opens with a specific verb and resource ("Debug ABAP code on the connected SAP system in ONE call") and explicitly frames the one-shot capture model against the sibling interactive model (abap_debug_session). An agent can distinguish it from abap_debug_session and abap_breakpoints without opening any schema.

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?

Explicitly names when to use it (one-shot capture), when to use the alternative (interactive: true plus abap_debug_session for per-move decisions), and points to abap_source for line numbering. It also states preconditions and refusals: only the session's own SAP user, refuses if Eclipse or VS Code is already debugging that user.

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

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

Beyond the annotations, the description discloses the critical runtime traits: the program waits in a work process between calls, calls exceeding ABAP_DEBUGGER_CALL_SECONDS return running: true and continue in the background, sessions are released after ABAP_DEBUGGER_IDLE_SECONDS (120 s) and ABAP_DEBUGGER_SESSION_SECONDS (15 min), and every answer reports remaining time. It also scopes side effects precisely — 'Apart from terminate, it never changes variables or the program's flow' — and notes that terminate aborts before commit and rolls back open database changes, which is consistent with readOnlyHint=false / destructiveHint=false.

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 purpose and the action menu are front-loaded and each action line earns its place for a six-action, fifteen-parameter tool. It is dense and uses line-broken em-dash fragments that make the first sentence harder to parse than necessary, but there is little filler.

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?

With no output schema, the description carries the burden well: it explains what each answer contains (position, surrounding code, watched variables, remaining session time, running: true for backgrounded calls) and covers the full session lifecycle including expiry and termination consequences. Nothing an agent needs to drive the session correctly appears to be missing.

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 coverage is already 100%, so the baseline is 3, but the description adds genuine cross-parameter meaning: count above 20 returns a compact trace, until ends stepping early on a line or a variable change, variables 'replacing the ones named before' across step/continue, and terminate causing rollback. It does not restate the numeric defaults for every bound (maxSeconds, maxResultKB, timeoutSeconds), leaving those entirely to the schema.

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 specific verb and resource — advancing an interactive ABAP debug session one move and returning position, surrounding code and watched variables — and explicitly ties it to the sibling that creates the capture ('abap_debug with interactive: true'), so an agent can tell the two apart. The opening sentence is convoluted ('One move of the program an interactive capture holds'), which slightly obscures the purpose until the per-action list clarifies it.

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?

Every action is given an explicit when-to-use: step for statement-by-statement (with stepMode/count/until), continue for running to the next breakpoint/watchpoint or toLine, inspect for reading variables and the call stack, watch for setting a watchpoint, wait for retrieving an answer that returned running: true, end for closing the session. It also states the operational rule 'end the session when you are done', naming the alternative (idle/session expiry) if you don't.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful return-value context ('exact name, type, what it is, package and description') and search examples, though it does not discuss rate limits, auth, or pagination.

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 definition is front-loaded and has only two sentences, but the first sentence is a dense enumeration of object types and return fields. The examples earn their place, though the description could be slightly easier to scan.

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?

Given rich annotations, full schema coverage, and no output schema, the description supplies what an agent needs: search scope, object-type coverage, return fields, and representative use cases. Nothing essential for correct invocation is missing.

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 schema already documents query patterns, type filtering, package filtering, maxResults, and includeTechnical. The description reiterates some query semantics but adds no meaningful parameter guidance beyond the schema.

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 opens with a specific verb and resource: 'Find repository objects of any type by name...' and enumerates the object types covered. This makes the tool's scope clear and distinct from the debugging and source-code siblings.

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?

It provides concrete usage examples, such as finding the service binding and definition behind a Fiori app or the unit-test class to use as triggerName. It does not explicitly state when to use this instead of abap_source or another sibling, but the discovery context is clear.

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

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

Annotations already declare read-only, idempotent and non-destructive behavior, and the description adds meaningful context beyond them: only ACTIVE source is returned, line numbers match abap_debug breakpoints, and SRVB returns its service definitions. It does not discuss error behavior for inactive or missing objects, but the active-only and line-number semantics are valuable.

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 appropriately sized and front-loads the core resource. The first sentence is somewhat convoluted due to the colon-and-dash construction, but the later sentences add useful usage and parameter context without excess.

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 seven-parameter read tool with full schema coverage and annotations, the description supplies the critical behavioral context: active-only source, supported object types, line-number alignment, and the SRVB/Fiori follow chain. It could say more about return shape or missing/inactive object handling, but is largely complete.

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 coverage is 100%, so parameter meanings are already well documented in the input schema. The description reinforces that method, lineStart/lineEnd and grep narrow the source and mentions the abap_debug line-number convention, but adds little beyond the structured parameter definitions.

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 clearly identifies the resource: ACTIVE ABAP source for classes, programs, function modules, interfaces, includes, CDS views, behavior definitions, service definitions and bindings. It adds a useful qualifier, line numbers aligned with abap_debug breakpoints, but does not explicitly distinguish itself from siblings such as abap_search.

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?

Usage is implied through the Fiori debugging flow and the suggestion to narrow source with method, lineStart/lineEnd or grep. However, it does not explicitly say when to use abap_source instead of abap_search or abap_debug, so an agent must infer the boundary.

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