sap_send_key

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

Beyond the annotations, the description discloses the inactive-key failure mode and the exact response field (available_keys) for recovery, plus the F11/Save elicitation flow and the confirmed_by_user response flag. These are concrete behavioral traits an agent could not infer from readOnlyHint=false/destructiveHint=false.

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?

Three short blocks, front-loaded with the core action, then key meanings, then failure/confirmation behavior. Every sentence earns its place, though the 'Common keys' enumeration partially restates enum members rather than adding new meaning for all of them.

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 an output schema present, return-value documentation is not required, and the description still flags the two response fields an agent must react to. It covers failure and confirmation paths well; the only gap is that it never mentions session/connection prerequisites despite sap_connect and sap_connect_existing being siblings.

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%, so the description carries the burden and largely does: it explains the semantics of most enum values (Enter=confirm, F3=Back, F4=value help, F8=Execute, F11=Save, F12=Cancel) and names the Shift+/Ctrl+ variants. It leaves F2, F6, F7, F9, F10 and the Shift+F1..F9 behaviors unexplained, so the mapping is incomplete for a 30-value enum.

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 names a specific verb+resource ('Press a keyboard key / function key in the SAP window') and disambiguates the keyboard-input surface from mouse-oriented siblings like sap_press_button or sap_select_menu. It stops short of naming an alternative explicitly, but the scope 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?

It gives practical context (what each common key does, standard Enter/F3/F8/F12 flows) and a useful failure/recovery note about inactive keys returning available_keys. However, it never states when to prefer this tool over sap_press_button, sap_select_menu, or sap_execute_transaction, so routing guidance is only implied.

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