Skip to main content
Glama

abap_enh

Manage SAP enhancement objects via ADT: write descriptions, create BAdI definitions, implementations, and hooks, set filter values, activate, and delete enhancements.

Instructions

Default op writes the root adtcore:description of an existing ENHO/XH, ENHO/XHH or ENHS/XS, optionally activating it. ENHO/XHH plug-in source body: use abap_write, not this tool. See operation for the other ops.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYeswrite_description/delete/set_impl_active: container name (never the nested badiImplementation entry - use spec.implName). create_spot/add_badi_def/add_filter_def: spotName. create_impl/set_filter_values: enhName. exercise: badiName. create_hook: new name. discover_hook_anchors: unused.
specNoFields per op (?=optional; IDs max 30 chars; lengths and value rules in doc/TOOLS/enhancements.md). create_spot: description. add_badi_def: badiName, interfaceName, singleUse, shortText. add_filter_def: badiName, filterName, filterType, filterText?. create_impl: spotName, badiName, implName, implClass, active, description. set_filter_values: spotName, implName, filterName, filterType, compare, value. exercise: methodName, filterName?, filterValue?, params?[{name, kind?, value?, type?}] (params[].type: required for changing/exporting/receiving, forbidden otherwise; a namespaced type ref is allowed). discover_hook_anchors: hostType, hostName, hostUri. create_hook: hostType(PROG/P only), hostName, hostUri, anchorFullName, anchorFullDescription, responsible?, activate?. set_impl_active: active, implName?(omit only if exactly one entry), description?.
typeNoRequired for write_description/delete; unused otherwise.
affectsNoObject affected. create_spot: optional, defaults to the spot itself. add_badi_def/add_filter_def: optional, defaults to the spot itself. create_hook: optional, derived from spec.hostName when omitted (one GET; NOT_FOUND if the host does not exist). REQUIRED (BAD_INPUT if omitted): create_impl, set_filter_values, exercise, write_description, delete, set_impl_active. discover_hook_anchors: never used.
corr_nrNowrite_description/delete/set_impl_active: transport request, unchanged. Five fluid ops: the transport for a transportable (non-$) package; with a local package this is BAD_INPUT. Omitted with a transportable package is resolved by the session resolver under ABAP_ALLOW_TRANSPORTS=auto.
packageNoTarget package for the five fluid ops only (create_spot, add_badi_def, add_filter_def, create_impl, set_filter_values). Default $TMP; trimmed and uppercased. Given on any other operation: BAD_INPUT.
activateNowrite_description: activate after a changed write (input.activate === true). Five fluid ops: default true; false saves without activating, leaving the object inactive. create_hook uses spec.activate (default false); set_impl_active always activates.
operationNoDefault "write_description". The five fluid ops (create_spot, add_badi_def, add_filter_def, create_impl, set_filter_values) take package (default $TMP), corr_nr and activate (default true). exercise creates nothing of the caller's own (its bridge class lives in $ABAPSMITH_FLUID_API). create_hook lands in $TMP. discover_hook_anchors: read-only. delete needs ABAP_ALLOW_ENHANCEMENT_DELETE=true, irreversible; set_impl_active: reversible.
descriptionNoRequired for write_description/create_hook (new adtcore:description, max 60). Unused otherwise.
expect_etagNoRefuse if etag differs (write_description/delete/set_impl_active only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.6.36
    • changedInput schema / properties / activate / description
      Previous value: -"write_description only: activate after a changed write. create_hook uses spec.activate; set_impl_active always activates."New value: +"write_description: activate after a changed write (input.activate === true). Five fluid ops: default true; false saves without activating, leaving the object inactive. create_hook uses spec.activate (default false); set_impl_active always activates."
    • changedInput schema / properties / affects / description
      Previous value: -"Object affected; required except discover_hook_anchors."New value: +"Object affected. create_spot: optional, defaults to the spot itself. add_badi_def/add_filter_def: optional, defaults to the spot itself. create_hook: optional, derived from spec.hostName when omitted (one GET; NOT_FOUND if the host does not exist). REQUIRED (BAD_INPUT if omitted): create_impl, set_filter_values, exercise, write_description, delete, set_impl_active. discover_hook_anchors: never used."
    • changedInput schema / properties / corr_nr / description
      Previous value: -"Transport request (write_description/delete/set_impl_active only)."New value: +"write_description/delete/set_impl_active: transport request, unchanged. Five fluid ops: the transport for a transportable (non-$) package; with a local package this is BAD_INPUT. Omitted with a transportable package is resolved by the session resolver under ABAP_ALLOW_TRANSPORTS=auto."
    • changedInput schema / properties / operation / description
      Previous value: -"Default \"write_description\". Six create ops: always $TMP, always activate. discover_hook_anchors: read-only. delete needs ABAP_ALLOW_ENHANCEMENT_DELETE=true, irreversible; set_impl_active: reversible."New value: +"Default \"write_description\". The five fluid ops (create_spot, add_badi_def, add_filter_def, create_impl, set_filter_values) take package (default $TMP), corr_nr and activate (default true). exercise creates nothing of the caller's own (its bridge class lives in $ABAPSMITH_FLUID_API). create_hook lands in $TMP. discover_hook_anchors: read-only. delete needs ABAP_ALLOW_ENHANCEMENT_DELETE=true, irreversible; set_impl_active: reversible."
    • addedInput schema / properties / package
      Added value: +{
      +  "description": "Target package for the five fluid ops only (create_spot, add_badi_def, add_filter_def, create_impl, set_filter_values). Default $TMP; trimmed and uppercased. Given on any other operation: BAD_INPUT.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv0.6.25
    • changedInput schema / properties / operation / description
      Previous value: -"Default \"write_description\". Six create ops: always $TMP, always activate. discover_hook_anchors: read-only. delete needs ABAP_ALLOW_ENHANCEMENT_DELETE=true, irreversible. set_impl_active: reversible."New value: +"Default \"write_description\". Six create ops: always $TMP, always activate. discover_hook_anchors: read-only. delete needs ABAP_ALLOW_ENHANCEMENT_DELETE=true, irreversible; set_impl_active: reversible."
    • changedInput schema / properties / spec / description
      Previous value: -"Fields per op (?=optional, else required; numbers=max chars). IDs max 30 chars, see enhancement skill.\ncreate_spot: description(60).\nadd_badi_def: badiName, interfaceName, singleUse(bool), shortText(60).\nadd_filter_def: badiName, filterName, filterType(1 upper letter, e.g. C), filterText?(255).\ncreate_impl: spotName, badiName, implName, implClass, active(bool), description(60).\nset_filter_values: spotName, implName, filterName, filterType(as above), compare(=,<>,<,<=,>,>=,EQ,NE,LT,LE,GT,GE), value(255).\nexercise: methodName, filterName?, filterValue?, params?[{name, kind?(importing/changing/exporting/receiving, default importing, max 1 receiving), value?(req for importing/changing, else forbidden), type?(params[].type: req for changing/exporting/receiving, else forbidden; namespaced type ref)}].\ndiscover_hook_anchors: hostType, hostName, hostUri.\ncreate_hook: hostType(PROG/P only), hostName, hostUri, anchorFullName, anchorFullDescription(200), responsible?(12), activate?(bool).\nset_impl_active: active(bool), implName?(omit only if exactly one entry), description?(60)."New value: +"Fields per op (?=optional; IDs max 30 chars; lengths and value rules in doc/TOOLS/enhancements.md).\ncreate_spot: description.\nadd_badi_def: badiName, interfaceName, singleUse, shortText.\nadd_filter_def: badiName, filterName, filterType, filterText?.\ncreate_impl: spotName, badiName, implName, implClass, active, description.\nset_filter_values: spotName, implName, filterName, filterType, compare, value.\nexercise: methodName, filterName?, filterValue?, params?[{name, kind?, value?, type?}] (params[].type: required for changing/exporting/receiving, forbidden otherwise; a namespaced type ref is allowed).\ndiscover_hook_anchors: hostType, hostName, hostUri.\ncreate_hook: hostType(PROG/P only), hostName, hostUri, anchorFullName, anchorFullDescription, responsible?, activate?.\nset_impl_active: active, implName?(omit only if exactly one entry), description?."
  3. First observedv0.3.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that the default op 'writes' and can 'optionally activat[e]', which is consistent with the annotations. It also hints at a limitation (not for XHH plug-in source). However, it does not disclose side effects like transport handling, irreversibility of delete, or the fact that some ops are read-only (e.g., discover_hook_anchors) – those are left to the schema.

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?

The description is extremely concise – two sentences that front-load the default operation and include a critical routing hint (use abap_write for XHH source). Every word earns its place, and the pointer to the operation parameter is an efficient way to handle the multi-operation nature without bloating the description.

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?

Given the tool's complexity (11 operations, 10 parameters, nested objects), the description is minimal but sufficient because the schema is exceptionally detailed. It covers the default operation and gives a key exclusion, while directing the agent to the schema for the remaining ops. For an agent that reads the full schema, this is adequate; it would be improved by a one-line summary of the operation families.

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 description coverage is 100%, so all parameters are documented in the schema. The description adds no parameter-specific details; it only says 'See operation for the other ops,' which implicitly refers to the schema. Since the schema is exhaustive, the description's lack of parameter elaboration is acceptable but not additive.

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?

The description clearly states the default operation (write_description) and its effect on ENHO/XH, ENHO/XHH, ENHS/XS. It distinguishes from abap_write for a specific case (ENHO/XHH plug-in source body), which helps differentiate the tool. However, it does not summarize the full scope of 11 operations, relying on 'See operation for the other ops' which is an indirect pointer rather than a direct statement of capabilities.

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 provides one explicit usage exclusion: 'ENHO/XHH plug-in source body: use abap_write, not this tool.' This is clear guidance for a specific scenario. However, it offers no guidance on when to use this tool versus other siblings like abap_read or abap_enh variants, and does not explain when to use each of the other operations beyond pointing to the schema.

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