Skip to main content
Glama
kts982

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sap_read_table

Read-only

Read rows from the current SAP screen table, auto-detecting ALV grid or TableControl, with column selection, schema discovery, and pagination for large tables.

Instructions

Read rows from a table on the current screen — ALV grid (report/list output) or TableControl (SM30 maintenance view, customizing screens).

Auto-detects the table type. The response includes a 'table_type' field ('GuiGridView' for ALV or 'GuiTableControl') so you know which type-specific tools to use next (e.g., sap_get_alv_toolbar for ALV, sap_scroll_table_control for TableControl).

Use columns_only=true for schema discovery (returns column metadata only, no data). For a TableControl it also gives each column's cell_type and a cell_id template ({row} = zero-based visible row) for sap_set_batch_fields. Use columns to fetch only specific columns (CSV). Use start_row to paginate through large tables. On a TableControl a start_row (0 included) scrolls there first; without one the read starts where the table is scrolled now (e.g. after Position...). first_visible_row says which row is on top.

A TableControl's total_rows counts its empty lines too (SM30 pads the view). When the read reaches the first empty row, the response has empty_rows_from, that row's absolute index: the data ends there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
columnsNo
max_rowsNo
table_idYes
start_rowNo
columns_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.2
    • addedInput schema / properties / start_row / anyOf
      Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / start_row / default
      Previous value: -0New value: +null
    • removedInput schema / properties / start_row / type
      Removed value: -"integer"
  2. First observedv0.2.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only cover readOnly/destructive, so the description adds substantially: auto-detection, the table_type field, that start_row=0 scrolls first, that total_rows includes SM30 padding lines, and how empty_rows_from marks data end. It omits max_rows/column-format details but the behavioral trait disclosure is rich and non-obvious.

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 purpose then the table_type routing hint, then usage paragraphs. Content is dense and mostly earns its place; a few parenthetical asides (the Position... example, SM30 padding note) add length but are genuinely informative.

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?

Given an output schema exists, return-field explanation is not strictly required, yet the description still clarifies table_type, total_rows, first_visible_row, and empty_rows_from—useful non-schema context. Coverage is strong; only max_rows semantics remain unclear.

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 0%, so the description must compensate and does: it explains columns_only, columns (CSV), start_row (including null/default 'current scroll' semantics), and touches on rows. It doesn't define max_rows or clarify table_id format, leaving one of five params undocumented.

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 (read rows from a table) and explicitly scopes to the two types it handles (ALV grid and TableControl), even naming the SM30 maintenance-view case. The 'table_type' return field lets an agent route to the right type-specific sibling, so it is clearly distinguished from tools like sap_read_shell_content or sap_read_list.

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?

Gives explicit when-to-use routing: columns_only=true for schema discovery, columns to fetch specific columns, start_row to paginate, and points to sap_get_alv_toolbar vs sap_scroll_table_control based on detected type. Also explains the start_row vs current-scroll behavior, removing ambiguity about read position.

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