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

With no annotations present, the description carries the full behavioral burden, and it does disclose the key risk that unsaved work in that transaction can be lost — valuable and non-obvious. However, it does not say what happens if no transaction is active, whether the call is idempotent, or whether ending commits or discards pending changes.

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 sentences with no waste. The scope constraint leads and the loss-of-work warning is placed where it will actually be read before invoking, so every clause earns its place.

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, no-output-schema tool this is nearly sufficient: scope plus the destructive consequence are both covered. The remaining gap is the no-active-transaction / error behavior, which is minor given the tool's simplicity.

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 zero parameters, so the schema has nothing that needs compensating for; the baseline for a no-argument tool applies. The description's session-scoping language ('the configured session's') usefully clarifies that the target is implicit rather than passed in.

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 states a specific verb and resource ('End ... current transaction') and narrows scope to 'the configured session's current transaction,' which meaningfully differentiates it from the other transaction sibling. It stops short of naming launch_transaction as its counterpart, so the pairing must be inferred from the sibling list rather than the description.

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?

Usage is implied rather than stated: the agent can infer this is how a transaction session is closed, and the 'configured session' constraint hints at a prerequisite. There is no explicit guidance on when to end versus leave a transaction open, and launch_transaction is never referenced as the alternative.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does add one useful trait ("preserves unrelated SAP sessions"), but says nothing about what happens to an already-open transaction in the same session, permission/auth requirements, or execution side effects.

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?

A single front-loaded clause with no filler or repetition; it is well-structured. Its brevity is closer to under-specification than to wasteful padding, but as sizing/structure goes it is efficient.

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?

With no annotations, no output schema, and 0% parameter documentation, the description is too thin for a 3-parameter action tool. The one session-preservation note is a good start but leaves the agent missing parameter format, side effects, and return 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?

Schema description coverage is 0% across 3 parameters. The description hints at the transaction argument but never states the expected format (e.g., SAP transaction code), and completely ignores return_screenshot and as_file_target_folder, so it does not compensate for the schema gap.

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 ("Start a transaction") plus a scoping clause ("in the configured session"), which cleanly pairs with the sibling end_transaction. It does not explicitly name alternatives, but the action is unambiguous.

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 no when-to-use/when-not guidance and no prerequisites, such as whether a session must already be configured or whether this can be called mid-transaction. The only routing signal is implicit from the sibling name end_transaction.

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

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

With no annotations, the description carries the full behavioral burden, yet it only discloses the coordinate origin. It says nothing about focus/window requirements, mouse-down/up timing, whether the click has irreversible side effects in the SAP UI, or what the return_screenshot options do.

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?

A single front-loaded sentence with no filler — the scoping detail comes first. It is arguably under-specified rather than overly long, but on pure conciseness it is efficient.

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 4-parameter, zero-annotation, no-output-schema tool, one sentence is insufficient: the screenshot-return mechanism and folder target are unexplained, and no side-effect or failure behavior is described.

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 phrase 'physical screenshot pixels relative to the selected SAP window' effectively defines x and y, which is real added value over a 0%-coverage schema. However, return_screenshot (5 enum options) and as_file_target_folder are entirely undocumented, including the evident dependency of the folder parameter on return_screenshot='as_file'.

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?

A specific verb (click) on a specific resource (screenshot pixels) with the coordinate frame named ('relative to the selected SAP window'), which meaningfully distinguishes it from sap_move_mouse and coordinate-free input tools like sap_type/sap_press. It does not, however, name or contrast with any sibling tool.

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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as sap_press, sap_set_field, or sap_send_vkey for element-level interaction. The agent must infer that this is the fallback for pixel-precise clicking.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely non-obvious behavior: password fields are redacted and control enumeration is capped at 300. It doesn't say what happens when a screen exceeds 300 controls, which keeps it short of a 5.

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?

One tight sentence that front-loads the verb, resource, and scope cap, then appends the optional screenshot clause. Every element earns its place with no filler.

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 read-only tool with no output schema, the agent is told what is read and that passwords are masked, but not the shape of the result, how controls are represented, or how the screenshot modes interact with as_file_target_folder. Adequate, but real gaps remain for a 2-param call.

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 carries the full burden for two parameters. It alludes to an optional screenshot but never explains the five enum modes (none/as_file/as_base64/as_imagecontent/as_imageurl) or the role of as_file_target_folder, leaving the main parameter largely opaque.

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 (Read) and resource (SAP COM controls and text) with a concrete scope cap (up to 300) and a redaction behavior baked into the purpose itself. Against siblings like sap_click, sap_type, and sap_press, which mutate the screen, this is unambiguously the read-side tool.

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?

No when-to-use guidance at all: it doesn't say to call this before inspecting state, before/after a click, or in relation to save_last_screenshot or launch_transaction. The word 'optionally' is the only hint, and it applies to a parameter rather than to tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether moving the mouse has side effects, whether the operation is instant or animated, whether permissions are needed, or what happens to the cursor position on failure. The only behavioral clue is the coordinate system ('physical screenshot pixels').

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 tight sentence that front-loads the action and coordinate system. It contains no filler and is appropriately sized for a brief summary, though it could be slightly more structured with prerequisite or return details.

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?

With no annotations, no output schema, and four parameters including an enum and a conditional folder argument, the description is substantially incomplete. It covers only the coordinate system for x and y, leaving return_screenshot behavior, as_file_target_folder conditions, and invocation prerequisites entirely unexplained.

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 for all parameters. It clarifies that x and y are in 'physical screenshot pixels', which is useful, but it says nothing about the return_screenshot enum options, its default of 'none', or when as_file_target_folder applies. Two of four parameters receive no semantic explanation.

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 states a specific action ('Move') and target ('within the selected SAP window') with a clear coordinate system ('physical screenshot pixels'). It distinguishes itself from sibling tools like sap_click and sap_scroll by describing pointer movement rather than clicking or scrolling, though it does not explicitly name alternatives.

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?

There is no guidance on when to use this tool versus alternatives such as sap_click or sap_get_screen. It also omits prerequisites like whether the SAP window must already be selected or focused. Usage is only implied by the tool name and the brief description.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing: pressing a GUI button can trigger screen changes, dialogs, or committed transactions, but none of that is mentioned. There is no note on permissions, error behavior, or whether a screenshot/refresh is needed afterward.

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?

A single well-formed sentence with no filler and the action front-loaded. It is efficient, though borderline under-specified rather than genuinely concise.

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 one-parameter automation tool with no annotations and no output schema, the description omits the two things an agent most needs: what element_id refers to and how it differs from sap_click. The overlap with other interaction siblings is left unresolved.

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% for the single required 'element_id' parameter (minLength 6, maxLength 1024). The description does not explain what an element_id is, where to obtain it (e.g., from sap_get_screen), or what format it takes, so the parameter is effectively undocumented.

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 ('Press') and resource ('SAP GUI button') plus the mechanism ('through its COM interface'), which is enough to identify the action. However it does not distinguish itself from the sibling tool sap_click, which appears to serve an overlapping purpose, leaving the agent to guess which to use.

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 no guidance on when to prefer this over sap_click, sap_send_vkey, or sap_run_guixt_script. There are no prerequisites, no mention of requiring an active transaction, and no stated conditions under which pressing is appropriate.

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

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

With no annotations at all, the description carries full burden and does disclose two important traits: the GuiXT opt-in/auth precondition and that 'Completion is asynchronous'. What it omits is whether the script can mutate or destroy SAP state and what happens on a failed script run, so the behavioral picture is good but not complete.

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?

One dense sentence, semicolon-separated into three clauses, front-loaded with the action and resource. Every clause (what, precondition, async nature) earns its place with no filler.

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 one-parameter, annotation-free tool with no output schema, the description covers action, target, precondition and async behavior, which is nearly everything an agent needs. The remaining gap is that it doesn't hint how to observe completion (e.g. via sap_get_screen) after the asynchronous submit.

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 0% for the single required 'script' parameter, so the description must compensate. It adds meaningful semantics by calling it a 'preinstalled' script (i.e. a name of an existing script, not a path or inline content), but it never clarifies the naming/format rules implied by the schema pattern (alphanumerics, underscore/hyphen, .txt suffix).

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 (Submit) and resource (a preinstalled GuiXT InputScript) scoped to 'this exact SAP window', which is clearly distinct from the low-level siblings like sap_click, sap_type and sap_press. It stops short of naming an alternative or contrasting explicitly with them, so it is clear but not maximally differentiating.

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 prerequisite 'requires configured GuiXT opt-in' gives real context for when this tool will work, and 'preinstalled' implies the script must already exist. However, there is no guidance on when to prefer a GuiXT script over the sibling primitives (sap_type/sap_click/sap_send_vkey), leaving the choice to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only restates the action. It does not disclose scroll granularity, whether it blocks, what 'selected window' means, or how the screenshot options affect behavior. This is thin for a tool with a required enum direction and four screenshot modes.

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?

A single front-loaded sentence with no padding. It is efficiently sized, though the brevity reflects under-specification rather than true economy.

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?

With no annotations, no output schema, and three parameters (two enums, one a file-path dependent on a screenshot mode) at 0% schema coverage, the description is far too thin. An agent cannot determine scroll amount, timing, or how to correctly use the screenshot outputs.

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 is responsible for explaining parameters and adds nothing. The complex return_screenshot modes (as_file/as_base64/as_imagecontent/as_imageurl) and their interaction with as_file_target_folder are left entirely undocumented, and the relationship between direction and the visible viewport is unexplained.

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 states a specific verb ('Scroll') and resource ('the selected SAP window'), clearly distinguishing it from action siblings like sap_click, sap_type and sap_press. It does not, however, explain how scrolling relates to the other navigation tools, so it earns a solid 4 rather than a 5.

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?

There is no guidance on when to scroll versus using another tool such as sap_press or sap_send_vkey, nor any prerequisites (e.g. whether a window must be selected first). Usage is only weakly implied by the tool name.

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

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

No annotations are provided, so the description carries the full disclosure burden. It never states what happens on failure (e.g. no session configured), what the response contains, or whether the call mutates UI state, which it clearly does. The only behavioral hint is the parenthetical that 0 maps to Enter.

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?

One tight sentence with no wasted words, and the key-mapping detail is placed inline where it is most useful. It is short to the point of under-specification rather than bloated, so it earns most of its space.

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 mutation-style input tool with no annotations and no output schema, the description omits critical context: how the target session is established, what a successful or failed send looks like, and how to find the key-code table it references. An agent cannot reliably call this without that information.

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 0% and the single integer parameter (0-134) is undocumented in the schema, so the description must compensate. It partially does by saying it is a documented SAP virtual key and giving one concrete mapping (0 = Enter), but 133 other codes and the notion of 'documented' are left unexplained.

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 gives a specific verb and resource: sending a virtual key code to the configured SAP session. That is enough to understand what it does, but it does not differentiate itself from the sibling sap_press, which plausibly also sends keystrokes, leaving the agent to guess which key-sending tool applies.

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?

There is no guidance on when to use this versus sap_press, sap_type, or sap_click, and no stated prerequisite such as an active session being required. The only implicit context is 'configured session', which the agent must infer.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the execution mechanism and window scoping, but says nothing about whether setting text fires SAP events/validations, what happens on an invalid element_id, permissions, or error/reversibility behavior for this mutation.

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?

A single front-loaded sentence with no filler, and the most important fact (setting text) leads. It is compact, though 'through SAP GUI ActiveX/COM scripting' is implementation detail that consumes space without helping selection.

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?

With no annotations, no output schema, and 0% parameter coverage, the description should compensate substantially. Instead it provides one sentence, leaving the agent without guidance on the element_id format, failure modes, or side effects — insufficient for a 2-parameter mutation tool.

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 neither element_id nor text is documented in structured data. The description's phrase 'literal text' loosely maps to the text parameter but gives no format, encoding, or length guidance, and element_id — the most opaque parameter — is not explained at all.

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 ('Set') and resource ('literal text') plus the mechanism (SAP GUI ActiveX/COM scripting) and scope (wnd[N] in this session). It clearly differentiates itself from sibling sap_type by emphasizing 'literal' value-setting, though it does not explicitly name that 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?

Usage is only implied: 'literal text' hints at direct value assignment versus the keystroke emulation of sap_type, and 'scoped to wnd[N]' hints at the targeting context. There is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings.

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

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

With no annotations, the description carries the full behavioral burden. It implies keys go to the currently selected window (a real risk if focus is wrong) but says nothing about whether existing field content is overwritten, permission/focus requirements, or how the operation reports success or failure.

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, front-loaded sentences with zero filler; the primary purpose leads and the disambiguation follows immediately.

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?

No output schema and no annotations, yet the description omits focus prerequisites, overwrite behavior, and any explanation of the two screenshot parameters. For a 3-parameter interaction tool this leaves significant gaps an agent must guess at.

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% for 3 parameters, and the description only hints at the 'text' parameter semantics ('text/special keys'). The screenshot-related parameters (return_screenshot, as_file_target_folder) are undocumented in both schema and description, so no compensation occurs.

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 states a specific verb (Type) and mechanism (WScript SendKeys) targeting a defined resource (the selected SAP window), and explicitly contrasts itself with the sap_set_field sibling. An agent can distinguish this from sap_set_field and sap_press without opening any schema.

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?

It gives one explicit routing rule: use sap_set_field for literal text, implying this tool is for special/non-literal keys. It does not state prerequisites (window must be focused/selected) or when NOT to use it, but the alternative is named concretely.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: output is written under SAP_OUTPUT_ROOT and existing files are not overwritten. However, it is ambiguous about the collision case — does it error, append a suffix, or refuse? — and says nothing about permissions or return 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?

A single efficient sentence with the destination and the no-overwrite rule front-loaded; no filler. It is tight, though the brevity contributes to the unresolved ambiguities noted elsewhere.

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 one-parameter tool with no output schema and no annotations, the description covers the core action and one behavioral constraint but leaves key operational questions unanswered: the resulting file path/return value, collision behavior, and when the tool is appropriate. Adequate but with clear gaps.

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% and the description adds no meaning for the sole 'filename' parameter — no extension handling, path semantics, or how the name interacts with the no-overwrite rule (e.g., whether SAP_OUTPUT_ROOT is prepended). The parameter is only self-explanatory by convention.

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 (Save) and resource (the last requested screenshot) plus the destination root, SAP_OUTPUT_ROOT, and the no-overwrite constraint. It is clearly distinguishable from siblings like sap_get_screen or sap_press, though it never names an alternative to sharpen 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 phrase 'last requested screenshot' hints at a prerequisite (a prior screenshot request) but the description never states when to use this tool versus sap_get_screen or what happens if no screenshot has been requested. No exclusions, prerequisites, or alternatives are given.

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