Which integrations are available for this server?

Provides tools for interacting with SAP ABAP Development Tools (ADT), enabling access to source code, table structures, and other ABAP system resources.

How do I use mcp-abap-adt?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-abap-adt show me the structure of table MARA" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-abap-adt

by SproitNET

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mcp-abap-adt: Your Gateway to ABAP Development Tools (ADT)

This project provides a server that allows you to interact with SAP ABAP systems using the Model Context Protocol (MCP). Think of it as a bridge that lets tools like Cline (a VS Code extension) talk to your ABAP system and retrieve information like source code, table structures, and more. It's like having a remote control for your ABAP development environment!

This guide is designed for beginners, so we'll walk through everything step-by-step. We'll cover:

Prerequisites: What you need before you start.
Installation and Setup: Getting everything up and running.
Running the Server: Starting the server in different modes.
Integrating with Cline: Connecting this server to the Cline VS Code extension.
Troubleshooting: Common problems and solutions.
Available Tools: A list of the commands you can use.

1. Prerequisites

Before you begin, you'll need a few things:

An SAP ABAP System: This server connects to an existing ABAP system. You'll need:
- The system's URL (e.g., https://my-sap-system.com:8000)
- A valid username and password for that system.
- The SAP client number (e.g., 100).
- Ensure that your SAP system allows connections via ADT (ABAP Development Tools). This usually involves making sure the necessary services are activated in transaction SICF. Your basis administrator can help with this. Specifically, you will need the following services to be active:
  - /sap/bc/adt
- For the GetTableContents Tool, you will need the implementation of a custom service /z_mcp_abap_adt/z_tablecontent. You can follow this guide here
Git (or GitHub Desktop): We'll use Git to download the project code. You have two options:
- Git: The command-line tool. Download Git. Choose the version for your operating system (Windows, macOS, Linux). Follow the installation instructions.
- GitHub Desktop: A graphical user interface for Git. Easier for beginners! Download GitHub Desktop. Follow the installation instructions.
Node.js and npm: Node.js is a JavaScript runtime that lets you run JavaScript code outside of a web browser. npm (Node Package Manager) is included with Node.js and is used to install packages (libraries of code).
- Download Node.js. Choose the LTS (Long Term Support) version. This is the most stable version. Follow the installation instructions for your operating system. Make sure to include npm in the installation (it's usually included by default).
- Verify Installation: After installing Node.js, open a new terminal (command prompt on Windows, Terminal on macOS/Linux) and type:
  node -v npm -v
  You should see version numbers for both Node.js and npm. If you see an error, Node.js might not be installed correctly, or it might not be in your system's PATH. (See Troubleshooting below).

Related MCP server: ABAP-ADT-API MCP-Server

2. Installation and Setup

Now, let's get the project code and set it up:

Installing via Smithery

To install MCP ABAP Development Tools Server for Cline automatically via Smithery:

npx -y @smithery/cli install @mario-andreschak/mcp-abap-adt --client cline

Manual Installation

Clone the Repository:
- Using Git (command line):
  1. Open a terminal (command prompt or Terminal).
  2. Navigate to the directory where you want to store the project. For example, to put it on your Desktop:
    cd Desktop
  3. Clone the repository:
    git clone https://github.com/mario-andreschak/mcp-abap-adt
  4. Change into the project directory:
    cd mcp-abap-adt # Or whatever the folder name is
- Using GitHub Desktop:
  1. Open GitHub Desktop.
  2. Click "File" -> "Clone Repository...".
  3. In the "URL" tab, paste the repository URL.
  4. Choose a local path (where you want to save the project on your computer).
  5. Click "Clone".
Install Dependencies: This downloads all the necessary libraries the project needs. In the terminal, inside the root directory, run:
```
npm install
```
This might take a few minutes.
Build the Project: This compiles the code into an executable format.
```
npm run build
```
Create a .env file: This file stores sensitive information like your SAP credentials. It's very important to keep this file secure.
1. In the root directory, create a new file named .env (no extension).
2. Open the .env file in a text editor (like Notepad, VS Code, etc.).
3. Add the following lines, replacing the placeholders with your actual SAP system information: Important: If your password contains a "#" character, make sure to enclose your password in quotes!
  SAP_URL=https://your-sap-system.com:8000 # Your SAP system URL SAP_USERNAME=your_username # Your SAP username SAP_PASSWORD=your_password # Your SAP password SAP_CLIENT=100 # Your SAP client
  Important: Never share your .env file with anyone, and never commit it to a Git repository!

3. Running the Server

To be fair, you usually dont usually "run" this server on it's own. It is supposed to be integrated into an MCP Client like Cline or Claude Desktop. But you can manually run the server in two main ways:

Standalone Mode: This runs the server directly, and it will output messages to the terminal. The server will start and wait for client connections, so potentially rendering it useless except to see if it starts.
Development/Debug Mode: This runs the server with the MCP Inspector. You can open the URL that it outputs in your browser and start playing around.

3.1 Standalone Mode

To run the server in standalone mode, use the following command in the terminal (from the root directory):

npm run start

You should see messages in the terminal indicating that the server is running. It will listen for connections from MCP clients. The server will keep running until you stop it (usually with Ctrl+C).

3.2 Development/Debug Mode (with Inspector)

This mode is useful for debugging.

Start the server in debug mode:
```
npm run dev
```
This will start the server and output a message like: 🔍 MCP Inspector is up and running at http://localhost:5173 🚀. This is the URL you'll use to open the MCP inspector in your Browser.

4. Integrating with Cline

Cline is a VS Code extension that uses MCP servers to provide language support. Here's how to connect this ABAP server to Cline:

Install Cline: If you haven't already, install the "Cline" extension in VS Code.
Open Cline Settings:
- Open the VS Code settings (File -> Preferences -> Settings, or Ctrl+,).
- Search for "Cline MCP Settings".
- Click "Edit in settings.json". This will open the cline_mcp_settings.json file. The full path is usually something like: C:\Users\username\AppData\Roaming\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json (replace username with your Windows username).

Add the Server Configuration: You'll need to add an entry to the servers array in the cline_mcp_settings.json file. Here's an example:

{
  "mcpServers": 
    {
      "mcp-abap-adt": {
        "command": "node",
        "args": [
          "C:/PATH_TO/mcp-abap-adt/dist/index.js"
        ],
        "disabled": true,
        "autoApprove": []
      }
    // ... other server configurations ...
    }
}

Test the Connection:
- Cline should automatically connect to the server. You will see the Server appear in the "MCP Servers" Panel (in the Cline extension, you'll find different buttons on the top.)
- Ask Cline to get the Sourcecode of a program and it should mention the MCP Server and should try to use the corresponding tools

5. Troubleshooting

node -v or npm -v gives an error:
- Make sure Node.js is installed correctly. Try reinstalling it.
- Ensure that the Node.js installation directory is in your system's PATH environment variable. On Windows, you can edit environment variables through the System Properties (search for "environment variables" in the Start Menu).
npm install fails:
- Make sure you have an internet connection.
- Try deleting the node_modules folder and running npm install again.
- If you're behind a proxy, you might need to configure npm to use the proxy. Search online for "npm proxy settings".
Cline doesn't connect to the server:
- Double-check the settings in cline_mcp_settings.json. It must be the correct, absolute path to the root-server directory, and use double backslashes on Windows.
- Make sure the server is running (use npm run start to check).
- Restart VS Code.
- Alternatively:
- Navigate to the root folder of mcp-abap-adt in your Explorer, Shift+Right-Click and select "Open Powershell here". (Or open a Powershell and navigate to the folder using cd C:/PATH_TO/mcp-abap-adt/
- Run "npm install"
- Run "npm run build"
- Run "npx @modelcontextprotocol/inspector node dist/index.js"
- Open your browser at the URL it outputs. Click "connect" on the left side.
- Click "Tools" on the top, then click "List Tools"
- Click GetProgram and enter "SAPMV45A" or any other Report name as Program Name on the right
- Test and see what the output is
SAP connection errors:
- Verify your SAP credentials in the .env file.
- Ensure that the SAP system is running and accessible from your network.
- Make sure that your SAP user has the necessary authorizations to access the ADT services.
- Check that the required ADT services are activated in transaction SICF.
- If you're using self-signed certificates or there is an issue with your SAP systems http config, make sure to set TLS_REJECT_UNAUTHORIZED as described above!

6. Available Tools

This server provides the following tools, which can be used through Cline (or any other MCP client):

Tool Name	Description	Input Parameters	Example Usage (in Cline)
`GetProgram`	Retrieve ABAP program source code.	`program_name` (string): Name of the ABAP program.	`@tool GetProgram program_name=ZMY_PROGRAM`
`GetClass`	Retrieve ABAP class source code.	`class_name` (string): Name of the ABAP class.	`@tool GetClass class_name=ZCL_MY_CLASS`
`GetFunctionGroup`	Retrieve ABAP Function Group source code.	`function_group` (string): Name of the function group	`@tool GetFunctionGroup function_group=ZMY_FUNCTION_GROUP`
`GetFunction`	Retrieve ABAP Function Module source code.	`function_name` (string), `function_group` (string)	`@tool GetFunction function_name=ZMY_FUNCTION function_group=ZFG`
`GetStructure`	Retrieve ABAP Structure.	`structure_name` (string): Name of the DDIC Structure.	`@tool GetStructure structure_name=ZMY_STRUCT`
`GetTable`	Retrieve ABAP table structure.	`table_name` (string): Name of the ABAP DB table.	`@tool GetTable table_name=ZMY_TABLE`
`GetTableContents`	Retrieve contents of an ABAP table.	`table_name` (string), `max_rows` (number, optional, default 100)	`@tool GetTableContents table_name=ZMY_TABLE max_rows=50`
`GetPackage`	Retrieve ABAP package details.	`package_name` (string): Name of the ABAP package.	`@tool GetPackage package_name=ZMY_PACKAGE`
`GetTypeInfo`	Retrieve ABAP type information.	`type_name` (string): Name of the ABAP type.	`@tool GetTypeInfo type_name=ZMY_TYPE`
`GetInclude`	Retrieve ABAP include source code	`include_name` (string): name of the ABAP include`	`@tool GetInclude include_name=ZMY_INCLUDE`
`SearchObject`	Search for ABAP objects using quick search.	`query` (string), `maxResults` (number, optional, default 100)	`@tool SearchObject query=ZMY* maxResults=20`
`GetInterface`	Retrieve ABAP interface source code.	`interface_name` (string): Name of the ABAP interface.	`@tool GetInterface interface_name=ZIF_MY_INTERFACE`
`GetTransaction`	Retrieve ABAP transaction details.	`transaction_name` (string): Name of the ABAP transaction.	`@tool GetTransaction transaction_name=ZMY_TRANSACTION`

Available Tools

13 tools

GetClassB

Retrieve ABAP class source code

ParametersJSON Schema

Name	Required	Description	Default
`class_name`	Yes	Name of the ABAP class

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are given, and the description does not disclose any behavioral traits such as required permissions, output format, pagination, or error handling. The minimal description fails to compensate for the lack of annotations.

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, comprising a single sentence with no unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description is insufficient for a tool that retrieves source code. It omits details about return format, access restrictions, and potential limitations. While simple, it lacks complete context for the agent.

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% (only parameter 'class_name' has a description). The description adds no additional meaning beyond the schema. Baseline score of 3 applies as the schema already documents the parameter.

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 description 'Retrieve ABAP class source code' clearly states the action (retrieve) and resource (ABAP class source code). It effectively distinguishes from sibling tools like GetFunction, GetInclude, etc., which retrieve different object types.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools are listed but no explicit conditions, prerequisites, or exclusions are mentioned.

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

GetFunctionB

Retrieve ABAP Function Module source code

ParametersJSON Schema

Name	Required	Description	Default
`function_name`	Yes	Name of the function module
`function_group`	Yes	Name of the function group

TDQS

B3.2/5.0

Behavior2/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. It only states the action without disclosing side effects, permissions, error handling, or output format.

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?

Single sentence, front-loaded with key information, no wasted words. Could be expanded slightly but maintains conciseness.

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 a simple retrieval tool with two parameters and no output schema, the description minimally indicates the resource but lacks details on what the source code output looks like or any limitations.

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% with basic descriptions for both parameters. The tool description adds no additional meaning beyond the schema.

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 action ('Retrieve') and the resource ('ABAP Function Module source code'), which distinguishes it from sibling tools targeting other object types like GetClass or GetProgram.

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?

No explicit guidelines on when to use this tool vs. alternatives, but the resource name and sibling tool names make the context implied.

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

GetFunctionGroupC

Retrieve ABAP Function Group source code

ParametersJSON Schema

Name	Required	Description	Default
`function_group`	Yes	Name of the function module

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description must fully convey behavioral traits. It only states 'Retrieve', implying a read operation, but fails to mention error handling, permissions, or what happens if the function group does not exist.

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 concise and front-loaded, using a single sentence. However, it sacrifices completeness for brevity, missing context that could improve usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema and annotations, the description is incomplete. It does not specify the format of the source code, limitations, or error handling, leaving the agent underinformed.

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?

The input schema already describes the single parameter as 'Name of the function module' with 100% coverage. The description adds no additional semantic value beyond what the schema provides.

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 specifies the verb 'Retrieve' and the resource 'ABAP Function Group source code', clearly indicating the tool's function. It distinguishes from siblings like GetFunction (which retrieves a function module) and GetProgram.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like GetFunction or GetInclude. The description lacks any context for appropriate usage.

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

GetIncludeB

Retrieve ABAP Include Source Code

ParametersJSON Schema

Name	Required	Description	Default
`include_name`	Yes	Name of the ABAP Include

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states the retrieval action but does not disclose safety, authorization needs, or behavior when include is not found. For a mere retrieval tool, this is minimal transparency.

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 a single, clear sentence with no redundant words. Every word adds value, achieving maximum conciseness.

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 a simple retrieval tool with one parameter and no output schema, the description is minimally adequate. It covers the primary purpose but lacks details on return format, error handling, or prerequisites, which could help the agent.

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%, and the parameter is adequately described as 'Name of the ABAP Include'. The tool description adds no further meaning beyond the schema, which is acceptable given high coverage.

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 uses a specific verb 'Retrieve' and resource 'ABAP Include Source Code', clearly indicating the tool's function. However, it does not differentiate from sibling tools like GetProgram or GetFunction, which also retrieve source code for different ABAP objects.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings such as GetProgram or GetFunction. There is no mention of prerequisites, context, or exclusions.

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

GetInterfaceC

Retrieve ABAP interface source code

ParametersJSON Schema

Name	Required	Description	Default
`interface_name`	Yes	Name of the ABAP interface

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description must bear full burden. Only states retrieval, but lacks details on side effects, authentication, or output constraints. Insufficient for a read tool.

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?

Extremely concise single sentence, no unnecessary words. Lacks structural elements like bullet points, but efficiency earns a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations; description fails to explain return format, prerequisites, or how it differs from 12 siblings. Incomplete for a tool in this context.

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% for the single required parameter (interface_name). Description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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?

Clearly states verb 'Retrieve' and resource 'ABAP interface source code'. However, does not differentiate from sibling tools like GetClass or GetFunction that also retrieve source code, preventing a 5.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like GetTypeInfo or SearchObject. Description is minimal with no context for selection.

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

GetPackageB

Retrieve ABAP package details

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes	Name of the ABAP package

TDQS

B3.2/5.0

Behavior2/5

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

The description does not disclose any behavioral traits such as whether the tool is read-only, what 'package details' comprises, or any authentication or performance implications. With no annotations, the description carries the full burden but fails to elaborate.

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 a single, clear sentence with no extraneous words. It is appropriately front-loaded and efficient for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description is insufficient. It does not explain what 'details' are returned, leaving the agent unsure of the tool's output. For a retrieval tool, more context is needed.

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% as the single parameter 'package_name' is described. However, the description adds no additional meaning beyond the schema; it simply restates the parameter name. Baseline 3 is appropriate.

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 description explicitly states the action 'Retrieve' and the resource 'ABAP package', clearly distinguishing it from sibling tools that target different ABAP object types (e.g., GetClass, GetFunction).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like SearchObject or other Get tools. The description lacks context about prerequisites or scenarios.

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

GetProgramB

Retrieve ABAP program source code

ParametersJSON Schema

Name	Required	Description	Default
`program_name`	Yes	Name of the ABAP program

TDQS

B3.2/5.0

Behavior2/5

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

Without annotations, the description carries full burden. It states a read operation but does not disclose authorization needs, error handling, size limits, or return format—minimal behavioral insight.

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 a single, concise sentence with no redundant words. However, it is almost too minimal, lacking detail that could be provided without bloat.

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 a simple retrieval tool with one parameter and no output schema, the description is passable but incomplete—it hints at the return value but does not specify the format or any additional context like rate limits or prerequisites.

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?

The input schema has full coverage (100%) with a clear description for 'program_name'. The tool description adds no extra meaning beyond the schema, meeting baseline but not exceeding it.

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 description uses a specific verb ('Retrieve') and clarifies it returns 'ABAP program source code', making the tool's function clear and distinguishing it from siblings like GetClass or GetFunction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. The sibling list implies differentiation by object type, but no explicit direction is given.

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

GetStructureC

Retrieve ABAP Structure

ParametersJSON Schema

Name	Required	Description	Default
`structure_name`	Yes	Name of the ABAP Structure

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only says 'Retrieve', which implies a read operation, but does not state what is returned, whether it is safe, or any side effects. The complete lack of behavioral details is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is extremely concise at four words, but it is under-specified lacking essential context. While concise, it does not earn its place as it fails to provide sufficient information for effective tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description should at least indicate what kind of data is returned (e.g., structure fields). The current description is too sparse to be complete.

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% for the single parameter 'structure_name', which is described as 'Name of the ABAP Structure'. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 'Retrieve ABAP Structure' clearly states the action (retrieve) and the resource (ABAP Structure). It distinguishes from siblings like GetClass or GetTable by specifying the object type 'Structure', though it lacks elaboration on what exactly is retrieved (e.g., metadata, definition).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like GetTable or GetClass. There is no mention of prerequisites, context, or exclusions.

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

GetTableB

Retrieve ABAP table structure

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	Name of the ABAP table

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden, but it only states the basic action. It omits behavioral details such as whether any prerequisites or side effects exist, or the format of the returned structure.

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?

A single sentence with no filler, but extremely brief. While concise, it might sacrifice necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should explain what 'table structure' entails (e.g., fields, keys). It fails to provide a complete picture, leaving ambiguity.

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?

The input schema covers the single parameter fully with a description, and the tool description adds no extra semantics. Baseline 3 is appropriate as schema coverage is 100%.

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 description 'Retrieve ABAP table structure' uses a specific verb and resource, clearly distinguishing it from siblings like GetTableContents (which retrieves data) and GetStructure (which may refer to other dictionary structures).

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 use for structure retrieval, and sibling names suggest alternatives like GetTableContents for data, but no explicit guidance on when or why to choose this tool over others.

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

GetTableContentsC

Retrieve contents of an ABAP table

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	Name of the ABAP table
`max_rows`	No	Maximum number of rows to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, and the description only says 'Retrieve contents', implying a read-only operation but not confirming it. No disclosure of potential side effects, authentication needs, or rate limits.

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 a single sentence, very concise, and free of fluff. However, it may be too sparse, sacrificing completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, and considering the sibling tools' context, the description should provide more details on return format, pagination, or constraints, but it does not.

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% with parameter descriptions. The description adds no extra semantic value beyond what the schema already provides, meeting the baseline for high coverage.

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 function: retrieving contents of an ABAP table. However, it does not distinguish from siblings like 'GetTable' which might fetch metadata, or 'SearchObject' which may involve table lookups.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives. There is no mention of prerequisites, limitations, or scenarios where another sibling tool would be more appropriate.

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

GetTransactionC

Retrieve ABAP transaction details

ParametersJSON Schema

Name	Required	Description	Default
`transaction_name`	Yes	Name of the ABAP transaction

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'retrieve', implying a read-only operation, but does not explain authentication needs, error handling, or what happens if the transaction does not exist. This is insufficient for a tool with no annotations.

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 a single, concise sentence that front-loads the purpose. It contains no unnecessary words. However, it could be slightly expanded to include key details without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and simple input, the description should at least hint at the output structure or what 'details' entails. It does not, leaving ambiguity. For a retrieval tool, the absence of return value information is a notable gap.

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% with the parameter 'transaction_name' having a description 'Name of the ABAP transaction'. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 'Retrieve ABAP transaction details' clearly identifies the action (retrieve) and the resource (ABAP transaction details). It distinguishes from sibling tools like GetProgram or GetTable by specifying 'transaction'. However, 'details' is vague and could be more specific.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as GetProgram or GetTable. The context is only implicit through the tool name and sibling list. No explicit when/when-not or alternative suggestions are given.

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

GetTypeInfoC

Retrieve ABAP type information

ParametersJSON Schema

Name	Required	Description	Default
`type_name`	Yes	Name of the ABAP type

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only implies a read operation but offers no details on error handling, performance, or what happens when the type does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is very short (one phrase) and front-loaded. However, it is so brief that it borders on under-specification, missing opportunities to add valuable context in a concise way.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool takes a single required parameter and has no output schema, the description is minimally complete but does not cover return values, error conditions, or tie-breakers among many sibling tools. A more complete description would help an agent select and invoke correctly.

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% with one parameter ('type_name') described as 'Name of the ABAP type'. The description adds no additional semantic meaning beyond what the schema already provides, so baseline 3 applies.

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 action ('Retrieve') and the resource ('ABAP type information'). It is distinct from sibling tools like GetTable or GetStructure which focus on specific data dictionary objects, so the purpose is clear.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as GetStructure, GetTable, etc. The description lacks context for selection among the 12 sibling tools.

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

SearchObjectC

Search for ABAP objects using quick search

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query string (use * wildcard for partial match)
`maxResults`	No	Maximum number of results to return

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description provides minimal behavioral info: only 'quick search'. It does not disclose whether the operation is read-only, requires authentication, or how results are structured, leaving significant ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single, concise sentence, but it could include additional useful context without becoming verbose. It is adequately sized but misses opportunities to enhance clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. An agent lacks information about result format, search behavior (e.g., case sensitivity), and potential limitations, which are critical for a search tool.

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 both parameters are well-documented in the schema. The description adds no extra meaning beyond what is already in the schema fields.

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 'Search for ABAP objects' with a verb and resource, and implicitly distinguishes from sibling tools which are specific getters for individual object types. However, it lacks specificity about the scope of object types covered.

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

Usage Guidelines2/5

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

No explicit guidance on when to use SearchObject versus sibling tools like GetClass or GetProgram. The agent must infer usage from context, increasing risk of incorrect tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv1.1.0Jun 18, 2026
- First observedGetClass
- First observedGetFunction
- First observedGetFunctionGroup
- First observedGetInclude
- First observedGetInterface
- First observedGetPackage
- First observedGetProgram
- First observedGetStructure
- First observedGetTable
- First observedGetTableContents
- First observedGetTransaction
- First observedGetTypeInfo
- First observedSearchObject

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct ABAP object type (class, function, table, etc.), with clear boundaries. No two tools overlap in purpose.

Naming Consistency4/5

All tools follow 'Get<ObjectType>' pattern except 'SearchObject' (uses 'Search' instead of 'Get'), which is a minor deviation. Overall consistent verb-noun structure.

Tool Count4/5

13 tools is a reasonable count for an ABAP retrieval server, covering many common object types. Slightly above typical range but not excessive.

Completeness3/5

The set provides read-only access to many ABAP artifacts, but lacks write operations (create, update, delete) and some common types like CDS views. Notable gaps exist but core retrieval is covered.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Azure DevOps (ADO)OAuth
io.github.PremierInc
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
CI/CD & DevOps Version Control Project Management
21,997
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13

Related MCP Servers

MCP ABAP ADT
ERP Systems Developer Tools
mario-andreschak
A
license
B
quality
A
maintenance
A server that bridges the Model Context Protocol (MCP) with SAP ABAP systems, allowing tools like Cline to retrieve ABAP source code, table structures, and other development artifacts.
Updated 4 days ago (2026-09-02 19:40 UTC)
13
177
183
MIT
ABAP-ADT-API MCP-Server
Developer Tools ERP Systems
dachienit
A
license
C
quality
Not graded
maintenance
An MCP server that facilitates seamless interaction with SAP ABAP systems to manage development objects, transport requests, and source code. It provides a comprehensive suite of tools for performing syntax checks, object searches, and code modifications via the ADT API.
Updated 7 months ago (2026-02-05 03:20 UTC)
100
-
ABAP-ADT-API MCP-Server
Developer Tools Code Analysis
dachienit
A
license
C
quality
D
maintenance
An MCP server that enables seamless communication between ABAP systems and MCP clients using the ABAP Development Tools (ADT) API. It provides tools for managing ABAP objects, handling transport requests, and performing code analysis directly through MCP-compatible interfaces.
Updated 5 months ago (2026-03-30 03:11 UTC)
100
MIT
dassian-adtofficial
Developer Tools Code Execution Code Analysis
DassianInc
A
license
Not graded
quality
D
maintenance
MCP server for SAP ABAP development via the ADT API. Connect AI assistants to your SAP system — read, write, test, and deploy ABAP code without SAP GUI.
Updated 2 days ago (2026-09-04 21:26 UTC)
9
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SproitNET/mcp-abap-adt'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-abap-adt: Your Gateway to ABAP Development Tools (ADT)

1. Prerequisites

2. Installation and Setup

Installing via Smithery

Manual Installation

3. Running the Server

3.1 Standalone Mode

3.2 Development/Debug Mode (with Inspector)

4. Integrating with Cline

5. Troubleshooting

6. Available Tools

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

dassian-adtofficial

Latest Blog Posts

MCP directory API