mcp-abap-adt

ValidateServiceBinding

Validates a new ABAP service binding against its service definition and package through the ADT validation endpoint, returning terse, full, or raw validation details.

Instructions

[read-only] Validates a new service binding named by service_binding_name for the service definition named by service_definition_name, in the package and version given, through the ADT validation endpoint. 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": {
      "service_binding_name": "<service_binding_name>",
      "service_definition_name": "<service_definition_name>"
    },
    "name": "ValidateServiceBinding"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	How much of the answer to return: "terse" (default, the fields you need to act), "full" (the whole parse), "raw" (the document as ADT sent it).	terse
`description`	No	Optional description used during validation.
`package_name`	No	ABAP package for the binding.
`service_binding_name`	Yes	Service binding name to validate.
`service_binding_version`	No	Service binding version (for example: 1.0). Accepted for backward compatibility; the transport check this now runs does not read it.
`service_definition_name`	Yes	Service definition linked to binding. Accepted for backward compatibility; the transport check this now runs does not read it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv16.0.0Oct 4, 2026

addedInput schema / properties / detail

Added value: +{
+  "default": "terse",
+  "description": "How much of the answer to return: \"terse\" (default, the fields you need to act), \"full\" (the whole parse), \"raw\" (the document as ADT sent it).",
+  "enum": [
+    "terse",
+    "full",
+    "raw"
+  ],
+  "type": "string"
+}

changedInput schema / properties / service_binding_version / description

Previous value: -"Service binding version (for example: 1.0)."New value: +"Service binding version (for example: 1.0). Accepted for backward compatibility; the transport check this now runs does not read it."

changedInput schema / properties / service_definition_name / description

Previous value: -"Service definition linked to binding."New value: +"Service definition linked to binding. Accepted for backward compatibility; the transport check this now runs does not read it."

AddedMar 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it declares '[read-only]' and explains the batch recording contract (recorded under the next number, empty content returned, answer read later by number). It does not say what a failed validation looks like or whether anything persists, which is the remaining gap.

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

Conciseness5/5

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

Two sentences, front-loaded with the read-only marker and the purpose before the batch caveat. Every clause carries information; nothing is padding.

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

Completeness3/5

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

For a 6-parameter, no-output-schema tool, the description covers purpose and batch mechanics but never describes the validation verdict (pass/fail, message list) an agent must act on. The backward-compatibility note for service_definition_name conflicts with the description's claim that it names the definition being validated.

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 coverage is 100%, so the baseline is 3; the description names the key parameters but adds nothing about the 'detail' enum or the version semantics. It also says validation runs 'for the service definition named by service_definition_name', which the schema says is accepted only for backward compatibility and not read by the current check.

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?

States a specific verb ('Validates') plus the exact resource ('a new service binding') and names the ADT validation endpoint, so an agent can tell it apart from GetServiceBinding/CreateServiceBinding and the Check* family. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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?

The word 'new' implies the pre-creation validation use case, and the batch-mode sentence implies how it is used inside BatchBegin/BatchEnd. Neither is stated as a rule, and there is no when-not clause telling the agent to prefer CheckServiceDefinition or GetServiceBinding instead.

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

Deploy Server