Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Press Button

sap_press_button

Clicks a pushbutton or toolbar button on the current SAP screen and returns updated screen info so you can detect navigation, popups, or messages after the action.

Instructions

Press (click) a pushbutton or toolbar button on the current SAP screen.

Returns screen info after the press so you can detect navigation or popups. Use sap_get_toolbar_buttons to discover toolbar button IDs. Use sap_get_screen_elements to find on-screen button IDs. When screen info has message_has_long_text, pressing 'wnd[0]/sbar' opens that long text (Diagnosis / Procedure), usually as a list popup: read it with sap_read_list(window_id='wnd[1]').

A popup button is checked like sap_handle_popup's press: a press that may save, or any answer but Cancel to a popup question the tool cannot read, asks the user first (confirmed_by_user: true when accepted).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "button_id": "<button_id>"
    },
    "name": "sap_press_button"
  }
}

Input Schema

NameRequiredDescriptionDefault
button_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that the tool returns screen info, detects navigation or popups, may save data, and asks the user for confirmation in certain popup cases. This is strong behavioral context, though the confirmation sentence is convoluted and references a confirmed_by_user field not present in 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The front-loaded first sentence is clear, but later paragraphs are dense and the popup confirmation sentence is hard to parse. Some details, such as the long-text flow, are useful, but the overall structure could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values in detail. It covers prerequisites, side effects, confirmation behavior, and follow-up actions, though the confirmed_by_user reference and lack of ALV differentiation leave minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the single button_id parameter. It does provide discovery guidance and an example value ('wnd[0]/sbar'), but it also mentions confirmed_by_user, which is not in the input schema and may mislead about available parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: press a pushbutton or toolbar button on the current SAP screen. It distinguishes itself from discovery tools but does not explicitly differentiate from the similar sibling sap_press_alv_toolbar_button or state when to use sap_handle_popup instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit prerequisite workflows: use sap_get_toolbar_buttons or sap_get_screen_elements to find button IDs, and use sap_read_list for long-text popups. However, it does not clearly say when not to use this tool versus the ALV toolbar press or popup handler.

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

Deploy Server

Other Tools