MCP SAP GUI Server

Overview Schema Source Related Servers Discussions Admin

Sap Screenshot

sap_screenshot

Read-only

Captures the current SAP GUI window as an inline image or full-resolution PNG, providing a visual fallback when structured screen-reading tools return empty or confusing results.

Instructions

Take a screenshot of the current SAP window.

Use as a fallback when structured tools (sap_get_screen_elements, sap_read_field, sap_read_table) return empty or confusing results, e.g., on Web Dynpro screens where the element tree is non-standard.

To put a screenshot into a document, pass save_path (must end in .png, directory must exist, existing files are never overwritten). The file keeps SAP GUI's full resolution; the inline image is capped at 1920px. The response then also reports the absolute path and pixel size. Set inline=False to skip the image when only the file is needed.

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_screenshot"
  }
}

Input Schema

Name	Required	Description	Default
`inline`	No
`save_path`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.0Sep 21, 2026
- addedInput schema / properties / inline
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
- addedInput schema / properties / save_path
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
First observedv0.2.0May 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/destructive=false, and the description adds substantial non-obvious behavior: save_path must end in .png, the directory must already exist, existing files are never overwritten, the file keeps full SAP GUI resolution while the inline image is capped at 1920px, and the response reports the absolute path and pixel size. That is far beyond the annotation surface.

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

Conciseness5/5

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

Three short, front-loaded paragraphs: what it does, when to use it, then how to persist the result. Every sentence adds information or a constraint; nothing is redundant.

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?

No output schema exists, yet the description still describes the response payload (inline image, absolute path, pixel size, failure-free file behavior). For a two-optional-parameter read tool with annotations, an agent has everything needed to call it correctly.

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?

Schema description coverage is 0%, so the description carries the full burden and does: it documents save_path's format constraint (.png), directory precondition, no-overwrite behavior, and that it triggers path/pixel-size reporting, plus inline=False for file-only use. The only small gap is that the defaults (inline=true, save_path="") and the pure inline-only return case are implied rather than stated.

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

Purpose5/5

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

States a concrete verb and resource ('Take a screenshot of the current SAP window') and immediately frames it relative to the structured read siblings (sap_get_screen_elements, sap_read_field, sap_read_table). No ambiguity about what the tool returns.

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

Usage Guidelines5/5

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

Explicit when-to-use rule: fallback when structured tools return empty or confusing results, with a named scenario (Web Dynpro screens with non-standard element trees). It also states the specific condition for the save_path versus inline-only path, so the agent can choose its call shape without guessing.

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

Deploy Server