Write Classic ABAP Screen or GUI Status

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

Beyond the annotations, the description explains that the tool has a preview-first confirmation flow and that execution only happens with a confirmed resubmission. It also mentions an opt-in same-origin bridge, which is useful authorization context. It does not detail exactly what destructive side effects might occur, but the annotations already signal the destructive nature and the description explains the safegating mechanism.

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 a compact two-sentence explanation with no filler. It leads with the core action ('Preview or execute'), then immediately gives the operative rule for both modes. Every clause adds useful information.

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 destructive, non-idempotent write tool with zero schema parameters, the description gives the essential confirmation-flow and safety mechanism. An output schema exists, so the return format does not have to be repeated. It could be more complete with an explicit statement of what kinds of requests belong to this tool and what conditions should prevent execution, but the core flow is present.

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?

The input schema has no properties, so the description carries the burden of explaining how the tool is controlled. It says to omit confirmation for a preview and resubmit the returned exact value for execution, which is helpful operational guidance for a parameterless interface. It does not specify the actual write-payload format, preventing a higher score.

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 states the tool performs a preview or execute action on a Classic ABAP Screen/Dynpro or GUI Status write, which is a specific verb+resource combination. It is not a tautology and can be told apart from sap.classic.read and other sibling write tools, though it does not explicitly contrast itself with another sibling.

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 an explicit usage protocol: omit confirmation to preview, then resubmit the returned value to confirm/execute. This tells the agent when each mode of the tool should be used. It does not name alternatives or exclusions, but the two-phase preview/execute context is unusually clear.

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