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

abap-config-mcp

by netweaver1970
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Unlock ABAP Object

unlock_abap_object
DestructiveIdempotent

Release the edit lock this server holds on an ABAP object without deleting saved inactive source. Use it to free objects you will not activate.

Instructions

Release the edit lock this server holds on an ABAP object, taken by lock_abap_object or kept by write_abap_object_source with keepLock. Saved (inactive) source is not removed. Use it to free an object you will not activate; abap_activate releases a held lock itself. If this server holds no lock and no handle is given, nothing is released and the call explains why; force_relogin drops the whole session's locks as a last resort.

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": {
      "url": "<url>"
    },
    "name": "unlock_abap_object"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesADT object URL that was locked (e.g. /sap/bc/adt/programs/programs/ZREPORT)
lockHandleNoLock handle returned by lock_abap_object or write_abap_object_source. Optional: defaults to the lock this server holds on the object.
connectionIdNoSAP system connection ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.2
    • changedInput schema / properties / url / description
      Previous value: -"ADT object URL"New value: +"ADT object URL that was locked (e.g. /sap/bc/adt/programs/programs/ZREPORT)"
  2. First observedv1.16.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=true, idempotent=true, openWorld=true, so the safety profile is covered. The description adds real value on top: it clarifies the blast radius ('Saved (inactive) source is not removed') and defines the no-op path ('If this server holds no lock and no handle is given, nothing is released and the call explains why'), which is exactly the destructive-scope detail annotations cannot express. It stops short of describing the response payload, keeping it below a 5.

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?

Four sentences, each carrying distinct information — action, non-destructive caveat, selection guidance, and edge-case/escalation behavior. The verb and object are front-loaded with no preamble or restating of the title.

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?

For a destructive, lock-releasing mutation with no output schema, the definition covers what is freed, what is preserved, what happens on a no-op, and the escalation route. The only omission is what a successful call returns or confirms, which matters slightly given there is no output schema, but the essentials for correct invocation are present.

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 url, lockHandle, and connectionId are already documented, including the lockHandle default. The description reinforces the fallback semantics by describing the outcome when no handle is supplied and no lock is held, but it adds no new syntax, format, or validation detail beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

Opens with a specific verb+resource ('Release the edit lock this server holds on an ABAP object') and immediately ties the resource to its origin ('taken by lock_abap_object or kept by write_abap_object_source with keepLock'). An agent can distinguish this from lock_abap_object, write_abap_object_source, and abap_activate without opening any schema.

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

Usage Guidelines5/5

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

Explicitly states the selecting condition ('Use it to free an object you will not activate') and names the alternative that needs no unlock ('abap_activate releases a held lock itself'). It also nests an escalation path ('force_relogin drops the whole session's locks as a last resort'), so when-to-use, when-not-to-use, and fallback are all present.

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