Skip to main content
Glama
MCP SAP GUI Server

MCP SAP GUI Server

by kts982

Sap Select Alv Context Menu Item

sap_select_alv_context_menu_item

Select an ALV context menu item by function code, visible text, or position; optionally open the toolbar menu and choose it in one atomic call.

Instructions

Select an item from an opened ALV context menu.

First use sap_press_alv_toolbar_button on a Menu button to open it, then use this to select an item. Alternatively, pass toolbar_button_id to open the menu and select in one atomic call (recommended).

menu_item_id can be a technical function code (for example @M00006), visible menu text (for example Confirm WT in Foreground), or a position descriptor. You can pass human-readable menu text directly. The menu_items of sap_press_alv_toolbar_button list what a menu offers.

select_by controls how selection is performed:

  • auto (default): heuristic based on whether menu_item_id has spaces

  • id: function code

  • text: visible menu text

  • position: position descriptor

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": {
      "grid_id": "<grid_id>",
      "menu_item_id": "<menu_item_id>"
    },
    "name": "sap_select_alv_context_menu_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
grid_idYes
select_byNoauto
menu_item_idYes
toolbar_button_idNo

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?

With readOnlyHint=false and destructiveHint=false already covering the safety profile, the description adds real behavioral context: the atomic open-and-select mode, and the fact that `auto` uses a space-based heuristic to guess id vs text, which materially affects outcomes. It does not describe what happens when a menu item is not found or when no menu is open, leaving failure behavior undisclosed.

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 and the prerequisite workflow, then the parameter guidance in scannable bullets. Slightly over-long — the two `menu_item_id` examples plus the reiteration that human-readable text works could be tightened without losing meaning.

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?

An output schema exists, so return-value details are not owed here, and the tool's main complexity (which identifier form to use, two-step vs atomic) is well covered. The remaining gap is the undocumented required `grid_id` and the absence of any error/fallback guidance for a failed selection.

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 carries the full burden and largely does: it enumerates the three accepted forms of `menu_item_id` with concrete examples, spells out each `select_by` enum value, and explains the role of the optional `toolbar_button_id`. The exception is `grid_id`, a required parameter that is never defined anywhere.

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 ("Select an item from an opened ALV context menu") and immediately positions itself relative to the sibling that produces the menu, sap_press_alv_toolbar_button. An agent can distinguish this from sap_press_alv_toolbar_button and sap_select_menu 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 explicit when-to-use context (menu must already be open), names the prerequisite tool, and offers a recommended alternative path (pass toolbar_button_id to open and select atomically). It even points to where to discover valid menu items when the menu is not yet open.

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