Set ABAP Debugger Breakpoint

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

Annotations only provide hints (readOnly=false, openWorld=true, etc.), so the description carries the burden of behavioral disclosure. It delivers extensive context: the FULL-SET SYNC write semantics and restart consequence, best-effort condition handling, the generated-include line mapping, the persistence table, and the requirement for an armed listener. This goes far beyond what the annotations convey.

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 front-loaded with the core purpose, then organized into Args, Returns, Examples, and Notes. Every sentence serves a purpose — behavioral caveats, workflow prerequisites, and parameter mapping — with no filler or repetition. Length is justified by the tool's complexity.

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 the absence of an output schema, the description explains the JSON return shape and the important line-number mapping caveat. It also covers persistence, session requirements, and user keying. For a setter tool with subtle side effects, nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by correlating natural-language examples ('Break on ZTEST line 42') to concrete parameter assignments and by explaining the function_group requirement and the condition caveat. This is meaningful enrichment over the structured 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 uses a specific verb-resource pair ('Set an external (ADT) breakpoint at a line in an ABAP object') and adds the user-scoping qualifier, which distinguishes it from sibling breakpoint tools like sap_list_breakpoints and sap_delete_breakpoints. The sentence about trapping execution only while a listener is armed further clarifies its distinct role.

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 gives clear operational context: breakpoints persist but only trap when a listener is armed, and it explicitly instructs to call sap_debug_attach then sap_debug_wait. It also explains the user-keying prerequisite for trapping another user's execution. It doesn't explicitly name alternatives for when to use a different tool, but the workflow guidance is sufficient for correct use.

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