Skip to main content
Glama
Sign In
mcp-abap-adt

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

CheckClass

Runs syntax checks on an ABAP class to validate active or inactive code and hypothetical source, returning syntax errors, warnings, and messages.

Instructions

[read-only] Runs a syntax check on the ABAP class named by class_name. Can check existing class (active/inactive) or validate hypothetical source code. Returns syntax errors, warnings, and messages. Recordable: in batch mode a call is recorded under the next number and answers with empty content; its answer is read by number after the batch ends.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "class_name": "<class_name>"
    },
    "name": "CheckClass"
  }
}

Input Schema

NameRequiredDescriptionDefault
versionNoVersion to check: 'active' (last activated) or 'inactive' (current unsaved). Default: active.
class_nameYesClass name.
source_codeNoOptional: source code to validate. If provided, validates hypothetical code without creating object. Must include complete CLASS DEFINITION and IMPLEMENTATION sections.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv16.0.0
    • changedInput schema / properties / class_name / description
      Previous value: -"Class name (e.g., ZCL_MY_CLASS)."New value: +"Class name."
  2. Addedv6.5.1

TDQS

A3.9/5.0
Behavior4/5

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

No structured annotations exist, so the description carries the burden, and it does substantial work: it self-labels read-only and discloses the non-obvious batch-mode behavior where the call records an answer and returns empty content to be retrieved by number later. It does not cover authorization, cost, or limits, but the batch quirk is exactly the kind of hidden behavior an agent needs.

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

Conciseness4/5

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

Four tight sentences with the read-only tag and core action front-loaded, followed by modes, return content, and the batch caveat in priority order. Nothing is redundant, though the batch sentence is dense and could be split for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly states what comes back (syntax errors, warnings, messages), and it covers the tricky batch-mode return path. For a three-parameter read-only check tool this is essentially complete; only cross-tool routing guidance is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented, including the active/inactive enum and the requirement that source_code contain full DEFINITION and IMPLEMENTATION sections. The description only restates that existing-code and hypothetical-code modes exist, adding little beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Runs a syntax check on the ABAP class named by class_name.' The resource naming implicitly separates it from the many sibling Check* tools (CheckProgram, CheckInterface, CheckTable), though none are called out explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains the two usage modes: checking an existing class (active or inactive) versus validating hypothetical source code passed in. It stops short of naming alternatives or stating when to prefer CheckClass-family tools over, say, activating the class, so it is clear context rather than explicit routing.

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

Deploy Server

Other Tools