Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Set Confirmation Points

sap_set_confirmation_points
Read-only

Configure which SAP operations require explicit user approval before execution, pausing matching tool calls for confirmation so nothing reaches SAP unconfirmed.

Instructions

Choose which SAP operations need the user's explicit approval first.

Replaces this session's set of confirmation points. When a point is active, every matching tool call pauses and asks the user to approve it (MCP elicitation) before anything reaches SAP; declining returns an error and nothing is executed.

Points:

  • transactions: sap_execute_transaction

  • batch_fields: sap_set_batch_fields

  • field_writes: sap_set_field, sap_modify_cell, sap_set_textedit, sap_select_checkbox, sap_select_radio_button, sap_select_combobox_entry

  • all_writes: every write-tagged tool. Strict and noisy — many write tools only select, scroll or navigate, and they will all prompt. Under all_writes, sap_send_key("F11") asks twice: once for the category and once for the unchanged save gate.

  • attach: sap_connect_existing lets the user pick the SAP session in a dialog, unless the call names a system with exactly one open session.

'save' (F11 / Save key, Save toolbar button) is always on and cannot be turned off. Points set by the server's --confirm flag cannot be removed either. Adding a point is silent; removing one asks the user first, and a declined removal keeps the point.

Confirmation prompts block until the user answers, and on clients without elicitation support the gated call fails instead of running unconfirmed (same fail-closed rule as the save gate). On such a client points also cannot be removed, so activating one there blocks that whole category for the rest of the session. Call sap_preview before a gated action so the user can see the screen and pending values first.

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": {
      "points": "<points>"
    },
    "name": "sap_set_confirmation_points"
  }
}

Input Schema

NameRequiredDescriptionDefault
pointsYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / points / items / enum
      Previous value: -[
-  "batch_fields",
-  "field_writes",
-  "transactions",
-  "all_writes"
-]New value: +[
+  "batch_fields",
+  "field_writes",
+  "transactions",
+  "all_writes",
+  "attach"
+]
  2. Addedv0.4.0

TDQS

A4/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true, but the description says the tool 'Replaces this session's set of confirmation points' and that removing a point changes session behavior after elicitation. That is a state mutation, so the description contradicts the read-only annotation even though it otherwise gives unusually rich behavioral detail.

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?

The description is long but well structured and front-loaded, with the core replacement behavior stated first and bulleted point definitions afterward. Every section adds safety-relevant information rather than repeating the schema.

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 one required enum parameter and an output schema, the description covers the enum meanings, elicitation behavior, fail-closed behavior on unsupported clients, immutable save/server points, and preview advice. It is complete enough for an agent to understand the tool's effects and limitations.

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?

Schema description coverage is 0%, but the description compensates by defining every enum value: transactions, batch_fields, field_writes, all_writes, and attach. It also explains that the points array replaces the session's current set and what each category gates.

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?

The description states a specific verb and resource: choosing which SAP operations require explicit user approval, and replacing this session's confirmation-point set. It clearly distinguishes this configuration/safety tool from the SAP operation tools it gates.

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 explains the operational consequences of activating each point and notes constraints such as the always-on save gate and server-forced points. It stops short of an explicit user-facing trigger like 'call this when the user asks to require approvals before writes', but the context is otherwise clear.

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