MCP SAP GUI Server

Overview Schema Source Related Servers Discussions Admin

Sap Set Batch Fields

sap_set_batch_fields

Fill multiple SAP GUI form or selection-screen input fields at once with a field_id-to-value map, including table cells and dropdowns, avoiding repeated single-field calls.

Instructions

Fill in multiple input fields at once (dict of field_id to value).

Use this to fill a form or selection screen in one call — more efficient than repeated sap_set_field calls. Table-control cells work too: take the cell_id template of each column from sap_read_table(columns_only=true) and replace {row}. A dropdown (cmb) takes an entry's key or text, as in sap_set_field.

The result gives counts; results lists only the fields that did NOT succeed (all of them with verbose=true). Check failed == 0: a field that was not set does not stop the others. With --strict-errors such a batch is returned as an error.

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": {
      "fields": "<fields>"
    },
    "name": "sap_set_batch_fields"
  }
}

Input Schema

Name	Required	Description
`fields`	Yes	Dict mapping field_id -> value.
`verbose`	No	List every field in `results`, not only the failures.
`validate`	No	Press Enter after setting fields and return status-bar feedback. Skipped when no fields were actually set, and when any field failed (`failed` > 0) unless validate_partial=true. `validation.performed` is false when Enter was not pressed or SAP refused it (then with `error`).
`skip_readonly`	No	Silently skip fields whose element reports Changeable == False instead of counting them as failures.
`validate_partial`	No	With validate=true, press Enter even when some fields failed.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Oct 28, 2026

changedInput schema / properties / validate / description

Previous value: -"Press Enter after setting fields and return status-bar\nfeedback. Skipped when no fields were actually set."New value: +"Press Enter after setting fields and return status-bar\nfeedback. Skipped when no fields were actually set, and when\nany field failed (`failed` > 0) unless validate_partial=true.\n`validation.performed` is false when Enter was not pressed or\nSAP refused it (then with `error`)."

addedInput schema / properties / validate_partial

Added value: +{
+  "default": false,
+  "description": "With validate=true, press Enter even when some\nfields failed.",
+  "type": "boolean"
+}

Changed1 schema field changedv0.4.0Sep 21, 2026

addedInput schema / properties / verbose

Added value: +{
+  "default": false,
+  "description": "List every field in `results`, not only the failures.",
+  "type": "boolean"
+}

Changed3 schema fields changedv0.2.2Jul 5, 2026

addedInput schema / properties / fields / description
```
Added value: +"Dict mapping field_id -> value."
```

addedInput schema / properties / skip_readonly / description

Added value: +"Silently skip fields whose element reports\nChangeable == False instead of counting them as failures."

addedInput schema / properties / validate / description

Added value: +"Press Enter after setting fields and return status-bar\nfeedback. Skipped when no fields were actually set."

First observedv0.2.0May 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: partial-failure semantics ('a field that was not set does not stop the others'), the failure-check contract (check failed == 0), and how `results` is populated. The annotations only say readOnlyHint=false / destructiveHint=false, which declares mutation but nothing about atomicity or error handling. Missing is whether values overwrite existing field contents and what happens if a field_id doesn't exist; also references a '--strict-errors' flag that is not a schema parameter, which is a mild portability smell rather than a contradiction.

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-loaded with the core action, then batching rationale, then edge-case guidance, then result handling — a sensible order with no filler sentences. Minor deductions for the trailing '--strict-errors' CLI-flag reference and the dense backticked field names that read more like reference docs than tool-selection copy.

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?

For a 5-parameter batch mutation with an output schema, the description covers what an agent needs to call it correctly: the payload shape, the non-atomic failure model, how to detect failures, and where the results come back. Return-value detail is legitimately left to the output schema.

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 coverage is 100%, so baseline is 3; the description earns above that by enriching the `fields` parameter with cell_id template patterns and combobox key-or-text semantics that the schema's one-line 'Dict mapping field_id -> value' does not convey. The verbose/strict-errors interaction is partly documented in the description, though validate/validate_partial/skip_readonly semantics are carried by the schema descriptions rather than the prose.

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?

Opens with a specific verb+resource plus the payload shape: 'Fill in multiple input fields at once (dict of field_id to value).' It explicitly distinguishes itself from the sibling sap_set_field by positioning itself as the batched alternative, so an agent can choose without opening either schema.

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?

States the target context ('fill a form or selection screen in one call') and names the alternative (repeated sap_set_field calls) with the efficiency reason that selects this tool. It also gives concrete guidance for two hard cases — table-control cells via sap_read_table(columns_only=true) templates with {row} substitution, and dropdowns taking an entry's key or text. It stops short of saying when not to use it (e.g., a single field), leaving that to inference.

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

Deploy Server