abap_bopf_test

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), and the description adds genuinely non-obvious context: the server-side lock, the ABAP_ALLOW_WRITE gate, and that a call produces a refusal with no SAP traffic. However, the headline claim of 'writing real rows' pulls against the read-only/idempotent annotations and muddies rather than clarifies the real behavior.

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 text front-loads a purpose line, then spends most of its length on environment-variable plumbing ('ABAP_ALLOW_PACKAGES is optional — it narrows the default, which is every package'), which does not earn its place for an agent that cannot set those variables. The result is dense and roundabout rather than crisp.

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 no output schema the description does explain the effective outcome of a call (refusal, no SAP traffic), which is the key behavior. But it omits any sibling routing and never resolves whether the tool is meant to be invoked at all on this locked server, leaving the agent without a decision rule.

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 tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on inputs, and it correctly avoids inventing parameters.

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 opening clause 'Run a BOPF business object end to end, writing real rows' gives a verb and resource, but it is immediately undercut by the later statement that calling it 'returns a refusal and sends nothing to the SAP system,' leaving the agent unsure whether this tool writes or is a no-op. It also never differentiates itself from close siblings like abap_bopf, abap_bopf_edit, or abap_bopf_delete.

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 configuration advice (set ABAP_ALLOW_WRITE=true) rather than usage guidance — it never says when to prefer this over abap_bopf, abap_bopf_edit, or abap_bopf_delete. The one implicit steer, that the tool is LOCKED on this server, is useful but is framed as operator setup, not agent decision guidance.

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