abap_img_edit

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

Annotations declare readOnlyHint=true and destructiveHint=false, which the description contradicts by claiming the tool writes rows. The description also asserts the tool is 'LOCKED' and 'returns a refusal,' which is a behavioral claim, but it muddles rather than clarifies the safety profile. It does disclose the configuration variable as the deciding factor, which is one useful nugget, but the core behavioral claim conflicts with the structured metadata.

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 first sentence is reasonable, but the rest of a five-sentence passage is spent unpacking one environment variable. The parenthetical about ABAP_ALLOW_PACKAGES is rambling and contains meta-commentary about defaults. The structure buries the operational instruction (set a flag to unlock) inside explanatory noise.

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 zero-parameter tool with annotations, the description should be crisp. Instead, it is incomplete because it never clearly states the tool's effect when unlocked, nor why it would be preferable to abap_img. It provides a postcondition ('returns a refusal and sends nothing') only for the locked state, omitting the primary behavior.

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?

With 0 parameters in the schema, the baseline is 4. The description does not invent nonexistent parameters, and the mention of ABAP_ALLOW_WRITE is environment configuration rather than tool input. However, the description never states that this tool takes no parameters, which could confuse an agent and is a missed opportunity.

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 'Preview and write IMG/customizing table rows,' which gestures at a purpose, but it immediately abandons that to discuss configuration flags. It pairs 'preview' and 'write' as a single verb phrase, which is confusing, and it never states what the tool actually does when it's not refusing. It sits next to abap_img, abap_bopf_edit, and abap_write without explaining the distinction.

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 explains the environmental precondition (ABAP_ALLOW_WRITE=true) but does not say when an agent should prefer this over abap_img or abap_write, which are the obvious siblings. There is no 'when to use' or 'when not to use' guidance beyond the lock state. The reader learns that it will refuse, but not what the intended use case is.

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