Skip to main content
Glama
Sign In
MCP SAP GUI Server

MCP SAP GUI Server

by kts982
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sap Scroll Table Control

sap_scroll_table_control

Scrolls a GuiTableControl to a specified row position so you can target visible rows; does not work on ALV grids.

Instructions

Scroll a GuiTableControl to a specific row position.

Does NOT work on ALV grids (they handle scrolling internally). For reading data at a specific offset, prefer sap_read_table with start_row parameter — it handles scrolling automatically.

position in the response is the row SAP actually put at the top, which can differ from the one asked for (then requested_position and a note say so). Cell IDs ([col,row]) count visible rows from that row.

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>",
      "position": "<position>"
    },
    "name": "sap_scroll_table_control"
  }
}

Input Schema

NameRequiredDescriptionDefault
positionYes
table_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 say readOnlyHint=false and destructiveHint=false, so the description carries the interesting behavioral burden and does it well: the scroll may land on a different row than requested, and the response surfaces requested_position plus a note when that happens. It also warns that cell IDs are relative to the visible window. What it does not state is whether scrolling has side effects on selection/current cell or whether it can fail for locked tables.

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?

Four short lines, front-loaded with the action and its scope, then the exclusion, then the preferred alternative, then the response caveat. Every sentence carries distinct, non-redundant information.

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?

An output schema exists, so return values need not be enumerated, yet the description still flags the one return detail an agent could misread (position vs requested_position). Combined with the ALV exclusion and the read_table routing, an agent has everything needed to call this correctly or avoid it.

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 both parameters are required, so the description must compensate. It clarifies position's semantics partially (the effective top row, the divergence from the requested value) but never states the indexing base (0- vs 1-based) or valid range, and table_id is left entirely unexplained beyond its 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 and resource ("Scroll a GuiTableControl to a specific row position") and immediately scopes it against the sibling family that looks similar but behaves differently (ALV grids). An agent can distinguish it from sap_read_table and the ALV tools 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit exclusion (does NOT work on ALV grids, with the reason: they scroll internally) and an explicit alternative with the condition that selects it ("For reading data at a specific offset, prefer sap_read_table with start_row — it handles scrolling automatically"). Both when-not and better-option are named.

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