The recent release of mcp-sap-gui on PyPI marks a notable step forward for intelligent automation within SAP environments. By exposing an MCP (Model Context Protocol) server that talks directly to the SAP GUI Scripting API, the package lets AI assistants manipulate SAP screens with the same precision a seasoned consultant would use, but without the need for brittle screen‑scraping or OCR workarounds. This development arrives at a time when enterprises are looking to embed generative AI into core business processes, yet they still rely heavily on SAP ERP for finance, logistics, and human resources. The ability to drive SAP GUI programmatically through a standardized protocol opens the door to copilot‑style experiences that can guide users through complex transactions, validate data entry in real time, and even generate audit trails automatically. Moreover, the server’s design is intentionally client‑agnostic, meaning any MCP‑compatible tool—whether it is Claude Code, GitHub Copilot, Gemini CLI, or a custom internal agent—can tap into the same functionality. In the sections that follow we will explore how the server works, what safeguards it puts in place, and why Basis teams should consider enabling SAP GUI Scripting in a controlled fashion to unlock these AI‑driven capabilities.
At its heart, the Model Context Protocol is a simple yet powerful idea: decouple the reasoning engine of an AI assistant from the specific tools it needs to act upon. Instead of hard‑coding API calls for each system, an MCP client launches a local server over standard input/output and exchanges JSON‑RPC messages that describe the desired action and its parameters. The server then translates those generic requests into system‑specific operations—in this case, calls into the SAP GUI Scripting COM interface. This indirection brings several benefits. First, it allows the same AI model to work across disparate environments without retraining; the model learns to issue MCP commands, and the server handles the translation. Second, it centralizes security, logging, and policy enforcement in one place, reducing the surface area for mistakes. Third, it makes it easy to swap out or upgrade the underlying automation library without touching the AI client. For SAP GUI, the protocol is especially valuable because the native Windows UI Automation layer cannot reliably interact with the custom dynpro canvas; only the Scripting API provides a structured hierarchy of windows, menus, tables, and fields. By wrapping that API in an MCP server, mcp-sap-gui gives AI assistants a safe, controllable way to read data, populate forms, trigger transactions, and navigate the SAP landscape exactly as a human user would, but with the added benefit of automated oversight.
Getting started with mcp-sap-gui is deliberately frictionless. The package is published on PyPI, and the recommended installation method uses uvx, which creates an isolated, temporary environment on demand and runs the server without leaving any permanent footprint. A typical launch line looks like `uvx mcp-sap-gui[screenshots]`, where the optional screenshots extra adds a lightweight image‑optimization step that cuts screen captures by 70‑90 %, making preview cards faster to transmit and less bandwidth‑hungry. Because the server communicates over stdio, there is no need to open ports, configure firewalls, or manage TLS certificates; the MCP client simply spawns the process and talks to it via stdin and stdout. This approach sidesteps many of the operational headaches that traditionally accompany remote automation services. For developers who prefer to work from a source checkout, the project also supports a conventional `uv run` invocation, though Windows users should be aware of file‑locking nuances when native DLLs are involved—stopping the MCP client before performing dependency updates avoids “Access is denied” errors. The server deliberately avoids accepting passwords as tool parameters; instead, it expects the user to log in manually first or to rely on single‑sign‑on, after which the `sap_connect_existing` tool can attach to an already authenticated session. This design reduces the risk of credentials leaking into logs, tool histories, or audit trails, a point we will revisit when discussing security best practices.
Security and user consent are woven into the fabric of mcp-sap-gui. One of the most visible additions in version 0.5.2 is the sap_preview tool, which acts as a controllable checkpoint before any mutating operation. When invoked, the agent captures the current screen, reads the values that are about to be written (masking anything that looks like a password), and presents that information to the human operator. In environments that support the MCP Apps UI extension—such as VS Code Copilot Chat—the preview appears as a rich inline card with a screenshot and a tidy table of pending changes; elsewhere the same data is rendered as plain text accompanied by the image. The user can then approve, modify, or cancel the action, and the server will only proceed after an explicit go‑ahead. Complementing this, the confirmation‑points mechanism lets administrators or power users define categories of write operations—such as individual field edits, batch updates, transaction starts, or saves—that must be gated by a manual prompt. Once a point is activated, the server’s middleware intercepts every call that matches the category and blocks it until the user confirms via MCP elicitation. If the client does not support elicitation, the call fails closed, ensuring that no unintended data modification can slip through. Declines are recorded in the audit log, giving administrators a clear trace of who blocked what and why. Together, preview cards and confirmation points create a layered defense model that balances automation speed with governance rigor.
For the server to function, SAP GUI Scripting must be enabled on both the client side (the Windows SAP GUI installation) and the server side (the SAP NetWeaver ABAP system). On the client, users navigate to SAP GUI Options → Accessibility & Scripting and check the box that enables scripting. On the server, the Basis team activates the feature via transaction RZ11 or through the profile parameter `sapgui/user_scripting`. It is important to note that many organizations disable scripting globally as a hardening measure, fearing that it could be abused for data exfiltration or unintended automation. However, SAP provides a graduated control model that allows scripting to be turned on for specific users, roles, or even specific transactions, while leaving it off for the remainder of the landscape. This granularity is especially useful when proposing mcp-sap-gui to security stakeholders: you can pilot the assistant on a development system or a sandbox client where only a handful of power users have scripting enabled, thereby limiting exposure. When discussing the effort with a Basis team, emphasize that the Scripting API is the only reliable way to read and write dynpro screens; alternatives that rely on Windows UI Automation or OCR are notoriously fragile, prone to breaking with theme changes, and often fail to capture contextual information such as table headers or tooltip text. By enabling scripting in a controlled, auditable fashion, organizations gain a secure bridge for AI‑driven process improvement without resorting to error‑prone workarounds.
Installation and operational tips differ slightly depending on whether you are using the pre‑built PyPI package or working from a source checkout. The uvx approach is the simplest: the command downloads the appropriate wheel, creates a virtual environment in the user’s cache, launches the server, and tears everything down when the MCP client exits. Because each uvx invocation gets its own cache, multiple MCP clients can run simultaneously without interfering with one another—a crucial detail for environments where developers might be experimenting with Claude Code in one terminal while a CI pipeline invokes GitHub Copilot in another. If you prefer to hack on the code directly, clone the repository and use `uv sync` to set up the development environment. Windows users should keep in mind that while the server is active, its process holds locks on native DLLs such as pywin32 and watchfiles that live inside the project’s .venv folder. Attempting to run `uv sync` or upgrade packages while those locks are held will result in “Access is denied” errors or leave the environment in a half‑updated state. The safe practice is to stop the MCP client (thereby releasing the locks), perform the dependency update, and then restart the client. If two different MCP clients are launched from the same source tree, point the second one at an isolated virtual environment—perhaps by using `uv venv` in a separate directory—to avoid sharing the same .venv and its attendant locking issues. These nuances are minor but can save hours of troubleshooting if overlooked.
Once the server is running, interacting with SAP GUI becomes a matter of calling the exposed MCP tools. The most basic operation is `sap_connect_existing`, which attaches to an already logged‑in session; alternatively, `sap_connect` can launch the SAP Logon Pad and present the login screen, useful for single‑sign‑on flows or when you want the user to type credentials manually. After connection, a rich set of navigation helpers lets the agent move through the SAP landscape with confidence. Tools like `sap_call_transaction` start a new transaction by its code (e.g., MM03 for material display), while `sap_press_button` and `sap_send_key` emulate toolbar buttons and function keys, respectively. For reading data, the server offers `sap_read_field`, `sap_read_table`, and `sap_read_list`, the latter of which extracts the contents of a classic report list directly from the GUI rather than trying to parse a screenshot—a technique that avoids OCR errors and yields structured data. Writing data is just as straightforward: `sap_set_text` populates an input field, `sap_select_option` chooses a dropdown entry, and `sap_press_button` can trigger a save. Importantly, the server includes built‑in knowledge that prevents common agent mistakes. For example, it knows that pressing F5 in most contexts means “New Entries” rather than “Refresh,” so it will either block or translate the command depending on the current screen. It also understands that double‑clicking a tree node in SPRO opens the documentation instead of executing the activity, and therefore will either warn the user or suggest an alternative action. These guardrails dramatically reduce the likelihood of the agent getting stuck in an unintended state.
To keep automation aligned with corporate governance, mcp-sap-gui ships with a flexible policy engine. Administrators can select a profile that determines which tool categories are visible to the agent: the exploration profile exposes only read‑only functions, suitable for data‑gathering bots; the operator profile adds write capabilities but still omits higher‑risk actions like transaction starts; the full profile unlocks everything, which is appropriate for tightly controlled development or sandbox environments. Profiles can be changed at runtime via `sap_set_policy_profile`, but the server‑level `–profile` flag establishes a floor—no session can elevate its privileges beyond what the administrator has allowed. Beyond profiles, a transaction whitelist lets you specify exactly which transaction codes the agent may initiate, supporting wildcards such as `/SCWM/*` to cover an entire warehouse‑management namespace. The older `–allowed-transactions` flag still works and simply layers on top of the policy file. Another safety net is OK‑Code bypass prevention: the server watches for attempts to set the OK‑CODE field (whether via `tbar[0]/okcd`, `txtOK_CODE`, or similar aliases) to a blocked transaction and rejects those calls outright, preventing crafty workarounds. Every tool carries MCP annotations (`readOnlyHint` and `destructiveHint`) that clients can use to show visual cues—grayed‑out buttons for reads, red‑outlined icons for writes—helping end‑users understand the potential impact before they approve an action. Together, these mechanisms give organizations fine‑grained control over what the AI can do, while still enabling meaningful automation.
Transparency and accountability are reinforced through comprehensive audit logging and secure credential handling. When the `–audit-log` flag is supplied, the server writes a JSON line for every tool invocation, capturing the tool name, the arguments (with any secrets automatically masked), the start and end timestamps, and the outcome—success, failure, or blocked due to a confirmation point. This creates an immutable trail that can be fed into SIEM systems for anomaly detection or used during internal audits to demonstrate that no unauthorized changes occurred. Credential management follows a zero‑knowledge principle: the `sap_connect` tool never accepts a password as a parameter. Instead, it reads SAP_USER, SAP_PASSWORD, SAP_CLIENT, and SAP_LANGUAGE from a local `.env` file, which should be kept out of version control and protected by filesystem permissions. Because the password never crosses the MCP boundary, it does not appear in client logs, tool‑call histories, or the audit log, dramatically reducing the risk of accidental exposure. For environments that rely on single‑sign‑on, the recommended pattern is to log in manually through SAP GUI first and then use `sap_connect_existing` to attach to the running session; this way the assistant works with an already authenticated connection without ever handling clear‑text credentials. Administrators can further tighten security by restricting the server’s ability to launch new SAP Logon instances, leaving only the attach‑to‑existing mode enabled.
From a market perspective, the arrival of mcp-sap-gui underscores a broader shift toward integrating large language models with mission‑critical enterprise systems. Historically, robotic process automation (RPA) vendors have dominated the SAP automation space, but their reliance on screen scraping and OCR introduces fragility—especially when SAP updates its UI theme or changes font rendering. By contrast, mcp-sap-gui leverages the official Scripting API, the same interface that traditional GUI‑based testing tools use, thereby delivering a level of precision and stability that pure image‑based approaches struggle to match. This distinction is becoming increasingly relevant as enterprises seek to embed AI copilots directly into core processes such as order‑to‑cash, procure‑to‑pay, and financial close, where data integrity is non‑negotiable. Moreover, the server’s client‑agnostic design means that investment in MCP tooling pays dividends across multiple platforms; a policy written for Claude Code can be reused with GitHub Copilot, Cursor, or a proprietary internal agent, reducing vendor lock‑in. Early adopters report that the combination of preview cards and confirmation points dramatically improves user trust, as operators can see exactly what the AI intends to do before it touches the system. As more organizations experiment with generative AI for SAP, solutions that marry Structured API access with strong governance—like mcp-sap-gui—are likely to gain traction.
When proposing mcp-sap-gui to a Basis or security team, it helps to frame the conversation around risk reduction rather than mere convenience. Begin by acknowledging the organization’s existing hardening stance: many firms disable SAP GUI Scripting globally because they view it as a potential avenue for malicious automation. Then explain how the graduated enablement model offered by SAP allows you to turn scripting on for a narrowly defined set of users, roles, or even specific transaction codes, thereby containing the blast radius. Highlight that the mcp-sap-gui server adds multiple layers of protection on top of the native scripting interface: preview cards give humans a chance to vet every change, confirmation points enforce explicit consent for risky operations, and the policy engine limits which tools and transactions the agent can employ. Emphasize also the audit‑log capability, which provides an immutable, machine‑readable record of every interaction—a feature that pure RPA bots often lack without costly add‑ons. Offer to run a proof‑of‑concept in a development client where non‑production data resides, and invite the Basis team to review the logs and observe the consent prompts in action. By demonstrating that the AI assistant never acts without an explicit, logged‑go‑ahead, you can turn a perceived security liability into a controlled, auditable enabler of process innovation.
For readers ready to try mcp-sap-gui today, here is a concise, step‑by‑step checklist. First, verify that you are running a Windows machine with SAP GUI 7.50 or later and that scripting is enabled both in the client options and, if you have Basis rights, on the server side. Second, install the latest uv release if you do not already have it, then execute `uvx mcp-sap-gui[screenshots]` to pull the server from PyPI and launch it in an isolated environment. Third, configure your MCP client—whether Claude Code, GitHub Copilot, or another tool—to point to the stdio interface; most clients provide a simple JSON snippet where you specify the command and arguments. Fourth, start with the exploration profile (`–profile exploration`) to familiarize yourself with read‑only tools such as `sap_read_field` and `sap_read_list` before attempting any writes. Fifth, once comfortable, create a `.env` file containing SAP_USER, SAP_CLIENT, SAP_LANGUAGE, and leave SAP_PASSWORD out; log in manually via SAP GUI, then use `sap_connect_existing` to attach. Sixth, experiment with sap_preview to see the approval card in action, and try activating a confirmation point like `sap_set_confirmation_points field_writes` to feel the consent gate. Finally, enable audit logging with `–audit-log sap_mcp.jsonl` and review the output to confirm that every action is recorded and that credentials remain masked. Following these steps will let you harness AI‑driven SAP automation safely, efficiently, and in full compliance with your organization’s governance policies.