bw_add_process_chain_error_links

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It discloses the in-place edit pattern (read, modify, PUT), idempotency (skipping existing edges), optional activation, and ETag handling. This provides sufficient transparency beyond the schema.

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 single paragraph with multiple sentences, each providing essential information. It front-loads the main action. While it could be broken into bullet points for readability, it remains concise and informative without wasted words.

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 tool's complexity (mutation with side effects), no output schema, and 4 parameters, the description covers the process (read-modify-write), parameter usage, error handling, and activation. It lacks explicit return value details, but the overall context is sufficient for an agent to use it effectively.

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%, but the description adds significant value beyond the schema: it explains how `dtps` matches (exact DTP name or substring of step description), that `name` is case-insensitive, that `activate` defaults to false, and the transport request logic. This detail helps the agent use parameters correctly.

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's purpose: adding on-error links to a Process Chain by mirroring existing on-success links from DTP load steps. It uses specific verbs ('Add', 'mirroring') and identifies the resource ('Process Chain (RSPC)') and method (via BW/4HANA Cockpit REST API). It is distinct from sibling tools which deal with different operations on process chains.

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 when to use the `dtps` parameter to restrict to specific steps or omit to apply to all DTP load steps. It also mentions handling of ETag staleness with a 412 error. While it does not explicitly state when not to use the tool or provide alternative tools, the usage context is clear enough.

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