GetFunctionGroup

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions paging but does not explain the output shape, response format, truncation behavior beyond the schema's byte-cap note, or side-effect-free nature. Most behavioral detail lives in the parameter descriptions rather than the tool description.

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 no filler: the first states the purpose, the second gives the key operational guidance. The paging instruction is front-loaded and directly actionable.

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 plus schema is adequate for paging behavior, and the required parameter is clear. However, with no output schema and no annotations, the description should give more context about what a retrieved page looks like. It also fails to flag the schema inconsistency where function_group is described as 'Name of the function module', which could confuse an agent into passing a function module name instead of a function group name.

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 100%, and the parameter descriptions already document defaults, bounds, and end-of-file behavior. The description adds a modest practical nudge about using startLine/maxLines for large function groups but does not provide meaningfully new semantic value 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 uses a specific verb and resource, 'Retrieve ABAP Function Group source code,' which clearly identifies the tool's action and object. The object is distinct enough from siblings like GetFunction, GetProgram, and GetInclude, so an agent can differentiate it without inspecting the schema.

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

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

The description gives a clear usage hint for large function groups: page with startLine/maxLines. However, it provides no guidance on when to choose this tool over sibling source-retrieval tools such as GetFunction or GetInclude, and no exclusions or alternatives are mentioned.

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