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

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

UpdateServiceBinding

Change the publication state of an existing ABAP service binding to published, unpublished, or unchanged, with routing based on OData V2/V4 variant. Runs outside batch mode.

Instructions

Update publication state of an existing ABAP service binding. Runs outside batch mode.

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>",
      "desired_publication_state": "<desired_publication_state>",
      "service_name": "<service_name>"
    },
    "name": "UpdateServiceBinding"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNoHow 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
service_nameYesPublished service name, from the binding. Required: an OData V2 publication job resolves the service by name and version and refuses without them. Ignored for V4, where the request names its target on its own.
binding_variantNoService binding variant. Determines OData version for publish/unpublish routing.ODATA_V4_UI
response_formatNoAccepted for backward compatibility; no longer affects the answer, which is always the structured write result.xml
service_versionNoPublished service version. Default 0001. Used by an OData V2 publication job together with the service name; ignored for V4.
service_binding_nameYesService binding name to update.
desired_publication_stateYesTarget publication state.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv16.0.0
    • 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"
+}
    • addedInput schema / properties / response_format / description
      Added value: +"Accepted for backward compatibility; no longer affects the answer, which is always the structured write result."
    • changedInput schema / properties / service_name / description
      Previous value: -"Published service name."New value: +"Published service name, from the binding. Required: an OData V2 publication job resolves the service by name and version and refuses without them. Ignored for V4, where the request names its target on its own."
    • changedInput schema / properties / service_version / description
      Previous value: -"Published service version. Optional."New value: +"Published service version. Default 0001. Used by an OData V2 publication job together with the service name; ignored for V4."
  2. Changed2 schema fields changedv6.5.1
    • addedInput schema / properties / binding_variant
      Added value: +{
+  "default": "ODATA_V4_UI",
+  "description": "Service binding variant. Determines OData version for publish/unpublish routing.",
+  "enum": [
+    "ODATA_V2_UI",
+    "ODATA_V2_WEB_API",
+    "ODATA_V4_UI",
+    "ODATA_V4_WEB_API"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / service_type
      Removed value: -{
-  "default": "ODataV4",
-  "description": "OData service type for publish/unpublish action routing.",
-  "enum": [
-    "ODataV2",
-    "ODataV4"
-  ],
-  "type": "string"
-}
  3. Added

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses the operation is a state mutation and that it cannot run in batch mode, but omits permissions required, side effects of publishing (service exposure), reversibility of published vs unpublished, and whether activation is implied. A significant portion of the mutation's risk profile is left undisclosed.

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 short sentences, zero filler, purpose front-loaded in the first sentence and the operational constraint immediately following. Nothing in it is wasted.

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?

The rich schema covers parameters, but with no annotations and no output schema the description should say more about what happens on success/failure, error modes (e.g., invalid state transition), and whether the binding must be inactive. For a mutating tool with seven parameters, that gap is real even if the schema is well documented.

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

Parameters2/5

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

Schema description coverage is 100%, so the schema itself explains service_name, service_version, binding_variant, desired_publication_state, and even the deprecated response_format. The description adds no parameter-level guidance beyond what the schema already states, so it earns only the baseline at best; scoring 2 because the two-sentence description contributes nothing to disambiguating the seven parameters.

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?

Names a specific verb and resource: updating the publication state of an existing ABAP service binding. It clearly implies a mutation on an already-existing object rather than creation, but it never mentions near-neighbours like ActivateServiceBinding, ValidateServiceBinding, or GetServiceBinding, so sibling differentiation is left to inference.

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?

'Runs outside batch mode' is a concrete usage constraint that tells the agent not to wrap this in BatchBegin/BatchEnd, which is genuinely useful. However, it says nothing about when to prefer this over ActivateServiceBinding or CreateServiceBinding, nor about prerequisites such as the binding needing to exist or be inactive.

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