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

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GetTypeInfo

Retrieve ABAP DDIC type details for a given name, including data elements, domains, structures, and table types; returns every matching type definition.

Instructions

[read-only] Retrieve ABAP type information for a DDIC type name: data elements (DTEL), domains (DOMA), structures and table types. One name can be more than one type (MANDT is a data element and a domain): the answer lists every type the name is, in alphabetical order of type, each with its definition — data type, length and decimals, field labels, a domain's output format, value table and fixed values, a table type's row type and key. 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": {
      "type_name": "<type_name>"
    },
    "name": "GetTypeInfo"
  }
}

Input Schema

NameRequiredDescriptionDefault
type_nameYesName of the ABAP type
include_structure_fallbackNoWhen true (default), the name is also read as a DDIC structure; false leaves the structure read out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv21.0.0
    • changedInput schema / properties / include_structure_fallback / description
      Previous value: -"When true (default), tries DDIC structure lookup only if type lookup returns 404/empty."New value: +"When true (default), the name is also read as a DDIC structure; false leaves the structure read out."
  2. Changed1 schema field changed
    • addedInput schema / properties / include_structure_fallback
      Added value: +{
+  "default": true,
+  "description": "When true (default), tries DDIC structure lookup only if type lookup returns 404/empty.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it declares read-only status, discloses that one name can resolve to multiple types, specifies alphabetical-by-type ordering, and describes what each entry contains. It also flags the important constraint "Runs outside batch mode," though it says nothing about failure behavior when a name is unknown or about authorization requirements.

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?

One dense paragraph, front-loaded with the read-only tag and the core verb, with the em-dash enumeration of returned fields doing real informational work rather than padding. Nothing is redundant.

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?

With no output schema, the description must sketch the return shape, and it does: per-type definitions including data type, length/decimals, field labels, domain output format, value table, fixed values, row type and key. Only error/not-found behavior and permission expectations are unaddressed for a tool of this complexity.

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 both parameters are already documented and baseline is 3. The description adds real meaning for type_name by explaining that a single name may map to several type kinds, but it never mentions include_structure_fallback, which is the non-obvious parameter that changes what comes back.

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?

Specific verb plus resource: "Retrieve ABAP type information for a DDIC type name," with the covered object kinds spelled out (data elements, domains, structures, table types). The MANDT example clarifies the multi-type resolution behavior, which meaningfully distinguishes it from the single-kind siblings like GetDataElement, GetDomain, GetStructure and GetTable.

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

Usage Guidelines4/5

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

By enumerating all four DDIC type kinds it implicitly signals this is the kind-agnostic lookup to use when the caller does not already know whether a name is a data element, domain, structure or table type. However, it never explicitly names the sibling tools (GetDataElement, GetDomain, GetStructure) or states when to prefer those narrower reads.

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