abap-config-mcp

Write ABAP Object Source

write_abap_object_source

DestructiveIdempotent

Write or update ABAP object source by locking the object, saving the code, verifying the write, and releasing the lock; optionally keep it locked for later activation.

Instructions

Write/update the source code of an ABAP object: locks, writes, reads back to verify, and releases the lock (keepLock: true to keep it). Give the code as source, or — for large sources — sourcePath, an absolute path to a local file under your home directory (UTF-8, at most 5 MB) that is sent as it is; exactly one of the two. The new source is the inactive version until abap_activate. Transport: a transport you pass is checked and used; an object already locked into a request uses it; createTransport: true creates a new one; otherwise the transport already used for this piece of work (workItem, else this session) is reused; otherwise exactly one open request is used, several are listed for you to choose, none offers creation.

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": "write_abap_object_source"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	ADT object URL (e.g. /sap/bc/adt/programs/programs/Z_MY_PROG)
`source`	No	New ABAP source code to write. Give this or sourcePath, not both.
`keepLock`	No	Keep the object locked after writing (default false). A kept lock belongs to this conversation and lasts until abap_activate, unlock_abap_object or the end of the conversation.
`workItem`	No	Name of the piece of work (e.g. HPM, a ticket). Keeps using the same transport for it across calls and sessions until you pass another.
`sourceUrl`	No	ADT source URL — defaults to <url>/source/main
`transport`	No	Workbench request to record into. Checked before use; becomes the transport for this piece of work.
`sourcePath`	No	Absolute path of a local file under your home directory holding the new source (UTF-8, at most 5 MB) — read instead of source, so large sources need not pass through the conversation. Give this or source, not both.
`connectionId`	No	SAP system connection ID
`createTransport`	No	Create a NEW Workbench request (only when you mean it; existing requests are preferred).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.16.0Nov 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare this is a destructive, idempotent, open-world write, so the safety profile is covered. The description still adds real context beyond them: the lock-write-verify-release cycle, that the written version is inactive until abap_activate, the lock lifetime, the 5 MB/UTF-8 file constraint, and the transport resolution algorithm. It stops short of saying what the read-back verification returns or how failures surface, which keeps it off 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.

Conciseness4/5

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

The operation sequence is front-loaded and the mutually exclusive source/sourcePath rule appears early. The final transport sentence is a dense semicolon chain that is harder to parse than necessary, but no sentence is redundant with the schema or annotations.

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 9-parameter destructive mutation tool with no output schema, the definition covers prerequisites, exclusivity, transport resolution, and lock lifecycle thoroughly. The only gap is the absence of any indication of what a successful call returns (confirmation, verification result, or assigned transport), which an agent might need for follow-up decisions.

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

Parameters4/5

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

Schema coverage is 100%, so a baseline of 3 applies. The description earns above that by explaining the transport precedence chain (explicit transport checked and used, existing object lock, createTransport, workItem/session reuse, single open request, listing several, offering creation) — a decision procedure the schema's single-sentence parameter descriptions do not convey.

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?

The first clause gives a specific verb and resource — 'Write/update the source code of an ABAP object' — and immediately enumerates the exact operation sequence (locks, writes, reads back to verify, releases). It also distinguishes itself from abap_activate by stating the new source stays inactive until activation, so an agent can place it in the workflow without opening sibling schemas.

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?

It states explicit selection rules: exactly one of source or sourcePath (with the 'for large sources' condition that selects sourcePath), keepLock true only to retain the lock, and a full precedence chain for transport choice. It also names related tools (abap_activate, unlock_abap_object) as the lifecycle endpoints, leaving nothing to inference about when to call this versus those.

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

Deploy Server