Sap Set Textedit

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds little beyond that: it does not say whether existing editor content is replaced or appended, or what happens if textedit_id is invalid — the most consequential behavioral detail for a write-text tool.

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?

Two short lines, front-loaded with the verb and target widget, with no filler. The trailing example list is slightly redundant but genuinely narrows intent.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, for a mutation with two fully undocumented parameters, the description should at least explain how to obtain textedit_id and whether the write replaces content.

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 description coverage is 0%, so the description must compensate and does not. It never explains what textedit_id refers to (e.g., an element ID from sap_get_screen_info) or whether 'text' overwrites the current value, leaving both required parameters semantically bare.

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?

States a specific verb and resource: 'Write text into a multiline text editor (GuiTextedit)'. The 'multiline' qualifier implicitly separates it from sap_set_field and pairs it with sap_read_textedit, though no sibling is named explicitly.

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 examples ('long texts, notes, comments, document text') imply the scenario, making usage inferable rather than explicit. It never says when to use sap_set_field instead, nor any preconditions such as focusing or locating the element first.

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