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

Annotations already indicate non-read-only and non-destructive behavior. The description adds context by specifying that clicking a link in an SPRO tree runs an activity, but does not detail any side effects or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, front-loading the action and immediately providing context. Every sentence adds value without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description mentions a companion tool ('sap_read_tree') for preparation, and given that an output schema exists, it covers the essential usage context. It is complete enough for an agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides specific guidance for the 'item_name' parameter (e.g., often '2' for execute icon), which adds value beyond the schema. However, 'tree_id' and 'node_key' are not described beyond their names, and schema coverage is 0%, so the description only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('Click a hyperlink') and the resource ('tree node item'), and distinguishes it from sibling tools like 'sap_double_click_tree_item' by focusing on link-type items. The mention of SPRO/customizing trees provides specific context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description advises to use 'sap_read_tree' to identify link-type columns, providing clear guidance on how to determine the correct column. It also gives a typical example (item_name='2') for SPRO trees, though it does not explicitly state when not to use the tool.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the tool modifies state non-destructively. The description adds 'collapse' but does not disclose behaviors like idempotency, error handling for already collapsed nodes, or effects on children. Minimal additional value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, highly concise and front-loaded. However, it may be too brief to provide sufficient guidance; a few more words on parameters would be beneficial without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with two parameters and an output schema, but the description does not cover return behavior, prerequisites (e.g., tree must be loaded), or what happens when collapsing an already collapsed node. Given the presence of an output schema, more context on input constraints is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate, but it provides no explanation for tree_id or node_key. The parameter names are somewhat self-explanatory but lack context about expected values or formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool collapses a folder node in a tree control, with a concrete example (SPRO/customizing tree). It uses a specific verb and resource, and distinguishes from siblings like sap_expand_tree_node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage for tree controls but does not explicitly state when to use this tool versus alternatives like sap_expand_tree_node or sap_select_tree_node. No when-not or alternative guidance.

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

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

The description discloses credential resolution from a .env file and that passwords never appear in calls, adding security context beyond the annotations. It explains parameter overrides. The annotations (readOnlyHint=true, destructiveHint=false) are not contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the main purpose, no unnecessary words. Efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, security, parameter usage, and alternative tool. The output schema handles return values. Does not mention error handling or prerequisites like the .env file existence, but remains sufficient for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Amid 0% schema description coverage, the description explains that parameters override .env values and identifies system_description as the SAP Logon Pad name. More detail on each parameter would improve clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool connects to an SAP system by its name in SAP Logon Pad. It distinguishes itself from the sibling tool sap_connect_existing, which is for already open sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly advises to use sap_connect_existing if already logged in. However, it does not elaborate on other scenarios where this tool should be avoided.

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

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

Annotations already declare this a safe read operation, so the bar is lower; the description still adds real behavioral context by noting it attaches to SAP Business Client / embedded SAP GUI sessions, that indexes originate from sap_list_connections, and that scripting-disabled connections are un-attachable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, action front-loaded, no filler; the distinguishing condition and the failure constraint each earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, annotations cover safety, and the description supplies the indexing model plus the scripting-disabled limitation. Only the explicit contrast with sap_connect for the non-logged-in path is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 so: it explains that connection_index=0 and session_index=0 target the first open session and that index values come from sap_list_connections. It does not describe what happens with out-of-range or missing indexes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Connect to an already open SAP session') and immediately disambiguates scope with 'Use this when SAP is already logged in', which distinguishes it from the sibling sap_connect that presumably establishes a new connection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear when-to-use condition ('SAP is already logged in') and frames it as the most common starting point, plus a hard constraint: a connection with scripting_disabled=true cannot be attached. It stops short of explicitly naming the alternative tool (sap_connect) for the not-logged-in case.

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

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

The description states that sessions are closed, which is a state change, contradicting annotations that set readOnlyHint=true. According to the scoring rules, a contradiction results in a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise, and front-loaded with the main action. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, an output schema exists, and the tool's behavior is fully explained (including what happens to different session types), the description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so baseline is 4 per the scoring guide. No additional parameter information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'disconnect' and the resource 'current SAP session'. It distinguishes behavior for sessions opened by this MCP vs attached ones, which differentiates it from siblings like sap_connect and sap_connect_existing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly tells when to use the tool (to disconnect) and explains the two cases. It lacks explicit 'when not to use' or alternatives, but the context is clear given the sibling tools.

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

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

Annotations show it is not read-only nor destructive, but description adds that double-click often opens details or drills down. However, it does not disclose potential side effects like screen changes or popups, and the output schema is not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, parameter details, and compatibility. No redundancy, front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers action, parameters, and compatibility. Lacks output schema explanation and potential prerequisites (e.g., cell visibility). Good for most use cases but could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite zero schema coverage, description explains that row is zero-based and column is the column name from specific tools, adding meaning beyond the schema types. table_id is left implicit but its purpose is clear from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (double-click a cell) and context (table/grid, opens details or drills down). It differentiates from sibling tools like sap_double_click_tree_item by specifying 'cell' and from sap_modify_cell by the action type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Implies when to use: for double-clicking a table/grid cell, not for trees or links. It mentions compatibility with ALV and TableControl, but does not explicitly state when not to use or list alternatives.

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

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds that it performs a double-click action, which implies interaction but no contradiction. It explains the item_name parameter but not side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 params and an output schema, the description covers the purpose and one parameter, referencing a sibling tool for more info. Missing explanations for tree_id and node_key, but overall sufficient for a simple action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains item_name with examples ('Column1', 'Column2'), but tree_id and node_key are not described. Partial coverage adds value but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'double-click' and the resource 'a specific item (column cell) in a tree node row.' It distinguishes from sibling tools like sap_click_tree_link and sap_double_click_tree_node.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description specifies when to use this tool (to double-click a tree item) and advises using sap_read_tree to discover column names. It does not explicitly state when not to use, but the context is clear.

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

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

Annotations already signal this is not read-only and not destructive. The description adds nuance about SPRO trees where double-click may open documentation rather than executing an activity. However, it does not explicitly state whether the action modifies state or what side effects occur, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the primary purpose and follow with a specific exception. No wasted words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (clicking a node) and the existence of an output schema, the description covers the main scenario and the SPRO edge case. However, it does not compare with sibling tools like sap_double_click_tree_item, which might be similar, leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions for parameters tree_id and node_key). The description does not explain what these parameters represent or how to obtain them, failing to add meaning beyond the raw schema. It only mentions 'node' generically.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Double-click a node in a tree control' with the specific verb and resource, and explains it 'often opens details or drills down'. It also distinguishes the SPRO case from normal usage, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly tells when to use this tool (for tree nodes) and when not to (for SPRO activities, recommending sap_click_tree_link instead on the execute column). It provides a clear alternative and context for the SPRO scenario.

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

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

The annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds meaningful details: it navigates to initial screens, is subject to transaction blocklist/allowlist, and warns that a bare /n can lose unsaved data. This goes well beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The sentences are compact and front-loaded with the core action, then examples, navigation behavior, restrictions, and related-tool guidance. Every sentence earns its place and there is no filler or restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema, the description covers what an agent needs before calling: what tcode means, what screen to expect, the blocklist/allowlist constraint, the /n caveat, and the related sap_get_session_info tool. Return-value details are covered by the output schema, so their absence here is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines a required string tcode with no description, so the description's identification of it as an SAP transaction code and the examples (MM03, VA01, SM30) are essential semantic context. It also adds the /n prefix nuance, though it does not exhaustively document every valid tcode or formatting edge case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action — execute/start/run an SAP transaction code — against a clear resource (tcode), with concrete examples (MM03, VA01, SM30). It also clarifies the immediate behavior by saying it navigates to the transaction's initial screen, which separates it from the many read/navigation sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides actionable conditions: always check the screen info in the response, use the /n prefix for certain SCWM transactions, and consult sap_get_session_info before navigating away. It does not explicitly contrast this tool with an alternative execution tool, so it stops short of a full when-to-use/when-not-to-use guide.

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

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

Annotations already indicate destructiveHint: false and readOnlyHint: false, so the description correctly implies a state-changing (non-read-only) but non-destructive action. It adds the behavioral detail that children become visible after expansion, which is useful context beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two succinct sentences: the first states the primary purpose, and the second provides actionable follow-up steps. No extraneous information is included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (handling return values), the description covers the essential usage scenario: how to perform the action and what to do next. It lacks explicit mention of prerequisites (e.g., node must be collapsible) or error conditions, but these are typical for such a simple operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It implicitly explains tree_id and node_key as identifiers for the tree control and the node to expand. However, it does not provide explicit details like data types, format expectations, or restrictions, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (expand) and the target (folder node in a tree control) to reveal children. It distinguishes itself from the sibling tool sap_collapse_tree_node by focusing on expansion, and provides specific follow-up tools (sap_get_tree_node_children, sap_read_tree).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly instructs to use sap_get_tree_node_children or sap_read_tree after expansion to see children. While it doesn't explicitly state when not to use it, the context is clear for a simple expand operation, and the sibling list includes a collapse tool, implying alternative use cases.

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

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

The description is consistent with annotations (readOnlyHint=true) and does not contradict them. However, it adds no behavioral context beyond the annotations, such as what happens if the path is invalid or if the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the purpose and including a helpful example. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the existence of an output schema, the description is minimally adequate. It lacks guidance on return values or error handling, but these may be covered by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the 'path' parameter is partially explained via the example, while 'tree_id' receives no description. With 0% schema coverage, the description should compensate more fully for both parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool finds a tree node key by its path and provides an illustrative example. However, it does not explicitly distinguish itself from sibling tools like sap_search_tree_nodes or sap_select_tree_node, which could cause ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or scenarios where another tool would be more appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds information about return values (IDs, texts, types) and the grid type limitation, which adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentence description with front-loaded purpose and no extraneous text. Every sentence is informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and an existing output schema, the description covers purpose, usage, return types, and limitations thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only one parameter (grid_id) and zero schema description coverage, the description does not explicitly describe the parameter, but the name and context ('from an ALV grid') imply its meaning. Sufficient for a simple parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', resource 'all toolbar buttons from an ALV grid', and distinguishes from sibling tools like sap_get_toolbar_buttons by specifying the grid type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly says to use this before pressing buttons with sap_press_alv_toolbar_button, and excludes GuiTableControl, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond them by explaining the meaning of the returned 'state' field (why a cell was rejected) and the supported control type, which is genuinely useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then a compact enumeration of return fields, closing with the control-type limitation. The field list is dense but each entry adds information; nothing reads as padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't fully restate return values, and the GuiTableControl exclusion is a useful caveat. However, the complete absence of parameter semantics for a three-required-parameter tool leaves a significant gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description says nothing about grid_id, row, or column — not their format, indexing base, accepted column identifiers, or validity constraints. With all three required parameters undocumented in both schema and description, an agent has to guess how to address a cell.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get detailed cell metadata from an ALV grid') and enumerates the metadata fields, making it distinguishable from siblings like sap_get_current_cell or sap_get_table_control_row_info. The explicit exclusion 'Does NOT work on GuiTableControl' further pins down the target control type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Offers one negative constraint ('Does NOT work on GuiTableControl'), which is real routing value, but gives no positive when-to-use statement and never names the alternative tool to use for GuiTableControl. Usage is left largely to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that, the description discloses behavior that varies by control type: ALV grids yield data_type and key flags, table controls yield cell_type and cell_id templates. It does not cover pagination, cost, or how to obtain a valid grid_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with the core capability front-loaded and the call-to-action (alternative tool) at the end. The per-control-type detail is packed into one clause rather than padding, so every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explanation is a bonus rather than a requirement, and annotations cover the safety profile. The description handles both supported control types and the sibling alternative, leaving only the unresolved question of how an agent obtains a valid grid_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single grid_id parameter, and the description never explains its format or provenance. The phrase 'ALV grid or table control' only indirectly hints that grid_id identifies such a control, so it does not fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Get detailed column info') plus resource and explicit scope ('from an ALV grid or table control'). It further distinguishes itself from the sibling sap_read_table by naming the lighter alternative, so an agent can pick between them 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.

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

Explicitly routes the agent to a cheaper alternative ('For a lighter alternative, use sap_read_table with columns_only=true'), giving a clear when-to-prefer-other condition. It stops short of stating prerequisites or when this tool is mandatory (e.g., before sap_modify_cell), so it is clear context rather than full when/when-not guidance.

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

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

Annotations already show readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral insight beyond returning key-value pairs, which is already implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences contain all essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple input, clear output, and annotations, the description is mostly complete. Could mention that the return format is suitable for validation or selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description should clarify the 'combobox_id' parameter. It only mentions 'combobox/dropdown' without explaining how to obtain the ID or what format it is.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all entries in a combobox/dropdown and returns key-value pairs, distinguishing it from sibling tools like sap_select_combobox_entry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies the tool is used to get valid values before selection, but does not explicitly state when to use it or when not to, missing explicit alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that the tool retrieves the focused cell position in specific control types (ALV grid or table control), which provides context beyond annotations but does not detail return format or side effects. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the tool's function without any extraneous information. It is appropriately sized for the tool's simplicity and immediately front-loads the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (as indicated by context signals), the description does not need to explain return values. However, it omits important context such as the requirement that a cell must be focused for the tool to succeed, and does not mention error conditions. The description is minimally adequate but leaves gaps for a robust understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the tool description provides no information about the 'table_id' parameter. The agent has no guidance on what value to provide or how to obtain it. The parameter name is somewhat self-explanatory, but the description should clarify its purpose to compensate for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'currently focused cell position in an ALV grid or table control'. It effectively distinguishes from sibling tools like sap_get_cell_info (gets cell info by coordinates) and sap_set_current_cell (sets focus). The purpose is unambiguous and specific to the current focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No usage guidelines are provided. The description does not explain when to use this tool versus alternatives such as sap_get_cell_info or sap_read_table. There is no indication of prerequisites or context in which the tool is appropriate.

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

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

Annotations already indicate read-only; description adds detail on return values including classification and suggested action, which is helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the purpose and key output details without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with output schema; description covers essentials: what it checks, what it returns, and special case (no popup).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline 4 applies as description does not need to add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it checks for open popups and returns their content, differentiating from sibling sap_handle_popup which likely responds to popups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Implies use before responding to popups but does not explicitly exclude alternatives or state when not to use it.

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

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

Annotations already declare a safe read-only operation, and the description adds substantial behavioural context beyond them: tables collapse to a single element rather than per-cell, classic lists are omitted and surfaced under 'lists', docking containers live under 'wnd[0]/shellcont' and are reported as 'docking_containers', and expand_tables produces large responses. These are exactly the surprises that would otherwise cause a wrong call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and free of throwaway sentences; each paragraph covers a distinct case (filters/depth, menu bar, tables/lists, docking containers). It is long, however, and reads as a flat block of prose where the table/list contrast and the docking-container caveat would scan faster as a short list or heading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 detail is correctly left out, and the description instead supplies the domain-specific gotchas an agent needs for this complex SAP UI tree (single-element tables, excluded lists, docking containers beside the user area). Nothing needed to call it correctly on a new or unusual screen appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description carries the load and mostly does: max_depth explained with default 2 and concrete values (1 for overview, 3+ for nested layouts), type_filter shown with real class names ('GuiTextField,GuiCTextField'), container_id illustrated with two example paths, and expand_tables with its size cost. changeable_only is only mentioned as a way to 'reduce response size' — its filtering semantics are implied rather than stated, a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Discover all elements on the current SAP screen' — plus the concrete goal ('finding field IDs when working with a new screen'). It also differentiates itself from siblings by name, e.g. tables are 'ONE element here' and should be read with sap_read_table, and lists are excluded in favour of 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.

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

Explicit when-to-use (new screen, need field IDs) and when-not (tables, classic lists) with the alternative tool named for each excluded case. It also routes the agent for special situations: container_id='wnd[0]/mbar' for the menu bar and 'wnd[0]' with max_depth=1 for top-level areas.

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

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

Annotations already declare readOnlyHint and non-destructive, so the bar is lower. The description adds real value beyond that: it explains the source (session.ActiveWindow), the meaning of the active_window field, and which fields are conditionally present (message_has_long_text, message_as_popup, subscreens, cursor) and why. It also notes the subtle behavior that a redisplayed screen still moves the cursor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well structured with a summary line, then source/behavior in paragraphs, then conditional fields. It is somewhat long and could be tightened, but almost every sentence carries information about field presence conditions that would otherwise be unknown.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema, so return values need not be enumerated fully, but the description still explains non-obvious semantics like conditional fields and cursor movement. With zero params and annotations covering safety, the description is nearly complete and adds behavioral context the schema cannot.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so baseline is 4. There is nothing to document beyond the response, and the description correctly focuses on return values rather than params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (current SAP screen info) and enumerates exactly what is returned: transaction, program, screen number, window title, status bar message. An agent can distinguish this from siblings like sap_get_session_info or sap_get_screen_elements immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly routes to the alternative sap_get_popup_window for full popup content, and explains that every action tool returns this same screen info so callers know when popups appear. No explicit 'when not to use' for other read tools, but context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds genuinely useful behavioral context by explaining that sap_gui_version and scripting_read_only are returned, and that scripting_read_only=true causes write tools to refuse. That cross-tool side effect is information an agent cannot get from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no wasted filler, and the enumerated fields come first. The second sentence is slightly awkwardly worded around the scripting_read_only condition, but the size is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not enumerate return fields in detail, yet it usefully summarizes them. Combined with the scripting_read_only warning, an agent has enough to call and interpret this tool correctly, though the absence of routing guidance to sibling info tools is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. There is no parameter semantics to document, and the description correctly focuses on returned content instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (information about the current SAP session) and enumerates what is returned (system, client, user, transaction, screen). It is clearly a metadata-read tool, though it does not explicitly differentiate itself from the closely named sibling sap_get_screen_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the resource type — you call this to inspect current session context — but there is no explicit when-to-use or when-not-to-use guidance, and no pointer to alternatives such as sap_get_screen_info or sap_list_connections for related needs.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context: it works specifically on GuiTableControl (not ALV grids) and the default behavior when rows is omitted. This goes beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the main purpose, no redundant information. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description adequately covers purpose, scope, and parameter behavior. It does not need to describe return values. All critical aspects are addressed for a read-only metadata retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains that omitting rows queries all visible rows, adding meaning to that parameter. However, table_id is not elaborated, and the description does not add substantial detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves row metadata (selectable, selected) from a GuiTableControl, differentiating it from ALV grids. This specific verb+resource combination, along with the explicit exclusion of ALV, effectively distinguishes it from sibling tools like sap_read_table.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides a clear usage condition: 'If rows is omitted, queries all visible rows.' It also warns against use on ALV grids. While it does not explicitly name alternative tools, the context is sufficient for an agent to infer when to use this tool versus other table-related tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns button IDs, text, tooltip, and enabled state, and specifies it works on tbar[0] and tbar[1]. No contradictions, but does not mention prerequisites like being connected to a session, which is minor given the tool's simplicity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no redundant information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (context indicates it exists), the description covers purpose, scope (which toolbars), return fields, and differentiation from sibling. Complete for a simple read-only list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has one optional parameter 'window_id' with a default, but the description provides no explanation for it. Schema description coverage is 0%, so description should compensate, but it does not. The parameter is simple, but still lacks clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists all buttons on system toolbar (tbar[0]) and app toolbar (tbar[1]), specifying returned fields (IDs, text, tooltip, enabled state). It distinguishes from ALV toolbar tool by naming a specific sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly states it is for standard SAP toolbars, not ALV, and directly references the alternative tool 'sap_get_alv_toolbar'. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'read-first' phrasing is consistent. It adds scope details about supported transactions but does not disclose additional behavioral traits like error handling, permission requirements, or side effects beyond the read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and uses bullet points for readability. Every sentence adds value—intro, transaction details, and aliases—with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main transaction parameter and provides useful context for two transactions, but misses the 'task' parameter semantics and does not mention error behavior for unsupported transactions. The presence of an output schema mitigates return-format gaps, but the parameter gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description compensates for the 'transaction' parameter by listing valid values and aliases, but completely omits the optional 'task' parameter, leaving its purpose unclear. Partial coverage of parameters reduces clarity for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a read-first guide for supported SAP transactions, with specific verb and resource. It distinguishes from siblings like sap_execute_transaction by emphasizing read-first nature and enumerating exact supported transactions and aliases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage for obtaining a guide on specific transactions but does not explicitly compare with alternatives like sap_execute_transaction or sap_get_workflow_guide. It lists valid inputs but lacks when-not-to-use or alternative routing, leaving selection to inference.

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

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

Annotations indicate not read-only and not destructive. Description adds that expand=true requires write permission, disclosing a behavioral trait beyond annotations. Also notes performance characteristic (much faster). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each serving a distinct purpose: purpose, node_key usage, expand usage. No fluff, clear and front-loaded. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained. Description covers main usage and constraints. Could mention error conditions or tree_id validity, but overall sufficient given tool complexity and sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. Description adds meaning for node_key (omission for root nodes) and expand (purpose and permission requirement). This compensates significantly for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Get direct children of a tree node.' It uses a specific verb and resource, and distinguishes from sibling tool 'sap_read_tree' by highlighting faster step-by-step navigation for deep trees like SPRO.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides clear context for when to use (faster than read_tree for step-by-step deep tree navigation) and how to use (omit node_key for root nodes, expand requires write permission). Does not explicitly state when not to use, but the comparison to read_tree implies alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds little behavioral context beyond stating it returns guidance. It does not contradict annotations, but it does not reveal additional traits like response format or potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences plus bullet points) and front-loads the purpose. Every part is informative without redundancy. The structure makes it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown), the description adequately covers the tool's function and input parameters. It lists all available workflows and their target usage. However, it does not describe the output format or handle potential edge cases, but the output schema likely fills that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description is essential. For the 'workflow' enum, it explains each value and what the 'target' should be. This adds significant meaning, though the 'target' parameter lacks format or constraint details beyond the examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns step-by-step guidance for SAP workflows, listing three specific workflows. While it is distinct from sibling tools that perform actions, it does not explicitly differentiate from sap_get_transaction_guide, which may be similar. Overall purpose is clear but not fully distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies when to use the tool (when guidance is needed for listed workflows) by specifying the workflows and their target parameters. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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

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

Goes well beyond the annotations: it discloses that presses which may save prompt the user first, that unreadable questions (question_readable: false, Edge control) restrict behavior, that confirm never falls back to Enter in that case, and that accepted presses report confirmed_by_user: true. This is exactly the kind of consequence-level context annotations (readOnlyHint/destructiveHint) cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the one-line purpose and the usage trigger before the action list, and the bullet structure makes scanning easy. It is somewhat long, with a dense paragraph on confirmation/safety behavior, but nearly every clause carries actionable information rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, multi-mode dialog tool with an output schema present, the description covers triggers, per-action semantics, safety constraints, and the user-confirmation contract. Since an output schema exists it needn't detail return shape, though it usefully notes what is reported back. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter burden, and it does: all five enum values of 'action' are defined with their distinct effects, and 'press' is explained as 'press a specific button by its text or tooltip', covering button_text's meaning. This fully compensates for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read and optionally act on the current popup/modal dialog') and explicitly notes it 'Combines popup inspection and response in a single call', which distinguishes it from the read-only sibling sap_get_popup_window and from sap_press_button. The action enum is spelled out so an agent knows exactly what operations are available.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives an explicit trigger ('Use when active_window shows wnd[1] or higher') and enumerates each action with when-to-use semantics, including a negative rule ('never No, which on a save prompt drops the changes') and the conservative fallback ('auto: take only a clearly safe action; otherwise return the popup read-only'). Alternatives like sap_send_key F11 are referenced for the confirmation-prompt case.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: the two host sources it spans (saplogon | sapguiserver) and the diagnostic meaning of a connection having no sessions with scripting_disabled=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action in the first sentence, followed by two short sentences that each add distinct value (coverage scope, diagnostic interpretation). No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and an output schema present, the description does not need to enumerate return values. It supplies exactly the extra framing an agent needs: what is listed, which SAP clients are covered, and how to read the scripting_disabled condition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero input parameters, so the baseline is 4 and there is nothing to clarify on the input side. The host/scripting_disabled details in the description pertain to returned fields rather than parameters, and the output schema covers those returns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List all open SAP connections and sessions,' and further scopes it to SAP Logon plus Business Client / embedded GUI sessions. It is clear what the tool returns, but it never names the nearest sibling (e.g. sap_get_session_info) to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: an agent can infer this is the entry point for enumerating connections before calling session-level tools, and the final sentence gives a diagnostic interpretation. There is no explicit 'use this when' or 'use X instead' guidance naming alternatives such as sap_get_session_info.

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

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

Annotations already indicate this is a non-read-only, non-destructive operation. The description adds that it only modifies editable cells, which is a behavioral constraint beyond the annotations. It does not disclose authentication needs or error states, but for a simple cell modification this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose, and contains no fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of SAP automation and the number of siblings, the description is somewhat brief. It does not explain success/failure behavior, return value (though an output schema exists), or error handling. While the core usage is clear, more context about return or side effects would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 4 parameters (grid_id, row, column, value) with 0% schema description coverage. The description only implies these parameters by saying 'Modify the value of a cell' but does not explain their semantics, format (e.g., 0-based vs 1-based indices), or constraints. More detail is needed to compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Modify the value of a cell' and identifies the resource as 'an ALV grid or table control'. It is specific and distinguishes from sibling tools like sap_get_cell_info (read) and sap_set_current_cell (focus setting).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides explicit guidance: it says it only works on editable cells and advises using sap_get_cell_info to check editability first. This tells the agent when to use the tool and what prerequisite to check.

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

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

Annotations only declare that this is neither read-only nor destructive. The description adds real behavioral context beyond that: a button press can open a menu whose menu_items (text and function_code) come back in the response, and that follow-up action routes to a different tool. It does not discuss permissions or how much UI state the press changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and its examples, then the discovery prerequisite and the menu-button follow-up. No filler or restated metadata.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explanation is not required, and the description usefully adds that menu responses expose menu_items. The remaining gap is the unexplained grid_id and no note on side effects or permissions for a non-read-only action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for both parameters. It partially compensates for button_id by pointing at sap_get_alv_toolbar as the source of valid IDs, but grid_id is never explained, so an agent gets no help on which grid identifier to supply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (press) and resource (toolbar button on an ALV grid), with concrete examples (sort, filter, export). It implicitly separates itself from the generic sap_press_button and from sap_get_alv_toolbar, which it names as the discovery counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear prerequisite workflow: find button IDs via sap_get_alv_toolbar, and use sap_select_alv_context_menu_item to complete a menu-button interaction. It stops short of stating when to prefer the generic sap_press_button or any exclusions, so it is clear context rather than full when/when-not guidance.

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

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing post-condition output ('Returns screen info after the press so you can detect navigation or popups') and a user-confirmation policy: presses that may save or ambiguous popup answers prompt the user and surface confirmed_by_user: true. That is exactly the kind of consequence/auth context an agent needs for a mutating click.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then progressively adds discovery, long-text, and confirmation details — all sentences are actionable rather than filler. Slightly dense for a single-parameter tool, but nothing is clearly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 spelled out, yet the description still notes that screen info is returned and how to interpret it for navigation/popup detection. Combined with the ID-discovery and confirmation guidance, an agent has enough to invoke this correctly; only the ALV-button disambiguation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for button_id is 0%, so the description must carry the load, and it does reasonably: it tells the agent where to obtain valid IDs (toolbar/screen-element discovery tools) and shows an example path syntax ('wnd[0]/sbar'). It stops short of stating the ID format rules in general, so a small gap remains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Press (click) a pushbutton or toolbar button on the current SAP screen'), so an agent immediately knows the action and target. It differentiates from discovery siblings by pointing at sap_get_toolbar_buttons and sap_get_screen_elements, though it never explicitly contrasts itself with the very similar sap_press_alv_toolbar_button.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives concrete usage context: discover IDs via sap_get_toolbar_buttons or sap_get_screen_elements, and a specific conditional workflow for message_has_long_text (press 'wnd[0]/sbar', then read with sap_read_list(window_id='wnd[1]')). It lacks an explicit when-not-to-use or a direct steer away from the ALV toolbar sibling, which leaves one plausible ambiguity unresolved.

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

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

Discloses the behavioral effect (triggers sort) and a limitation (does not work on GuiTableControl). Annotations only indicate non-read-only, non-destructive, so description adds value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with action and limitation, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers basic use and limitation, but lacks details on parameter values or output. Has output schema, so return not needed. Missing guidance on how to obtain grid_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% parameter descriptions; the description does not explain grid_id or column beyond implying they refer to ALV grid and column header. Minimal value added over schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (click), target (column header in ALV grid), effect (triggers sort), and a limitation (not on GuiTableControl). This distinguishes it from sibling tools like sap_click_tree_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit context: when to use (to sort an ALV grid column) and what not to use (not on GuiTableControl). Lacks explicit alternatives, but sibling list provides context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description reinforces this with 'Read-only: nothing is written or saved.' It adds useful context about the tool's behavior: it renders a preview card including screenshot, session info, status bar, and pending fields. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. It front-loads the core purpose, follows with usage guidance, and ends with the read-only note. Each sentence earns its place, and the structure is logical and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's function, when to use it, and its read-only nature. However, it does not describe the output/return value (no output schema exists), and it leaves the note parameter entirely unexplained. For a simple preview tool with optional parameters, it is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters. It explicitly mentions pending_fields ('the values the agent is about to write (pending_fields)') but does not mention note or include_screenshot. The parameter names are self-explanatory to some degree, but the description does not clarify their purpose or relationships. Given the low coverage, the description fails to fully compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Render a preview card of the current SAP screen' and lists its contents (screenshot, session/transaction info, status bar, pending_fields). It distinguishes itself from siblings like sap_screenshot (which only captures a screenshot) and sap_get_screen_info (which only fetches info) by combining these into a preview card. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly states when to call: 'Call before significant writes (batch fills, F11 save) or whenever the user asks to see what's about to happen.' This provides clear context and timing. However, it does not explicitly mention when not to use it or alternative tools, so it stops short of a full when/when-not/alternatives treatment.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: what the read returns, that 'changeable' status is included, and specifically that a dropdown's value is the selected text with key as the key.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core purpose, then return shape, then the dropdown edge case, then the prerequisite pointer. Every sentence carries distinct information with no repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return-shape sentence is supplementary rather than required, and annotations carry the safety profile, so the critical gaps are closed. The remaining shortfall is the undocumented field_id format, which is not fully resolved by the sap_get_screen_elements pointer alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single field_id parameter is undocumented in the schema. The description partially compensates by pointing to sap_get_screen_elements for discovering field IDs, but it never says what form a field ID takes or how to read it off a screen.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('the value of a field on the current SAP screen'), with scope limiting it to the active screen. This distinguishes it from sap_set_field (write counterpart) and from the table/textedit readers whose targets are named differently.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a concrete prerequisite rule: 'Use sap_get_screen_elements to discover field IDs on unknown screens.' That tells the agent what to do first when the field ID is unknown. It lacks explicit when-to-prefer-this-over-alternatives guidance (e.g. vs sap_read_textedit or sap_get_cell_info), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true / destructiveHint=false, yet the description still adds real behavioural context: no screenshot is required, the response shape (lines as the user sees them), colour semantics ('negative' = red errors, 'positive' = green, 'total', 'heading'), and the scroll/pagination convention ('pass scroll_to=position+page_size to read the next page'). It stops short of stating limits on max_lines or truncation behaviour, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and routing rule are front-loaded in the first paragraph, followed by a tight bullet list where each bullet adds a distinct fact (colours, scrolling, IDs, the negative case). No sentence repeats a sibling name or the schema without adding meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 re-explained; the description instead covers the remaining decision surface — when this tool applies, when it does not, and how to continue paginating. For a read-only 4-parameter tool this is complete enough to call correctly on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 parameter burden, and it does for three of four: with_ids (adds the first label's ID for setting focus via sap_set_focus), scroll_to (defined operationally as position+page_size for the next page), and window_id (pinned to popup hit lists). max_lines and the default values are never explained, leaving one parameter undocumented in both schema and prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Read a classic ABAP list ... as lines of text') and immediately distinguishes it from the sibling that handles the other case ('a plain list rather than an ALV grid'). It also explains why the resource is special ('every word is its own label, so sap_get_screen_elements leaves the cells out'), so an agent can route correctly 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.

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

Explicit when-to-use ('when a report shows a plain list rather than an ALV grid', 'for F4 hit lists in a popup (window_id='wnd[1]')') is paired with an explicit when-not plus alternative ('is_list=false means this screen has no list: use sap_read_table'). This is the strongest form of routing guidance.

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

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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower, and the description adds genuine behavioral context: content is only readable with the IE browser control, and the Edge control path (SAP GUI 7.70+ default) returns an explanatory `note` instead. This platform-dependent behavior is valuable disclosure beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then the platform caveat, then the prerequisite — a logical order. Three sentences with no filler, though the middle sentence is dense with parenthetical asides.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 like `note` need not be explained), and annotations cover the safety profile. The description adds the platform limitation and the ID-source prerequisite, making it largely complete for a one-parameter read tool, with only the ID format left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single `shell_id` parameter, so the description must carry the load. It partially compensates by pointing to sap_get_screen_elements as the source of valid IDs, but never describes the ID format or type, leaving a real gap for the only parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Read) and resource (content from a GuiShell subtype such as HTMLViewer), which distinguishes it from sibling read tools like sap_read_field, sap_read_textedit, and sap_read_tree that target other UI element types. It does not explicitly name a competing sibling, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a concrete prerequisite workflow: 'Use sap_get_screen_elements first to find shell element IDs,' and explains the runtime condition under which content is actually readable (IE control vs Edge control). It omits explicit when-not/alternative guidance for reading shell content versus other read tools, so it is clear context rather than a full routing rule.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying that the tool returns full text and line count, and explains the max_lines parameter behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with front-loaded purpose and no redundant content. Every sentence adds value: first defines what it does, second explains return and parameter usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple; description covers purpose, return values, and key parameter. Output schema exists to detail return structure. Missing prerequisites like requiring an active connection, but that is likely shared context from sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains max_lines (cap output, 0=all lines) but does not describe textedit_id beyond implicitly referencing it. Partial coverage of parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb "Read" and the resource "multiline text editor (GuiTextedit)", listing use cases. It distinguishes from sibling tools like sap_read_field or sap_read_table by specifying the target UI element.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides clear context for when to use the tool (reading multiline text editors), but does not explicitly mention when not to use it or contrast with alternatives like sap_set_textedit. However, the context is sufficient for an AI agent to infer appropriate usage.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by stating the output format (node hierarchy with texts and column values), though it does not detail edge cases or performance characteristics beyond the large tree hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no superfluous content, front-loaded with the primary purpose, and efficiently covers key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (documenting return format), the description adequately covers purpose, usage guidance, and parameter context. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description relies on context to explain parameters. It implies tree_id identifies the tree and hints at max_nodes via the large tree alternative, but does not explicitly describe max_nodes as a node limit. Partial compensation but not fully clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as reading data from tree controls, specifies the returned structure (node hierarchy with texts and column values), and distinguishes it from sibling tools like sap_get_tree_node_children for large trees and sap_search_tree_nodes for searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly advises against using this tool for large trees, directing to sap_get_tree_node_children, and for finding specific nodes, directing to sap_search_tree_nodes, providing clear when-to-use guidance.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description aligns with those. It adds valuable behavioral details beyond annotations: existing files are never overwritten, the saved file keeps full SAP GUI resolution, inline images are capped at 1920px, and the response includes the absolute path and pixel size. This is meaningful operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into three compact sections: core purpose, fallback usage, and parameter behavior. Every sentence carries operational information with no filler. The main purpose is front-loaded, and the parameter details are grouped logically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two optional parameters, no output schema, and safe annotations, the description covers purpose, when to use it, parameter constraints, file behavior, and response contents. Nothing essential for an agent to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It explains save_path must end in .png, the directory must exist, files are never overwritten, and the file keeps full resolution. It also clarifies inline controls whether the image is embedded and that inline=False skips the image when only the file is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Take a screenshot of the current SAP window.' It also differentiates itself from structured inspection tools by positioning itself as a fallback for screens where the element tree is non-standard. This is unambiguous among many SAP sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly says when to use the tool: as a fallback when structured tools like sap_get_screen_elements, sap_read_field, and sap_read_table return empty or confusing results. It also gives concrete guidance for when to set inline=False, making the selection criteria clear.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the safety profile is thin; the description compensates by disclosing that the resulting top row may differ from the requested one, that requested_position/note signal the mismatch, and that cell IDs are relative to the visible top row. It does not cover other behavioral details (e.g. whether the scroll is reversible or session state side effects), so it stops short of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary action is front-loaded in the first sentence, followed by the exclusion, the preferred alternative, and the response caveat. Every sentence earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-format details are not required, and the description still adds the one non-obvious return caveat (position vs requested_position). For a 2-param scroll tool, nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema gives only integer/string types, so the description must carry the load; it meaningfully explains that 'position' becomes the top row, that the applied position may differ, and how cell IDs index off it. 'table_id' remains self-evident but undocumented, keeping it below a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('Scroll a GuiTableControl to a specific row position') and explicitly excludes ALV grids, which is the key ambiguity given the sibling tools sap_get_alv_toolbar and sap_press_alv_toolbar_button. An agent can distinguish this from the many other table/row siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly names when not to use it (ALV grids, which scroll internally) and routes the agent to a concrete alternative with the exact parameter to use ('prefer sap_read_table with start_row parameter'). This is the when/when-not/alternative pattern in full.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds crucial behavioral context: only searches already loaded/expanded nodes, case-insensitive substring match, and option to search in a specific column. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four clear paragraphs with front-loaded purpose. Each sentence adds value: first paragraph states function, second gives use cases, third details parameter options, fourth highlights limitation with actionable resolution. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but indicated), the description does not need to detail return values. It provides all necessary context for a tree search tool, including a key limitation and reference to a sibling tool (sap_get_tree_node_children).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains tree_id and search_text as required, column for specific column search, and max_results with defaults. However, it does not detail possible values or formats for tree_id or search_text beyond obvious usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches for tree nodes by text and returns matches with full ancestor paths. It specifies the verb 'search' and resource 'tree nodes', and distinguishes from siblings like sap_find_tree_node_by_path by focusing on text search within loaded nodes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly says when to use (deep trees, same labels in multiple branches) and when not to use (collapsed subtrees not searched). Provides guidance to expand parent nodes using sap_get_tree_node_children with expand=true before searching, which is a clear alternative step.

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

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds the critical behavioral constraint that it does not work on GuiTableControl, which is useful for agents. It stops short of explaining side effects like event triggers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences: the first states the core function, the second adds a crucial limitation. No unnecessary details, well front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is concise and covers the main purpose, it lacks explanation of the parameter and prerequisites (e.g., needing an active SAP connection, the ALV grid must be visible). For a tool with one parameter and no schema description, more context is needed to be fully actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single required parameter 'grid_id', and the description does not explain what grid_id is, how to obtain it, or its format. This is a significant gap for an agent to correctly invoke the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: select all rows in an ALV grid. It also specifies the limitation about not working on GuiTableControl, which helps distinguish from other table-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description mentions when to use (ALV grid) and when not to (GuiTableControl), providing clear usage boundaries. However, it does not explicitly suggest alternative tools for GuiTableControl or mention context like selection mode requirements.

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

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

Annotations already indicate mutation (readOnlyHint=false, destructiveHint=false). Description adds context that it affects GuiTableControl specifically, not ALV grids, which is valuable. Does not mention side effects such as scrolling or state changes, but for a simple selection toggle this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence conveying purpose and a critical limitation. No wasted words; front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple parameters (table_id and boolean select) and presence of an output schema, the description captures the core behavior and key limitation. Could be slightly more detailed about the boolean parameter's effect, but overall adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so description must clarify parameters. It implies the boolean 'select' controls selection/deselection but does not explain 'table_id' or provide concrete syntax. Partial value added, but insufficient for full understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action (select/deselect) and resource (all columns in GuiTableControl) with an explicit exclusion of ALV grids. Differentiates from siblings like sap_select_all_rows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides a when-to-use description (selecting/deselecting columns in GuiTableControl) and a when-not (does not work on ALV grids). Does not explicitly mention alternative tools for ALV grids, but the exclusion is helpful.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is already covered. The description adds genuine behavioral context beyond that: the menu must be in an opened state, and the toolbar_button_id parameter collapses open+select into one atomic operation rather than two dependent calls. It stops short of saying what the selected command actually triggers or what happens on failure, so it falls short of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then the workflow, then parameter semantics, using a compact bulleted list for the enum decoding. Every sentence adds information -- no restatement of the title, no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need no prose; annotations cover the safety profile; the description covers the state prerequisite, the alternative call sequence, and all meaningful parameter formats. Nothing an agent needs in order to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden and does so well: it enumerates the accepted formats for menu_item_id (function code like @M00006, visible text, or position descriptor), decodes every select_by enum value including the auto heuristic, and explains toolbar_button_id's role in the atomic path. Only grid_id is left implicit, which is reasonable given the name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb+resource ('Select an item from an opened ALV context menu') and immediately scopes it away from the siblings it could be confused with, sap_press_alv_toolbar_button (opens menus) and sap_select_menu. An agent can distinguish it from those without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly states the two usage paths -- call sap_press_alv_toolbar_button first, or pass toolbar_button_id for a single atomic call -- and marks the atomic path as recommended. It even points to where the available items are listed, leaving nothing to inference.

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

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

Annotations indicate this is not read-only (readOnlyHint=false) and not destructive, which aligns with the description's write operation. The description adds that it can both check and uncheck, but does not disclose failure behavior or prerequisites. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences: first states purpose, second provides usage details. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (handling return details), the description covers input acquisition and the toggle action. It references a sibling tool for input, closing the loop. Slightly lacking in error handling details but complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by explaining the 'selected' parameter's effect ('Set selected=false to uncheck') and how to obtain the 'checkbox_id' via another tool. Adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'select or deselect' and resource 'checkbox on the current SAP screen'. Distinguishes from siblings like sap_select_radio_button and sap_press_button by explicitly targeting checkboxes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit instructions: 'Set selected=false to uncheck' and recommends using sap_get_screen_elements with type_filter='GuiCheckBox' to find checkbox IDs. Gives clear context for how to obtain required input.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation-but-safe profile is known. The description adds the behavioral note that F4 does nothing on a dropdown, but omits what happens on an invalid key/text, whether an existing selection is overwritten, and any error signaling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the sentences are short, but sentence 2 ('Accepts either the technical key or the visible display text') restates sentence 1's 'by its key or display value text', which is redundant filler. The F4/parenthetical contrast sentence earns its place but sits awkwardly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return details are not needed, and annotations cover the safety profile. The description supplies the prerequisite, the alternative, and the accepted value formats, leaving only edge-case/error behavior unaddressed for a two-parameter mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 parameter meaning, and it does explain that key_or_value accepts either a technical key or visible display text and points to sap_get_combobox_entries for valid values. combobox_id remains undocumented, but the non-obvious parameter is well covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Select an entry in a combobox/dropdown') plus the accepted value forms, so the agent knows exactly what the call does. It also differentiates itself from relatives by naming sap_get_combobox_entries as a prerequisite and sap_set_field as an equivalent alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Use sap_get_combobox_entries first to see all valid options' gives a concrete prerequisite/order of operations, and the F4 remark steers the agent away from keyboard-driven selection. There is no explicit when-not or failure condition, but the routing context is clear.

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

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

Annotations show non-read-only and non-destructive. Description explains selection action and return of screen info, clarifying navigational side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences that front-load purpose, then example, then guidance and return info. No extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and output schema implied, the description covers purpose, parameter format, prerequisite discovery, and return value. Sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has one string parameter with 0% coverage, but the description provides a concrete example of the menu_id format ('wnd[0]/mbar/menu[1]/menu[0]'), adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool selects a menu item from menu bar or submenu, with an example path. This distinguishes it from sibling tools like sap_select_checkbox.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit guidance to use sap_get_screen_elements to discover menu structure and mentions return value for detecting navigation. Does not explicitly exclude alternatives but sufficiently contextualizes use.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false) and the description does not disclose behavioral traits beyond the action. It does not mention side effects like clearing previous selections, whether the action requires a visible grid, or any other UI state changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise, front-loaded sentences with no extraneous information. Every sentence serves a purpose: stating the action and providing a usage example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has only two parameters and an output schema, so the description is somewhat adequate for a simple selection operation. However, it lacks prerequisites (e.g., container must be visible) and does not mention what the output schema provides, which is acceptable given the presence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It adds meaning for the 'rows' parameter with an example and explanation of indices, but entirely omits any explanation for 'table_id', which is a required string parameter. This leaves a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool selects multiple rows in an ALV grid or table control, specifying the verb 'select' and the resource 'ALV grid or table control'. This distinguishes it from siblings like 'sap_select_table_row' (single row) and 'sap_select_all_rows' (all rows).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description provides a basic instruction to pass a list of row indices with an example, but lacks explicit guidance on when to use this tool versus alternatives like 'sap_select_table_row' or 'sap_select_all_rows'. Usage context is implied but not clearly stated.

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