Skip to main content
Glama

GetPackageContents

Retrieve objects from one or more ABAP packages as a flat list, optionally recursing into subpackages and including object descriptions.

Instructions

[read-only] Retrieve objects inside an ABAP package as a flat list. Supports recursive traversal of subpackages. Takes package_name (one package: its list) or package_names (several packages: one entry per package, in the order given, each { package_name, objects } or { package_name, error }). Each level of the walk is read in one ADT batch envelope: the root node structures of its packages, then their type nodes; with include_descriptions, as single requests, several at a time. Runs on an ABAP session of its own. Optional timeout (seconds): when it passes, the read is cancelled, its ABAP session logged off, and the system stays as it was. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a client's cancel ends only the client's wait, and SAP runs the read on. Runs outside batch mode.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "GetPackageContents"
  }
}

Input Schema

NameRequiredDescriptionDefault
timeoutNoSeconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.
max_depthNoMaximum depth for recursive package traversal (default: 5)
package_nameNoName of the ABAP package (give this or package_names)
package_namesNoNames of several ABAP packages, read together (give this or package_name)
include_subpackagesNoInclude contents of subpackages recursively (default: false)
include_descriptionsNoInclude each object's description in the response. The walk's levels are then read as single requests, several at a time, rather than in ADT batch envelopes (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv20.1.0
    • changedInput schema / properties / include_descriptions / description
      Previous value: -"Include object descriptions in response (default: true)"New value: +"Include each object's description in the response. The walk's levels are then read as single requests, several at a time, rather than in ADT batch envelopes (default: false)"
    • changedInput schema / properties / package_name / description
      Previous value: -"Name of the ABAP package"New value: +"Name of the ABAP package (give this or package_names)"
    • addedInput schema / properties / package_names
      Added value: +{
      +  "description": "Names of several ABAP packages, read together (give this or package_name)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / timeout
      Added value: +{
      +  "description": "Seconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.",
      +  "maximum": 2147483,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "package_name"
      -]
  2. Changed1 schema field changedv16.0.0
    • changedInput schema / properties / package_name / description
      Previous value: -"Name of the ABAP package (e.g., \"ZMY_PACKAGE\")"New value: +"Name of the ABAP package"
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full disclosure burden and does so thoroughly: it describes recursive traversal, ADT batch envelopes, dedicated ABAP sessions, timeout cancellation/logoff behavior, the fact that a client-side cancel does not stop SAP, and that it runs outside batch mode.

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 description is front-loaded with purpose, then moves through recursion, parameter modes, batching, and timeout behavior in a logical order. It is dense but mostly earns its length; some timeout details replicate the schema and could be tightened.

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 complex six-parameter tool with no annotations and no output schema, the description covers the essential operational behavior, timeout semantics, and multi-package response shape. The single-package return structure is only described as 'its list,' leaving a minor gap, but overall an agent has enough to call it correctly.

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 the schema already documents each parameter. The description adds return-shape semantics beyond the schema: package_names yields one entry per package in input order, each being { package_name, objects } or { package_name, error }, and it explains how include_descriptions changes the request pattern.

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 sentence states a specific verb and resource: 'Retrieve objects inside an ABAP package as a flat list.' The phrase 'flat list' also implicitly distinguishes it from the tree-oriented GetPackageTree sibling, so an agent can identify its role without opening the schema.

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 explains the two input modes (package_name vs package_names) and optional recursion, which implies usage. However, it never explicitly says when to choose this tool over alternatives such as GetPackageTree or GetPackage, and there are no exclusion rules.

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