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

Annotations already declare read-only, idempotent, closed-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: 'Fast and needs no Node.js' (a performance/dependency trait) and 'Each finding cites the style guide section' (output behavior). It doesn't cover error handling when neither input mode is supplied.

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?

Purpose and the key operating constraint are front-loaded in the first two sentences, followed by a compact Args block that earns its space. Minor redundancy between the prose 'Pass either source ... or object_name' and the Args list, but no wasted sentences.

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, return-value detail is not required, and annotations cover the safety profile, so the remaining burden is small. The one notable gap is that all four parameters are optional, and the description never says what happens if neither source nor object_name is provided or if both are.

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 carry the full burden, and it does document all four parameters inline with meaning: source as ABAP text, object_name as a workspace object 'instead', path as a project folder relative to the workspace root, and max_method_statements as a per-method statement limit. It omits the default of 40 and the default path '.', but the semantics are otherwise self-sufficient.

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: 'Review ABAP against Clean ABAP conventions,' which an agent can act on immediately. It does not, however, differentiate itself from the sibling tool 'lint', which an agent could plausibly confuse it with for static analysis of ABAP code.

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?

Gives clear usage context by explaining the two entry modes: 'source' for a snippet you just wrote versus 'object_name' for an object in the workspace. It offers no explicit exclusions or guidance on when to prefer this over 'lint', so it stops short of full routing 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, idempotentHint and openWorldHint=false, so the description only needs to add context — and it does: it discloses the Node.js runtime requirement and that project configuration (abaplint.json) is auto-detected. It does not state failure modes when Node.js or config is absent, but the safety/idempotency profile is fully covered by 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?

Front-loaded with the core action, then the source-vs-path selection rule, then a compact arg list. Every sentence earns its place; the Args block mildly duplicates wording already given in the paragraph above, keeping it just short of a 5.

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?

An output schema exists, so return values need no explanation, and the description covers the runtime prerequisite, config discovery, and both input modes. Sufficient for a two-parameter, zero-required tool, with only edge behavior (no Node.js, missing config) left unstated.

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 carries the burden, and it defines both parameters meaningfully: `source` as ABAP source text linted instead of a project, and `path` as a project folder relative to the workspace root. This compensates for the bare schema, though it doesn't mention that `path` defaults to '.' when omitted.

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+resource ('Run abaplint static analysis') and enumerates what it checks (syntax, types, obsolete code, naming). It is distinguishable from most siblings, but the nearest neighbor, check_conventions, is never contrasted, leaving slight ambiguity about which to pick for convention checks.

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?

Clearly states the two operating modes: lint the given `source` text, otherwise lint the project at `path`, using the project's own abaplint.json. That tells an agent when each parameter path applies, but it offers no exclusions or explicit alternatives to 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 already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered by structured data. The description adds the folder-scoping behavior but says nothing about recursion, result ordering, or behavior on a missing/invalid path.

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?

Front-loaded with the purpose in one sentence, followed by a compact Args block. No filler, though the 'Args:' formatting is slightly redundant given the schema already lists the path argument.

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?

An output schema exists, so return values need not be explained. However, for a listing tool the description omits whether the scan is recursive, what ordering or filtering applies, and what happens when the folder contains no ABAP objects — leaving meaningful 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?

With schema description coverage at 0% and one parameter, the description carries the burden and does so: it clarifies 'path' is a project folder relative to the workspace root, which the schema's bare 'Path' title with default '.' does not convey. Some ambiguity remains (e.g., whether nested folders are searched).

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 ('List') and resource ('ABAP objects (classes, interfaces, programs...)') with the scoping context ('in an abapGit folder'). It is clear what the tool returns, though it never names or contrasts itself with the siblings (outline_object, check_conventions, lint, run_tests).

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?

There is no guidance on when to use this tool versus the sibling tools, and no prerequisites or exclusions. Usage must be inferred entirely from the one-line purpose statement.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that it introspects code structure (visibility, signatures, line ranges), which is useful framing, but says nothing about limits on large objects, cost, or failure modes (e.g. non-existent object names).

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 one-sentence purpose is front-loaded and information-dense, followed by a compact Args block. The Args block partly restates what the schema already declares, which is mildly redundant but not costly.

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, the description needn't explain return values, and annotations cover safety semantics. Both parameters are explained despite 0% schema coverage, leaving only the absence of sibling-routing guidance as a 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?

Schema description coverage is 0%, so the description must carry the param burden, and it does: object_name is given with a concrete example ('ZCL_ORDER_TOTAL') and path is explained as the project folder relative to the workspace root. This compensates well for the empty schema, though it does not state the default '.' behavior or format constraints.

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 ('Describe') and resource ('a class or interface') and enumerates exactly what is returned: methods with visibility and signature, attributes, test classes, and method-body line ranges. It is clearly distinguishable from lint/run_tests by the static-structure nature of the output, though it never names a sibling explicitly.

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?

There is no guidance on when to pick this over list_objects, check_conventions, or lint. Usage is only inferable from the nature of the output described; no prerequisites, scope limits, 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.

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

Annotations declare readOnlyHint=false, openWorldHint=true and idempotentHint=true, and the description is consistent with that, adding real behavioral detail: the run is transpiled and executed on Node.js, no SAP backend is contacted, and `install` triggers a dependency reinstall. It does not mention expected runtime, failure reporting, or how test results surface, so it stops short of 5.

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?

Purpose is front-loaded in the first sentence, followed by a compact two-line Args block; every line contributes information. Slightly verbose on the toolchain parenthetical, but nothing is wasted.

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 two-parameter tool with an output schema present, the description covers what the tool does, where it runs, its side effects, and both parameters. The only missing element is routing guidance relative to the sibling check tools, which is a minor 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?

Schema description coverage is 0% (only bare titles 'Path' and 'Install'), so the description carries the burden and does so: it explains that path must be a project folder containing package.json, and that install reinstalls npm dependencies before testing. This meaningfully upgrades both parameters past the schema's titles.

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+resource ('Run the ABAP Unit tests') and adds the execution environment (Node.js via abaplint transpiler + open-abap, invoked with `npm test`), which makes it clearly distinct in kind from lint/check_conventions even though no sibling is named.

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 is implied by the name and by the note that no SAP system is needed, which helps an agent decide it can call this in a bare environment. However, it never states when to prefer this over the sibling tools (lint, check_conventions) or any prerequisites beyond a package.json.

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