Lint ABAP source

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

Annotations already declare read-only and idempotent, but the description adds significant context: fully offline, no ATC, cannot judge undefined objects unless provided, and preset behavior differences. It also explains focus tags and rule overrides. 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 dense but well-structured: purpose first, then when to use, limitations, preset semantics, focus/overrides, alternative, and an example. Every sentence conveys distinct information—no filler or repetition. The length is justified by the tool's complexity.

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 5 parameters, nested objects, enums, and output schema, the description covers all critical aspects: input types, limits (via schema), return value contents, preset meanings, and the boundary case (check_cloud_readiness). It even includes an example, making it self-contained 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?

Schema coverage is 100% (all five parameters have descriptions), but the description adds meaningful semantics beyond the schema: explains why the default preset skips whole-program checks, how focus packs work with rule overrides, how filename omission triggers type inference, and includes a concrete invocation example that maps to 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 starts with a specific verb and resource: 'Run abaplint static analysis over ABAP, CDS or behavior-definition sources' and clearly states the output (structured findings). It distinguishes from siblings by naming check_cloud_readiness as the alternative for migration verdicts, and the detail about offline operation further differentiates it from system-connected 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?

Explicit use case: 'Use this when you have written or modified ABAP code and want style and correctness feedback before it goes anywhere near a system.' It provides exclusions (does not connect to SAP system, does not run ATC) and presets with scenario guidance (style for isolated snippets, full when all dependencies provided). It names an alternative tool for a different intent.

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