Check ABAP Cloud readiness

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

The description goes well beyond the readOnlyHint and idempotentHint annotations by detailing the analysis behavior: two parsing passes, diffing, separate reporting of pre-existing broken code, snapshot-dated released-API observations, and explicit limitations (static, parser-level, not exhaustive, no ATC, verdict not certification). This gives the agent an accurate mental model of what the tool does and does not do.

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 long single paragraph, but nearly every clause carries a distinct piece of information: purpose, method, output categories, use cases, limitations, and an example. It is dense rather than padded, though a shorter front-loaded summary could make it slightly easier 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 tool's moderate complexity, an output schema, and 100% parameter schema coverage, the description supplies the crucial non-schema context: what the verdict means, what is excluded, the example invocation, and the separating of baseline vs cloud findings. An agent has everything needed to invoke it correctly and interpret results.

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%, so the input schema already defines files, source, filename, baselineVersion, its enum, default, and limits. The description adds useful context on how baselineVersion participates in the two-pass diff and gives an example call, but that is supplementary; the schema carries the 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 opens with a specific verb and resource: 'Assess how far ABAP source is from ABAP Cloud', and immediately explains the two-pass parsing and diffing method. It distinguishes itself from siblings by describing its static parser-level nature and explicitly separating cloud blockers from broken code, so an agent can tell it apart from check_released_api or lint_abap.

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?

It provides explicit use triggers: 'when someone asks is this code cloud-ready / Clean Core compliant / S/4HANA-cloud safe, before porting classic ABAP into an ABAP Cloud environment, or for a graded tech-debt assessment of an abapGit export.' It also warns when not to trust it: not exhaustive dependency discovery, no SAP connection, no ATC, verdict is not certification. However, it never names sibling alternatives for those other cases, so the guidance stops short of fully explicit routing.

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