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 readOnlyHint=true and destructiveHint=false. Description adds minor context about being a common starting point but no additional behavioral traits. No contradiction.

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 core purpose. No redundant or irrelevant 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?

Simple tool with 2 parameters, annotations, and output schema. Description covers main usage. Lacks error handling details (e.g., when no session exists), but adequate 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 has 0% description coverage. Description explains that indices 0 refer to first session, adding meaning beyond schema defaults. Does not cover other possible index values.

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 'Connect to an already open SAP session', specifying verb and resource. Distinguishes from sibling tools like sap_connect (new connection) and sap_disconnect.

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 when to use ('when SAP is already logged in') and references alternative sap_list_connections to explore sessions. Lacks explicit when-not-to-use scenarios.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by listing the returned metadata fields (value, changeable, color, tooltip, style, max_length) and highlighting the incompatibility with GuiTableControl. No contradictions and no missing behavioral traits.

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 at two sentences, front-loading the purpose and key details. It efficiently communicates the core functionality and a critical limitation. Minor improvement could come from structuring the return fields as a list, but current form is functional.

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, the description adequately covers return values by listing the fields. However, the lack of parameter descriptions means the description is incomplete for invocation. For a tool with three required parameters and no schema descriptions, the agent needs more context to use it 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?

The description provides no explanation of the parameters (grid_id, row, column) beyond their names. With 0% schema description coverage, the burden on the description is high. Without explaining what grid_id refers to (e.g., the ID from sap_get_screen_elements) or the expected format for row and column, the agent lacks sufficient guidance to invoke the tool correctly.

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 gets detailed cell metadata from an ALV grid, specifying the exact fields returned. It explicitly notes it does not work on GuiTableControl, distinguishing it from sibling tools like sap_get_current_cell or sap_read_table. The verb 'Get' and resource 'cell metadata' make the purpose 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 provides clear guidance by stating it works on ALV grids and explicitly excluding GuiTableControl. However, it does not mention alternative tools for other grid types or when to prefer this over closely related siblings, such as sap_get_current_cell. This is a minor gap, 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 already establish readOnlyHint=true and destructiveHint=false, ensuring the agent knows it's a safe read operation. The description adds value by specifying the kind of information returned (column names, titles, widths, visibility), providing behavioral context 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 concise (four lines) and front-loaded with the main action and return values. Every sentence serves a purpose, and the structure is well-organized with 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?

The output schema exists (though not shown), so return values may be documented there. However, the single parameter 'grid_id' lacks any explanation in both the schema and the description. For a tool with only one parameter, the omission of parameter context makes it incomplete 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?

Schema description coverage is 0%, meaning the parameter 'grid_id' has no description in the schema. The tool description does not mention or explain this parameter at all. Given the low coverage, the description should compensate but fails to do so, leaving the agent uncertain about what value to provide for grid_id.

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 ('Get detailed column info') and the resources ('ALV grid or table control'). It also explicitly mentions the returned data (column names, titles, widths, visibility) and distinguishes from the sibling tool 'sap_read_table' by suggesting it as a lighter 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?

The description provides explicit guidance: it states the tool is 'useful for understanding table structure' and offers an alternative ('For a lighter alternative, use sap_read_table with columns_only=true'). This clearly indicates when to use this tool versus when to use a sibling.

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?

The description discloses meaningful behavior beyond the readOnly/destructive annotations: default max_depth of 2, recursion behavior, docking containers being listed separately in the response, table controls collapsing to one element, and expand_tables causing large output. It also warns about response size on complex screens, which helps an agent anticipate outcomes before calling.

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 long, but every sentence adds operational value. It front-loads the core purpose and usefulness, then systematically covers each parameter and edge case, with examples inline. Nothing is filler; the length is proportionate to the tool's complexity and the absence of schema-level parameter descriptions.

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 is complete for an agent to select and invoke this tool correctly. It covers purpose, when-to-use, alternatives, parameter semantics, special screen regions, table-control behavior, and response-size considerations. An output schema exists, so not detailing the return shape is acceptable, and the description still mentions key response concepts like 'docking_containers'.

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 full burden for all five parameters, and it does. It explains max_depth with concrete values, type_filter with a real example ('GuiTextField,GuiCTextField'), container_id with default and special targets, expand_tables with the 'lists every visible cell (large)' caveat, and changeable_only as a response-reduction switch.

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 'Discover all elements on the current SAP screen,' which is a specific verb-resource pairing, then explains its main use case: 'finding field IDs when working with a new screen.' It also distinguishes itself from sibling tools like sap_read_table by explaining that a table control is 'ONE element here, not one per cell.'

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 guidance is explicit and comprehensive. It tells agents when to use the tool, when to use alternatives ('use sap_read_table(columns_only=true) for its columns and cell_id templates'), and how to adapt calls to the situation: type_filter for input fields, max_depth=1 for overview, max_depth=3+ for nested layouts, and container_id='wnd[0]/mbar' for menu bars. No conditions are left 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?

The description reveals that the tool reads from `session.ActiveWindow` so the response always reflects what the user sees, and explains the `active_window` field and title. This adds valuable behavioral context beyond the annotations (readOnlyHint=true, destructiveHint=false). 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?

The description is a bit lengthy but well-structured with a clear main sentence followed by additional context. Every sentence adds value, covering the source of data, what fields are returned, and how it relates to other tools. Slightly verbose but still concise for the information provided.

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 zero parameters and the presence of an output schema, the description provides complete context: it lists the returned fields, explains the data source, and mentions the relation to action tools. The agent has all necessary information to understand and use the tool 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?

The tool has zero parameters, and the schema coverage is 100%. The description does not need to add parameter semantics, but it effectively explains what the tool returns. Baseline of 4 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 that it retrieves current SAP screen info including transaction, program, screen number, window title, and status bar message. It also distinguishes itself from the sibling tool sap_get_popup_window by noting that the latter is for full popup content.

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 explains that every action tool returns this same screen info, so the agent knows when a popup appears. It also suggests using sap_get_popup_window for full popup content, providing clear guidance on when to use this tool vs. alternatives. However, it does not explicitly 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 readOnlyHint=true and destructiveHint=false, ensuring safe usage. The description adds value by specifying the exact data returned (system, client, user, transaction, screen), which is beyond the annotations. 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?

The description is a single, concise sentence that front-loads the verb and resource. Every word is necessary and there is no 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?

With zero parameters and an output schema existing, the description is complete. It clearly explains what information the tool retrieves, which is sufficient for a simple read 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?

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it meets the requirement for a parameterless 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 verb 'Get information' and the resource 'current SAP session', listing specific attributes (system, client, user, transaction, screen). This distinguishes it from sibling tools like sap_get_screen_info which retrieve different data.

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 retrieving session metadata but does not explicitly state when to use or alternatives. Given the tool's simplicity and zero parameters, minimal guidance is acceptable but not explicit.

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?

Discloses behavioral traits for each action (e.g., 'press a specific button by its text or tooltip', 'auto: take only a clearly safe action; otherwise return the popup read-only'). Annotations are minimal but no contradiction; description adds valuable 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?

Well-structured with a clear first sentence and bullet-pointed actions. Every sentence adds value without unnecessary length.

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 all necessary aspects: return value description includes popup contents, classification, requested action, and post-action state. Output schema exists but description still provides helpful summary.

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 0% schema description coverage, the description fully explains the 'action' enum values and the role of 'button_text' when action is 'press'. This compensates completely for the lack of schema comments.

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 'Read and optionally act on the current popup/modal dialog', lists specific actions (read, confirm, cancel, press, auto), and distinguishes from sibling tools like sap_get_popup_window by combining inspection and response.

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 usage condition 'Use when active_window shows wnd[1] or higher' and explains each action's purpose. Lacks explicit when-not or alternatives but is clear enough for correct 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 declare readOnlyHint=true and destructiveHint=false, so the description's 'list' verb aligns. No additional behavioral traits disclosed (e.g., performance, error handling).

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 of 8 words, direct and front-loaded with key information. No unnecessary 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?

Given zero parameters, strong annotations, and an output schema (not shown), the description covers the basics. Could mention that it only lists connections in the current SAP GUI session, but not essential.

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, so schema coverage is 100%. Description adds no parameter info, which is acceptable as there is nothing to add.

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 uses specific verb 'list' and resource 'open SAP connections and sessions', clearly stating the tool's function without tautology. Differentiates from siblings like sap_connect or sap_get_session_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?

No guidance on when to use this tool versus alternatives such as sap_get_session_info or sap_get_screen_info. The description is silent on context 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?

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 already declare readOnlyHint=false and destructiveHint=false, indicating the action modifies state but is not destructive. The description adds no further behavioral context (e.g., what occurs after pressing, error behavior). However, it does not contradict annotations, and the verb 'press' implies a standard UI interaction, so the description is minimally 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?

The description is two succinct sentences. The first sentence clearly states the action and examples. The second immediately provides a useful cross-reference to a related tool. No wasted words, and the most critical information is 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?

Given the presence of an output schema (not shown), the description does not need to detail return values. The tool is simple (press a button). However, it lacks details on preconditions (e.g., grid must be visible), error handling (e.g., button not found), or side effects (e.g., navigation). Still, for a straightforward UI action, it is 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?

The input schema has 0% description coverage, so the description carries the full burden of explaining parameters. It does not describe grid_id (identifying the ALV grid) or button_id (the button identifier). Although the tool's purpose hints at these, no additional semantic detail is provided beyond what is obvious from the parameter names.

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 uses a specific verb ('press') and identifies the exact resource ('toolbar button on an ALV grid') with concrete examples ('sort, filter, export'). This clearly differentiates it from sibling tools like sap_press_button (generic button) or sap_select_alv_context_menu_item (context menu).

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 directs the agent to use sap_get_alv_toolbar to find button IDs, which is a crucial preparatory step. It does not provide when-not-to-use scenarios or alternatives, but the mention of the prerequisite tool provides good context for 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?

The description discloses that after pressing, it returns screen info to detect navigation or popups, adding value beyond the annotations. Annotations indicate non-read-only and non-destructive, but the description clarifies the post-action behavior and side-effect detection.

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 with no wasted words. The first sentence presents the core action, the second explains return value, and the third provides discovery guidance. Efficient and 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?

Given the tool's simplicity (one required parameter, output schema exists), the description adequately covers the purpose, usage hints, and return behavior. It is complete enough 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?

The input schema has no description coverage (0%), so the description must compensate. It explains that button_id can be discovered from other tools, but does not specify format or validation rules. This adds some meaning but not deep detail.

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 ('Press (click) a pushbutton or toolbar button') and the target ('on the current SAP screen'). It distinguishes the tool from siblings like sap_click_tree_link and sap_press_alv_toolbar_button by specifying the button type and interaction.

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 guidance on when to use the tool (to press buttons) and how to discover button IDs via sap_get_toolbar_buttons or sap_get_screen_elements. However, it does not explicitly state when not to use it or mention alternatives, 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?

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. The description adds value by detailing the return structure (value, type, changeable status, labels) and specifying the context (current SAP screen), which aids agent understanding of behavior 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 three sentences, each serving a distinct purpose: stating the action, listing returns, and providing usage guidance. No redundant or unnecessary text; highly efficient.

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 is complete enough: it explains the purpose, parameter acquisition, and return data. It could mention error scenarios (e.g., invalid field_id) but is otherwise sufficient for a simple read 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?

The schema has no description for field_id (0% coverage). The description indirectly explains how to get valid field IDs (via sap_get_screen_elements) but does not elaborate on the format or constraints of field_id itself. This adds some value but does not fully compensate for the missing parameter documentation.

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 reads a field value from the current SAP screen, specifies the return data (value, type, changeable status, labels), and distinguishes from the sibling tool sap_get_screen_elements which is for discovering field IDs. Verb+resource is explicit.

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 the agent to use sap_get_screen_elements to discover field IDs when the field ID is unknown, providing a clear alternative and when to switch tools. This is a high-quality guideline.

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 known. The description adds useful behavioral context: it returns lines without screenshots, explains the 'no table object' behavior (every word is a label), and describes scroll semantics (scroll_to=position+page_size). This goes beyond what annotations provide, though it doesn't mention return structure details (output schema exists, so that's covered).

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 well-structured with a clear opening, a use-case context paragraph, and a bulleted list of key features. It front-loads the main purpose and then details specifics. Slightly verbose in the second paragraph but each sentence adds value; the bullet list 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 there is an output schema (not shown) and annotations covering safety, the description is largely complete. It covers usage context, parameters, color handling, scrolling, and focus. The only minor gap is not explicitly stating what happens with max_lines (e.g., truncated output), but this is likely inferable from 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?

Schema description coverage is 0%, so the description must explain parameters, and it does. It explains with_ids (adds line IDs for focus setting), scroll_to (for pagination), and window_id (default wnd[0], but example shows wnd[1] for popup). max_lines is implied but not explicitly described; still, the coverage is strong.

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 reads a classic ABAP list as lines of text, specifies the exact input type (WRITE output, SAPMSSY0 screen 120), and distinguishes it from ALV grids and other list-like structures. It also explicitly differentiates from sap_read_table and sap_get_screen_elements, making its purpose 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 explains when to use this tool (plain lists, F4 hit lists) and when not to use it (is_list=false means use sap_read_table). It also provides concrete guidance on scrolling, colors, and focus setting, covering both use cases and 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?

Annotations already indicate readOnly and non-destructive behavior. The description adds that output depends on shell type, providing further behavioral context. It does not detail error cases but is sufficient.

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 earning its place: purpose, behavior, usage tip. Front-loaded and efficient with 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 output schema exists (no need to explain returns), the description covers purpose, behavioral nuance, and prerequisite. It omits error handling but is complete enough for an agent on a medium-complexity 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?

With no schema parameter descriptions (0% coverage), the description compensates by explaining how to obtain the shell_id via another tool. This adds practical meaning beyond the raw 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 verb 'Read' and resource 'content from a GuiShell subtype'. It specifies the types of content (HTML, URL, text) and distinguishes this tool from siblings like clicks and selections.

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_screen_elements first to find shell element IDs, providing a clear prerequisite. While it doesn't state when not to use, the guidance is practical and contextually complete.

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?

Even though readOnlyHint=true and destructiveHint=false already cover the safety profile, the description adds substantial operational behavior: auto-detection of table type, the table_type field in the response, columns_only=true returning metadata with no data, per-column cell_type and cell_id template for TableControls, and start_row pagination semantics. This goes well beyond what annotations alone 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 runs ~120 words and is dense but every sentence earns its place: purpose, auto-detection behavior, table_type routing, columns_only mode, column filtering, and pagination. It is front-loaded with the core purpose and follows a logical order. It could be tightened slightly, but there is no fluff or repetition of schema 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?

With an output schema present and read-only annotations, the description covers most of what an agent needs: table type scope, mode switching, column selection, pagination, and next-step routing. The main completeness gap is the undocumented required table_id (where to get it) and max_rows semantics, which matter for correct invocation on a 5-parameter 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?

With 0% schema description coverage, the description carries the full burden and does explain columns_only (schema discovery, cell_type/cell_id template), columns (CSV selection), and start_row (pagination) meaningfully. However, it never explains the required table_id parameter — where an agent obtains it or what identifies a table — nor does it clarify max_rows behavior. Missing the one required parameter is 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 opens with a specific verb+resource ('Read rows from a table on the current screen') and precisely scopes the target to two UI constructs: ALV grid and TableControl. This clearly distinguishes it from siblings like sap_read_field (single field), sap_read_list (list output), and sap_get_cell_info (individual cell), so an agent can select it correctly without inspecting 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?

The description gives explicit context for when to use the tool: any table on the current screen, with the ALV-vs-TableControl distinction spelled out. It also routes the agent to the correct follow-up tools based on the returned table_type (sap_get_alv_toolbar vs sap_scroll_table_control). It stops short of explicitly naming alternatives NOT to use (e.g., sap_read_field), but the scoping is clear enough that exclusion is mostly implied.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds value by specifying the tool does not work on ALV grids, which is a key behavioral constraint. It does not elaborate on other behaviors like requiring visibility or scroll limits, but the annotations already cover safety.

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: three sentences with no filler. The first sentence states the core action, the second adds a critical constraint, and the third provides an alternative. 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?

Given the tool has 2 required parameters and an output schema (not shown but exists), the description covers the key behavioral aspects: action, constraint on ALV grids, and an alternative. It could mention that the table control must be visible or that scrolling is relative, but overall it is adequately 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 coverage is 0%, so the description must compensate for the missing parameter documentation. The description does not explain what table_id or position mean beyond the implicit 'row position'. The agent must infer the meaning, which could lead to misuse. Minimal value added for parameter semantics.

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 scrolls a GuiTableControl to a specific row position using a specific verb and resource. It differentiates from siblings like sap_read_table by specifying it does not work on ALV grids, though it does not explicitly mention it is for navigation within the visible window.

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 not to use it (does not work on ALV grids) and suggests an alternative tool (sap_read_table with start_row) for reading data at an offset. This provides clear guidance on 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 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 indicate readOnlyHint=false (modification) and destructiveHint=false, which are consistent. Description adds context about prerequisite (menu must be open) and atomic alternative. Could mention if selection triggers actions, but sufficient.

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?

Concise with 7 sentences; front-loaded main purpose. Every sentence adds value, no 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?

Covers purpose, prerequisite, alternative usage, parameter details, limitations. Has output schema, so return values are handled. Complete for a context menu selection 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 coverage is 0% but description explains menu_item_id can be function code, text, or position descriptor, and clarifies select_by modes with examples. Fully compensates for 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 'Select an item from an opened ALV context menu,' specifying the action and resource. It distinguishes from sibling tools like sap_press_alv_toolbar_button and sap_select_menu by focusing on context menus.

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: use sap_press_alv_toolbar_button first or pass toolbar_button_id for atomic call. Explains select_by options and limitations (no way to enumerate menu items).

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 indicate readOnlyHint=false and destructiveHint=false, which is consistent with the description's 'Select' action. The description adds behavioral detail by noting that the tool accepts either a technical key or display text, which is not captured in annotations. This adds value beyond the annotated metadata.

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 concise sentences with no extraneous information. The first sentence states the primary purpose, and the second adds key usage details (dual input and prerequisite). It is front-loaded and efficient.

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 low complexity (2 required string parameters), the presence of an output schema, and annotations, the description covers the essential aspects: purpose, input alternatives, and a prerequisite step. It does not elaborate on error handling or exact behavior upon selection, but for a simple UI interaction, this is adequate. A score of 4 reflects minor omissions.

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 'key_or_value' can be either a technical key or visible display text. The 'combobox_id' parameter is not explicitly described but is inferable from the tool name and context. The partial explanation for one of two parameters justifies a score of 4.

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 explicitly states the action ('Select') and resource ('entry in a combobox/dropdown') and specifies the method (by key or display value). It clearly distinguishes this tool from siblings like 'sap_select_checkbox' or 'sap_select_radio_button' by focusing on combobox/dropdown interaction.

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 using 'sap_get_combobox_entries first to see all valid options', providing a clear prerequisite. While it does not explicitly state when not to use this tool, the context of sibling tools makes the resource type differentiation clear. A score of 4 reflects the useful guideline without full 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?

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.

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

Annotations already indicate non-read-only and non-destructive. The description adds context on how to obtain the radio ID, but does not elaborate on behavioral details like deselection of other radio buttons. It is adequate but minimal.

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: first states the purpose, second provides actionable guidance. No unnecessary words, efficient and clear.

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 one-parameter action tool, the description covers the essential aspects: what it does and how to get the parameter. It doesn't mention return values, but that is not critical given the simplicity. The presence of an output schema is noted but not explained, but still adequate.

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