Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Read Field

sap_read_field
Read-only

Read a field's value, type, labels, and changeable status on the current SAP GUI screen to inspect screen data, including selection state for checkboxes and radio buttons and keys for dropdowns.

Instructions

Read the value of a field on the current SAP screen.

Returns value, type, changeable status, and labels (left/right). For a dropdown, value is the selected entry's text and key its key. For a radio button or checkbox, value is its label and selected says whether it is selected. Use sap_get_screen_elements to discover field IDs on unknown screens.

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": {
      "field_id": "<field_id>"
    },
    "name": "sap_read_field"
  }
}

Input Schema

NameRequiredDescriptionDefault
field_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is given. The description goes further by disclosing the type-dependent semantics of the returned value (dropdown returns entry text, radio/checkbox return labels with a selected flag), which is real behavioral context an agent cannot get from annotations. Error behavior for a missing or invalid field_id is not covered.

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?

Front-loaded with the action, then the return shape, then the special-cased control types, then the discovery hint. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations, an output schema, and a single required parameter, the description covers what an agent needs: what it reads, what comes back for each control type, and how to obtain IDs. The only gap is failure behavior when the field does not exist or is not readable.

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

Parameters3/5

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

Schema description coverage is 0% and the single field_id parameter has no documented format in the schema. The description partially compensates by telling the agent where valid field IDs come from (sap_get_screen_elements) but never indicates what an ID looks like or whether it is a screen-element path versus a plain name.

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+resource pair, 'Read the value of a field on the current SAP screen', which is immediately distinguishable from write-side siblings like sap_set_field or sap_modify_cell. It also enumerates what comes back (value, type, changeable status, labels), so an agent knows exactly what it is asking for.

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?

Explicitly directs the agent to sap_get_screen_elements when field IDs are unknown, which is the one real precondition for calling it. It does not, however, exclude other read siblings such as sap_read_textedit, sap_read_table, or sap_get_cell_info, so an agent facing a non-field control still has to reason it out.

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