MCP SAP GUI Server

Overview Schema Source Related Servers Discussions Admin

Sap Get Tree Node Children

sap_get_tree_node_children

Retrieves the direct children of a SAP GUI tree node, enabling step-by-step navigation of deep trees such as SPRO without reading the entire tree.

Instructions

Get direct children of a tree node. Much faster than read_tree for step-by-step navigation of deep trees (e.g., SPRO).

Omit node_key or pass empty string for root-level nodes. Set expand=true to expand the node first (requires write permission).

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": {
      "tree_id": "<tree_id>"
    },
    "name": "sap_get_tree_node_children"
  }
}

Input Schema

Name	Required	Description	Default
`expand`	No
`tree_id`	Yes
`node_key`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0May 28, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Explains the non-obvious side effect behind readOnlyHint=false: expand=true mutates the tree state and therefore requires write permission. That is real disclosure beyond the annotations. It does not mention error behavior for invalid node_key, which keeps it from a 5.

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?

Three short sentences, front-loaded with the core action and the performance/sibling comparison before the parameter notes. Nothing is wasted.

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?

With an output schema present, return values need no explanation; the description covers the remaining decision-relevant facts — root handling, the write-permission requirement for expansion, and the read_tree alternative.

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 burden and does it for two of three params: empty/omitted node_key means root level, and expand has a state-changing meaning. tree_id is only self-evident from context, so it is not fully covered.

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 ("Get direct children of a tree node") and immediately differentiates itself from the sibling read_tree. An agent can pick between this and read_tree/expand_tree_node without opening any schema.

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 recommends itself for step-by-step navigation of deep trees like SPRO and positions read_tree as the slower alternative. It stops short of an explicit "use read_tree when you need the whole tree" exclusion, but the selection context is clear.

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

Deploy Server