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

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

CheckDdl

Run a syntax check on a CDS view or hypothetical DDL source and return syntax errors, warnings, and messages for active or inactive versions.

Instructions

[read-only] Runs a syntax check on the CDS view named by ddl_name. Can check existing view (active/inactive) or validate hypothetical DDL source. 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": {
      "ddl_name": "<ddl_name>"
    },
    "name": "CheckDdl"
  }
}

Input Schema

NameRequiredDescriptionDefault
versionNoVersion to check: 'active' or 'inactive'. Without `version` the active version is checked.
ddl_nameYesCDS view name to check, passed as ddl_name.
ddl_sourceNoOptional: DDL source code to validate instead of the saved version.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv20.1.0
    • changedInput schema / properties / version / description
      Previous value: -"Version to check: 'active' or 'inactive'. Default: inactive."New value: +"Version to check: 'active' or 'inactive'. Without `version` the active version is checked."
  2. Changed1 schema field changedv16.0.0
    • changedInput schema / properties / ddl_name / description
      Previous value: -"CDS view name to check, passed as ddl_name (e.g., ZI_MY_VIEW)."New value: +"CDS view name to check, passed as ddl_name."
  3. Addedv8.0.0

TDQS

A3.7/5.0
Behavior4/5

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 well: it explicitly declares read-only behavior, states the return content (syntax errors, warnings, messages), and discloses the unusual batch-mode recording semantics including empty responses and answer retrieval by number. It does not cover auth/permission requirements or error handling for invalid ddl_name, but the core behavioral profile is clear.

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?

The purpose and read-only marker are front-loaded, and the description stays compact despite covering two modes plus batch semantics. The batch sentence is long but earns its place by explaining non-obvious behavior.

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?

There is no output schema, but the description states the return content (syntax errors, warnings, messages), and no annotations exist, yet the description supplies the read-only and batch-mode context. An agent has enough to call the tool correctly, with only minor gaps around invalid-input behavior.

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 in the input schema. The description reinforces the mode distinction (existing view vs. hypothetical source) but adds little syntax or interaction detail beyond what the schema already provides; baseline 3 applies when the schema does the heavy lifting.

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 CDS view named by ddl_name,' and explains the two modes (existing active/inactive view vs. hypothetical DDL source). This clearly separates it from retrieval tools like GetDdl and from other Check* tools aimed at different object types, though it never names an explicit alternative.

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

Usage Guidelines3/5

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

It states what can be checked (existing view or hypothetical source), which implies when the tool is appropriate, but gives no explicit when-not conditions or routing to alternatives such as GetDdl for plain retrieval or ActivateDdl for activation. The batch-mode note is contextual rather than a usage guideline.

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