Skip to main content
Glama

UpdateDataElement

Updates an existing ABAP data element by locking, replacing its definition with supplied parameters, unlocking, and optionally activating it.

Instructions

Update an existing ABAP data element. Locks, updates with provided parameters (complete replacement), unlocks, and optionally activates. 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": {
      "data_element_name": "<data_element_name>",
      "package_name": "<package_name>"
    },
    "name": "UpdateDataElement"
  }
}

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
lengthNoLength - for predefinedAbapType or refToPredefinedAbapType
activateNoActivate data element after update (default: true)
decimalsNoDecimals - for predefinedAbapType or refToPredefinedAbapType
data_typeNoData type (CHAR, NUMC, etc.) - for predefinedAbapType or refToPredefinedAbapType
type_kindNoType kind: domain, predefinedAbapType, refToPredefinedAbapType, refToDictionaryType, refToClifTypedomain
type_nameNoType name: domain name, data element name, or class name (depending on type_kind)
descriptionNoNew data element description
search_helpNoSearch help name
package_nameYesPackage name
field_label_longNoLong field label (max 40 chars)
data_element_nameYesData element name to update
field_label_shortNoShort field label (max 10 chars)
set_get_parameterNoSet/Get parameter ID
transport_requestNoTransport request number, not a task. Required for transportable packages.
field_label_mediumNoMedium field label (max 20 chars)
field_label_headingNoHeading field label (max 55 chars)
search_help_parameterNoSearch help parameter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv16.0.0
    • changedInput schema / properties / data_element_name / description
      Previous value: -"Data element name to update (e.g., ZZ_TEST_DTEL_01)"New value: +"Data element name to update"
    • 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 / package_name / description
      Previous value: -"Package name (e.g., ZOK_LOCAL, $TMP for local objects)"New value: +"Package name"
    • changedInput schema / properties / transport_request / description
      Previous value: -"Transport request number (e.g., E19K905635). Required for transportable packages."New value: +"Transport request number, not a task. Required for transportable packages."
  2. First observed

TDQS

A4.1/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 well: it discloses the internal lock/unlock lifecycle, that activation is optional, that it runs outside batch mode, and critically that the update is a complete replacement. It does not cover failure behavior (e.g. what happens if the lock fails) or permission requirements, keeping it short of 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?

Two sentences, tightly packed, with the identity of the operation front-loaded before the behavioral detail. Every clause conveys something actionable; nothing is redundant.

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 an 18-parameter mutation tool with no annotations and no output schema, the description covers the mutation lifecycle well but says nothing about the response (the 'detail' parameter implies a returned data element representation) or error/lock-conflict behavior. Adequate but with clear remaining gaps.

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 description coverage is 100%, so baseline is 3, but the phrase 'updates with provided parameters (complete replacement)' adds semantics the schema cannot express: any omitted field is effectively cleared. That is a material warning for an 18-parameter mutation tool and earns a step above baseline.

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?

States a specific verb ('Update') and resource ('ABAP data element') and constrains it to an 'existing' object, which separates it from CreateDataElement at a glance. The sequence of operations (lock/update/unlock/activate) further pins down what the call actually does.

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 description implies when to use it via 'existing' and hints at a usage constraint with 'complete replacement', but it never names an alternative (e.g. ActivateDataElement for activation-only, or CreateDataElement for new objects) or states prerequisites beyond what the schema carries. Usage is inferable rather than explicit.

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