Skip to main content
Glama
MCP SAP GUI Server

MCP SAP GUI Server

by kts982

Sap Read Table

sap_read_table
Read-only

Read rows from the current SAP screen table, auto-detect ALV grid or TableControl, and return column metadata or paginated data for follow-up actions.

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 read returns at most the visible rows: page with start_row=next_start_row while has_more is true. start_row_note explains a clamped or failed scroll. 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.

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": {
      "table_id": "<table_id>"
    },
    "name": "sap_read_table"
  }
}

Input Schema

NameRequiredDescriptionDefault
columnsNo
max_rowsNo
table_idYes
start_rowNo
columns_onlyNo

Output 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.7/5.0
Behavior5/5

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

Annotations already establish a safe read (readOnlyHint=true), yet the description still discloses non-obvious behavior beyond them: automatic table-type detection, that start_row=0 causes an actual UI scroll as a side effect, that TableControl reads are capped at visible rows, that scrolls may be clamped or fail (start_row_note), and that SM30 pads total_rows with empty lines. These are operational gotchas an agent could not infer from the annotations.

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 what the tool does and what it returns, then parameter guidance, then edge cases — a sensible order with no filler sentences. It is dense and longer than typical, and some of the latter material retreads return-field names that the output schema already documents, but each paragraph still carries actionable guidance.

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?

For a five-parameter tool with zero schema descriptions and a rich output schema, this covers identification, projections, pagination, and truncation/empty-row edge cases thoroughly. The remaining gaps are max_rows semantics and its interplay with the visible-row limit, which an agent would still have to guess at.

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 description coverage is 0%, so the description must carry the load, and it does a strong job for three of five parameters: columns_only (metadata-only plus cell_type/cell_id template), columns (CSV projection), and start_row (pagination, zero-based, scroll semantics, null default behavior). table_id is left unstated and max_rows is never mentioned at all, including how it interacts with the visible-row cap, so it doesn't fully compensate.

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 concrete verb and resource ('read rows from a table on the current screen') and immediately disambiguates the two supported table types (ALV grid vs TableControl/SM30). It distinguishes itself from sibling readers like sap_read_field, sap_read_list, and sap_get_column_info by naming what it returns (row data plus table_type), so an agent can pick it without opening schemas.

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?

Explicit conditional routing: columns_only=true for schema discovery, columns (CSV) for projections, start_row for pagination, and named downstream tools per table type (sap_get_alv_toolbar for ALV, sap_scroll_table_control for TableControl). It also spells out the pagination loop condition (start_row=next_start_row while has_more) and the fallback behavior when start_row is omitted.

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