GetTypeInfo

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

No annotations are provided, so the description carries the full burden. It discloses that results can be paged and mentions a byte cap that may truncate output ('the byte cap may return fewer lines'), which is useful. However, it does not describe the structure of the returned type information or any other behavioral traits (e.g., read-only nature, potential errors). Given the tool is a retrieval, the safety profile is implicit but not explicitly disclosed. A score of 3 reflects that some behavior is covered but not exhaustive.

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

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

The description is two sentences, front-loaded with the core purpose and followed by a concise paging instruction. No redundant words. Perfectly sized for the information it conveys.

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 no output schema, so the description must hint at what is returned. It says 'ABAP type information' but does not elaborate on the format or content. The paging guidance is helpful, but the absence of any detail about the response structure leaves the agent guessing. Given the simplicity of the tool and the complete parameter documentation, this is a moderate gap, hence a 3.

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%, so all three parameters have descriptions in the schema. The description adds minimal value beyond that, only reinforcing the paging use of startLine/maxLines. Since the schema already documents the parameters thoroughly, a baseline score of 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 verb 'Retrieve' and the resource 'ABAP type information', which is specific enough to distinguish it from sibling tools that retrieve other object types (e.g., GetTable, GetClass). No ambiguity about what the tool does.

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 for handling large results: 'For large results, use startLine/maxLines to page through it instead of retrieving it all at once.' This is clear and actionable. It does not explicitly state when not to use this tool, but the sibling list makes it obvious that this is for ABAP types specifically, so the lack of explicit exclusion is acceptable.

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