Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Get Popup Window

sap_get_popup_window
Read-only

Detects whether a SAP GUI popup or modal dialog is open and returns its title, text, and available buttons, then classifies it and suggests a safe next action.

Instructions

Check if a popup/modal dialog is open (wnd[1], wnd[2], etc.).

Returns the popup's title, text content, and available buttons so you know how to respond. Also classifies the popup and suggests a safe next action. Returns {popup_exists: false} if no popup.

The popup's text is in texts: labels and display-only fields (a message popup's lines). A popup whose body is a classic list (an F4 hit list, a note, a message's long text) has list (cells, rows, hint) instead: its lines are never in texts or interactive_elements; read them with sap_read_list. Radio buttons and checkboxes in interactive_elements carry selected. texts, buttons and interactive_elements are left out when empty.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sap_get_popup_window"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), and the description adds substantial behavior beyond them: it returns {popup_exists: false} when no popup is present, classifies the popup and suggests a safe next action, and documents that empty collections are omitted from the response. The texts-vs-list body distinction is real behavioral detail an agent could not infer from annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Purpose is front-loaded in the first clause, followed by return semantics and then the field-presence rules; each block earns its place. The second paragraph is dense and slightly long for a zero-parameter read tool, but it carries genuinely non-obvious information (list body never in texts, selected flag on radio/checkbox).

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

Completeness5/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 need not enumerate return values, yet it covers the tricky cases an agent would otherwise get wrong: popup body as list vs. texts, omitted empty collections, and the pointer to sap_read_list. Nothing needed to call or interpret this tool correctly is missing.

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

Parameters4/5

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

There are zero parameters, so the baseline of 4 applies; nothing about invocation arguments needs explaining. The description correctly spends its space on return-shape semantics instead of inventing parameter discussion.

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 opens with a specific verb+resource: 'Check if a popup/modal dialog is open (wnd[1], wnd[2], etc.)', which is unambiguous about what the tool does and the SAP context it targets. It does not explicitly name the closest sibling, sap_handle_popup, to say how it differs (inspect vs. act), so the agent must infer that boundary.

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

Usage Guidelines3/5

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

Usage is only implied through the phrase 'so you know how to respond' and the note to read list-style popups with sap_read_list. There is no explicit when-to-use/when-not statement, and the relationship to sap_handle_popup (the obvious alternative for actually dismissing a popup) is never addressed.

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