Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Connect Existing

sap_connect_existing
Read-only

Attach to an already open SAP GUI session for scripting, optionally targeting a named system. Use when SAP is already logged in and the open session needs automation.

Instructions

Connect to an already open SAP session. Use this when SAP is already logged in.

This is the most common starting point. connection_index=0 and session_index=0 connect to the first open session. Also attaches to SAP Business Client / embedded SAP GUI sessions. Indexes come from sap_list_connections; a connection with scripting_disabled=true cannot be attached.

system: pass it only when the user named the SAP system, as 'DEV' or 'DEV/100' (system/client). One open session on it is attached; several, or none, return an error that lists what is open. The indexes are then ignored.

With the 'attach' confirmation point on, the user picks the session in a dialog unless system names exactly one open session. The response says how it was chosen (chosen_by: named, dialog or index).

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

Input Schema

NameRequiredDescriptionDefault
systemNo
session_indexNo
connection_indexNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / system
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the read-only annotations by describing attached session types, index defaults, scripting-disabled restrictions, error behavior for ambiguous or missing named systems, and how the session is selected via dialog or index. These are material behavioral details an agent would not know 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?

Front-loads the core action and condition, then adds only relevant operational details. It is somewhat long, but the length is justified by the nontrivial selection and confirmation behavior.

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?

Given a zero-description schema, an output schema, and read-only annotations, the description supplies all the operational context needed to invoke the tool correctly, including selection precedence, error conditions, and response field `chosen_by`.

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

Parameters5/5

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

Despite 0% schema description coverage, the description explains all three parameters: the `system` format and its effect, the meaning of `connection_index` and `session_index`, and that indexes are ignored when `system` selects a session. This compensates fully for the absent schema descriptions.

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 specific verb and resource: connecting to an already open SAP session, with the condition that SAP is already logged in. It clearly distinguishes this from a fresh connection and names `sap_list_connections` as the source of indexes.

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?

Explains exactly when to use it, notes that `connection_index=0` and `session_index=0` target the first open session, and gives the `system` parameter as an alternative selector. It also covers exclusions such as connections with `scripting_disabled=true` and describes the attach confirmation behavior.

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