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

No annotations exist, so the description carries the full burden, yet it says nothing about what a 'status' result contains (connected/disconnected, bridge version, endpoint, latency) or whether an unreachable bridge raises an error or returns a negative status. It also doesn't disclose that this is a local-only network probe with no filesystem or workspace side effects, which would reassure an agent it is safe to call speculatively.

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?

A single sentence with no filler, front-loading the verb and the endpoint pair being probed. Nothing could be removed without losing meaning.

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 is inherently simple (zero input, no nested objects), and the description covers what is probed. However, with no output schema and no annotations, the description is the only source of information about the result shape and failure behavior, and it leaves both unaddressed.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description correctly conveys that the call is argument-free and is driven entirely by the local server/bridge relationship.

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 ('Checks') and a precisely scoped resource: connectivity between this MCP server and the LiskinLabs KUKA KRL extension local bridge. An agent can distinguish it from the content-oriented siblings (lint, lookup, telemetry) without inspecting the schema. It loses a point only because it doesn't explicitly contrast itself with the other diagnostics sibling, krl_workspace_diagnostics.

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 rather than stated: nothing tells the agent to call this before/after other krl_* tools or when a bridge-related failure occurs. No alternatives or exclusions are named (e.g., what to do if the bridge is down). Adequate but relies on the agent inferring the trigger condition.

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?

With no annotations, the description carries the full burden. It discloses the KUKA KRL Professional license requirement and names the output artifacts, but omits whether the operation is read-only, how the output is formatted (e.g., text vs. image), and any error or side-effect behavior.

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 tightly written sentences with the purpose and license requirement front-loaded. Every sentence contributes necessary information without redundancy.

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 is simple (one parameter) but lacks an output schema, and the description does not explain the return format of the CFG or Mermaid diagram, nor does it address error handling. Given the absence of annotations, more behavioral detail would be expected.

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?

The schema has 100% description coverage for the single 'code' parameter, so the baseline is 3. The description adds no additional syntax or format details beyond what the schema already provides.

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 states a specific verb (Generates) and two concrete output artifacts (Control Flow Graph and Mermaid diagram) for a KRL routine. It does not explicitly contrast with sibling tools, but the unique output makes the tool distinguishable.

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 license prerequisite is mentioned, which is useful context, but there is no explicit guidance on when to use this tool versus alternatives like krl_lint_snippet or krl_deep_safety_audit. Usage is only implied by the tool's purpose.

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?

No annotations are provided so the description carries the full burden. It discloses the KUKA KRL Professional license requirement and what categories of risk are checked, which is genuinely useful context, but it never states whether the code is only statically analyzed or executed, how long the audit takes, or how findings are surfaced.

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, front-loaded with the core action and the hazard list, then the licensing caveat. No padding or repetition.

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 single-parameter analysis tool with no output schema, most of what an agent needs is present: the scope of checks and the license prerequisite. The notable remaining gap is what comes back (a findings list, severity ratings, pass/fail), which matters since there is no output schema to describe it.

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?

There is only one parameter and schema description coverage is 100%, so the schema already explains 'code: KRL code to audit.' The description adds no format constraints, size limits, or expectations about the input beyond what the schema provides — baseline 3.

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 — deep safety and motion verification of KUKA KRL code — and enumerates concrete hazard classes (advance run hazards, payload verification, actuator-sensor races, turn unwind). This clearly separates it from krl_lint_snippet and krl_safe_auto_repair, 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?

The word 'deep' implies a heavier-weight counterpart to the lint tool, and the licensing prerequisite is stated. However, there is no explicit when-to-use guidance (e.g., 'use after lint passes' or 'use before deployment') and no when-not-to-use or named alternatives.

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?

With no annotations, the description carries the full burden; it does disclose that the analysis is static/offline and lists the checks performed, which implies a non-mutating read. It does not say whether findings carry severity or line numbers, what happens on unparsable input, or confirm that no code is executed or modified.

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, no filler, with the tool's nature front-loaded and the check list used efficiently to convey capability. Every clause earns its place.

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 one-input linting tool with no output schema and no annotations, the definition should at least indicate the shape of the result (list of findings with locations/severities). It covers what the tool looks for but not what the agent gets back or how to interpret a clean run.

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?

There is a single required parameter with 100% schema description coverage, so the schema already defines 'code' adequately. The description adds no constraints or format details (encoding, size limits, full module vs fragment) beyond what the schema states, so baseline 3 applies.

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 ('static code analysis for KRL code snippets') and then enumerates the exact defect classes it detects (uninitialized $TOOL/$BASE, loops without EXIT, division by zero, unbalanced folds, I/O overflows, non-ASCII). The 'snippet' scope distinguishes it from the workspace/file-level siblings such as krl_workspace_diagnostics and krl_deep_safety_audit.

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 words 'Fast offline' imply this is the lightweight, no-workspace-needed check, which hints at when to prefer it. But no sibling is named and there is no explicit when-not guidance (e.g. use krl_deep_safety_audit for a full audit, krl_workspace_diagnostics for whole-project scanning), leaving routing to inference.

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?

With no annotations, the description carries the full burden; it does disclose that the operation is a read, requires a Professional license, and needs a live connection, which is real added context. It omits failure behavior if the controller is disconnected, latency/freshness of the telemetry, and whether the call blocks or errors.

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?

A single sentence, front-loaded with the action and resource, then the payload fields, then the prerequisites. The parenthetical field list is dense but every item is informative; only the placement of licensing at the tail costs it a perfect score.

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?

No output schema exists, and the description compensates by enumerating the returned telemetry fields, which is exactly what an agent needs to know. Combined with license/connection constraints, the coverage is solid; only disconnect/error behavior is left unaddressed.

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?

The tool takes zero parameters, so per the baseline this starts at 4. The description correctly implies no input is required, and the long field enumeration actually reads as return-value documentation rather than a missing-parameter gap.

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 — 'Reads real-time operational telemetry from ... KUKA Robot Controller' — and enumerates the exact data fields returned (TCP position, joint angles, $OV_PRO, mode, alarms). This clearly separates it from documentation-style siblings like krl_syntax_reference or krl_workspace_diagnostics, though it never explicitly contrasts itself with krl_bridge_status, which is the nearest neighbor.

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 prerequisites ('Requires KUKA KRL Professional license and active controller connection') imply when the tool is callable, but the description never states when to choose this over siblings or what to do if preconditions fail. Usage is implied rather than directed.

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?

With no annotations, the description carries the full burden; it discloses the return payload (explanation, root cause, remediation) but never states that this is a read-only lookup, nor what happens for an unknown or out-of-range message ID, nor the scope of code coverage. Useful but incomplete behavioral context.

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?

A single front-loaded sentence that wastes nothing structurally, though the long enumerated list of example message numbers partially duplicates the examples already present in the schema field description.

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?

Two parameters, fully documented schema, no output schema — and the description does explain what comes back, so an agent knows the shape of the result. Only the unknown-code and coverage behavior are left unspecified, which is a minor gap for a simple two-parameter lookup.

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 the baseline is 3. The description reinforces the message_id format by listing valid example codes and implies that output is localized, which lightly supports the locale parameter, but adds no detail the schema does not already carry.

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 (Resolves), a precisely scoped resource (KUKA KSS error and status message numbers), and the three outputs it produces (localized explanations, root causes, remediation steps). None of the siblings do this, so an agent can distinguish it immediately.

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 strongly implied — you call it when you have a numeric KSS message code — but there is no explicit when-to-use/when-not statement and no routing guidance versus nearest siblings like krl_lookup_system_var or krl_workspace_diagnostics. The agent must infer the trigger condition.

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?

With no annotations provided, the description carries the full burden and does disclose useful return content: description, type, range, read/write permissions, syntax, examples, and six languages. However, it omits behavior for unknown variable names, error handling, and does not clarify read-only nature beyond implication.

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 single front-loaded sentence with no wasted framing. The parenthetical list of variable examples is slightly lengthy but directly useful for an agent recognizing valid inputs.

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 read-only lookup tool with no output schema and no annotations, the description adequately states what information is returned and the supported languages. It could be stronger by noting error behavior or whether all listed variables are guaranteed for every KSS version in range.

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 the parameters are already well documented. The description adds marginal value by listing example variable names and mentioning six languages corresponding to the locale parameter, but it does not explain format or semantics 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 ('Looks up') with a precise resource ('KUKA System Software system variable') and scopes it to KSS 8.3-8.7. It implicitly distinguishes itself from siblings like krl_lookup_kss_message by focusing on system variables, though it does not explicitly name an alternative.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Usage is only implied by the verb 'Looks up'.

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?

With no annotations, the description carries the full burden; it does disclose a real prerequisite (requires the LiskinLabs KUKA KRL extension) and frames the operation as a read of text content. It does not say what happens on missing files, non-text/binary files, encoding, size limits, or whether errors are raised or returned, which matters for an unannotated tool.

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 short sentences, zero filler, with the operation and scope front-loaded before the environment prerequisite. Every sentence carries information the agent needs.

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 read-only, single-parameter tool with no output schema, the description covers the action, the file domain, and the environment prerequisite; 'text content' also hints at the return shape. It is only slightly short on failure behavior and the workspace boundary, which are minor for a simple read.

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% and the single path parameter is documented there, including that it may be relative or absolute. The description adds no further path semantics (workspace-rooting, extension requirements, traversal limits), so it sits at the baseline expected when the schema does the work.

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 (Reads) and resource (text content of a KRL program or data file) and scopes it to the active IDE workspace, so the agent knows exactly what it retrieves. It does not explicitly contrast itself with the sibling krl_workspace_files, leaving the read-vs-list distinction to be inferred from names.

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 mention of 'active IDE workspace' and the extension prerequisite, which signals when the tool is available. There is no explicit when-to-use guidance, no exclusion of alternatives such as krl_workspace_files for enumerating files, and no note about what to do for files outside the workspace.

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?

With no annotations, the description bears the full disclosure burden. It usefully signals that repairs are 'safe' and output is 'verified,' implying the original code is returned transformed rather than mutated in place, but it does not state what happens on unrecoverable hazards, whether changes are reversible, or what 'verified' checks.

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?

One dense sentence with the action and hazard enumeration front-loaded and no filler. The parenthetical list is long but each item is informative rather than redundant.

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 simple one-parameter tool this is close to sufficient, and 'outputs verified repaired code' hints at the return value. But with no output schema, the description should more fully explain what the returned payload contains and how failure/partial-repair cases are reported.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains that it takes KRL code. The description adds no format, size, or encoding constraints beyond that, which is the expected baseline when the schema does the work.

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 (repairs) and resource (KRL code), and enumerates the concrete hazards handled (BOM/encoding, advance run desyncs, inline form folds, trailing whitespace, uncommitted payload), which goes well beyond a tautology. It does not explicitly distinguish itself from the linting sibling krl_lint_snippet, so it falls short of a 5.

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 license prerequisite (KUKA KRL Professional) is a useful gating condition stated up front. However, there is no guidance on when to repair versus when to lint first (krl_lint_snippet) or run diagnostics, so the choice among siblings is left implicit.

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?

With no annotations, the description carries the full burden. It implies a safe, static reference lookup ('authoritative syntax definitions and examples'), which hints at read-only behavior, but it never states that no workspace state is touched, gives no response format or size guidance, and offers no coverage detail on that front.

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?

A single sentence that front-loads the verb, the resource, and the keyword coverage with zero filler. The parenthetical keyword list is dense but earns its space by signaling scope.

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 read tool with no annotations and no output schema, the definition conveys what the content is (definitions and examples) but says nothing about return format, per-keyword content depth, or whether a single call returns one keyword's reference. The locale dimension's effect on output is only implied.

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 50%: the keyword param already lists its valid values in the schema, and the description's keyword list adds nothing new. The locale enum is documented only structurally, and the description's 'in 6 languages' is the sole clue that locale controls the language of the returned reference, which is genuine but thin added value.

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 ('Provides syntax definitions and examples') and resource ('KUKA KRL statements') and enumerates the covered keywords, so an agent knows exactly what it returns. It does not explicitly distinguish itself from the overlapping krl_control_flow sibling, which keeps it below a 5.

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 explicit when-to-use or when-not-to-use guidance and no named alternative. The reader must infer from 'authoritative syntax definitions' that this is the lookup to call before writing or validating KRL, while siblings like krl_lint_snippet and krl_control_flow are never mentioned as contrasts.

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?

With no annotations, the description carries the full burden. It discloses the extension dependency and the exact set of checks performed, and 'Collects ... from all open files' implies a non-mutating scan, but it never states read-only vs destructive behavior, expected latency on large workspaces, or what happens if the extension is absent.

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, no filler, and the core scope statement is front-loaded ahead of the parenthetical checklist and the prerequisite. The first sentence is long and heavily parenthesized, but every clause carries distinct information.

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 zero-parameter, no-output-schema tool, the description covers what is scanned, which checks run, and the extension prerequisite. The remaining gap is the shape of the result — whether it returns per-file diagnostic lists, severities, or an aggregate — which an agent cannot infer without an output schema.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. Schema coverage is reported at 100% with an empty properties object, leaving nothing for the description to compensate for.

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?

Specific verb ('Collects') plus a precise resource ('project-wide continuous KRL diagnostics') and an explicit file scope (.src, .dat, .sub across all open workspace files), backed by an enumerated list of check categories. The 'all open files / project-wide' framing implicitly separates it from snippet-level siblings like krl_lint_snippet, but no sibling is named, so the differentiation is inferential rather than stated.

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 no explicit when-to-use or when-not-to-use guidance, and names no alternatives, so the agent must infer that this is the workspace-wide counterpart to krl_lint_snippet. The one condition it does state — 'Requires LiskinLabs KUKA KRL extension' — is a genuine prerequisite, which lifts it above a pure no-guidance score.

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?

With no annotations, the description carries the burden: 'Lists' implies a read-only, non-destructive operation and it discloses the required LiskinLabs KUKA KRL extension, which is useful prerequisite context. It says nothing about what happens when the workspace is empty, whether results are paginated or recursive, or whether hidden/system folders are included.

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 short sentences with no filler: the first front-loads what is returned and where, the second gives the prerequisite. Every clause earns its place.

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 parameterless list tool with no output schema, the description still leaves the return shape unspecified (bare names vs. paths, ordering, whether nested directories are traversed) and gives no failure behavior when the extension is absent. What it does cover — content types and the extension dependency — is accurate but not sufficient.

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?

The tool takes zero parameters, so the description has no parameter semantics to convey and cannot be faulted; baseline 4 applies. Nothing in the description misleadingly implies options that don't exist.

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 ('Lists ... in the active workspace') and enumerates exactly what is listed (.src, .dat, .sub), which makes the scope concrete. It does not contrast with siblings such as krl_read_file or krl_workspace_diagnostics, so it stops short of full differentiation.

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?

No guidance on when to use this versus alternatives like krl_read_file or krl_workspace_diagnostics is given. The only conditional information is the prerequisite extension, which is a requirement, not usage selection.

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