The MCP ABAP ADT server acts as a bridge to interact with SAP ABAP systems, enabling retrieval and manipulation of development data through the ABAP Development Tools protocol.
Key capabilities:
Source Code Retrieval: Access ABAP programs, classes, function modules/groups, includes, and interfaces
Data Structure Access: Retrieve ABAP structures, table structures, and table contents
Development Object Management: Obtain package details, type information, and transaction details
Search Functionality: Perform quick searches for ABAP objects
Integration: Connect with tools like Cline for enhanced ABAP development in VS Code
Allows interaction with SAP ABAP systems to retrieve information like source code, table structures, and more through ABAP Development Tools (ADT)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
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.
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 FLUJO, Claude or 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!
The server is published on npm as mcp-abap-adt and listed in the MCP Registry as io.github.mario-andreschak/mcp-abap-adt, so most MCP clients can install it with a single command.
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 FLUJO: The easiest way — one-click install from the Spotlight/Marketplace.
Integrating with Cline: Connecting this server to the Cline VS Code extension.
Integrating with Claude Desktop: Adding the server to the Claude Desktop app.
Integrating with Claude Code: Adding the server via .mcp.json or the CLI.
Troubleshooting: Common problems and solutions.
Available Tools: A list of the commands you can use.
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
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 -vYou 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).
Git (or GitHub Desktop) (optional in most cases): 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.
Related MCP server: ABAP-ADT-API MCP-Server
Now, let's get the project code and set it up:
The server is published on npm, so you don't need to clone or build anything. Most MCP clients can run it directly with npx:
npx -y mcp-abap-adtYou'll typically configure this inside your MCP client rather than run it by hand — point the client at the command npx with args ["-y", "mcp-abap-adt"] and supply your SAP credentials as environment variables (SAP_URL, SAP_USERNAME, SAP_PASSWORD, SAP_CLIENT; optionally SAP_LANGUAGE, TLS_REJECT_UNAUTHORIZED). See the integration sections below for and Cline.
To install it globally instead:
npm install -g mcp-abap-adtClone the Repository:
Using Git (command line):
Open a terminal (command prompt or Terminal).
Navigate to the directory where you want to store the project. For example, to put it on your Desktop:
cd DesktopClone the repository:
git clone https://github.com/mario-andreschak/mcp-abap-adtChange into the project directory:
cd mcp-abap-adt # Or whatever the folder name isUsing GitHub Desktop:
Open GitHub Desktop.
Click "File" -> "Clone Repository...".
In the "URL" tab, paste the repository URL.
Choose a local path (where you want to save the project on your computer).
Click "Clone".
Install Dependencies: This downloads all the necessary libraries the project needs. In the terminal, inside the root directory, run:
npm installThis might take a few minutes.
Build the Project: This compiles the code into an executable format.
npm run buildCreate a .env file: This file stores sensitive information like your SAP credentials. It's very important to keep this file secure.
In the root directory, create a new file named .env (no extension).
Open the .env file in a text editor (like Notepad, VS Code, etc.).
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 clientImportant: Never share your .env file with anyone, and never commit it to a Git repository!
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 Claude, FLUJO, Cline, etc. 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.
To run the server in standalone mode, use the following command in the terminal (from the root directory):
npm run startYou 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).
This mode is useful for debugging.
Start the server in debug mode:
npm run devThis 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.
FLUJO is the easiest way to use this server — no cloning, building, or editing JSON config. mcp-abap-adt is a curated Spotlight server, so it installs with a single click:
In FLUJO, navigate to MCP.
Click Add Server.
On the Spotlight tab, click mcp-abap-adt (or switch to the Marketplace tab and find it there).
FLUJO fetches the package automatically and opens the Local Server tab. Enter your SAP URL, Username, and Password (and client), then click Save.
That's it — FLUJO downloads and runs the npm package for you.
mcp-abap-adt runs over stdio. If you need to reach it over streamable HTTP — for example from another app on your machine or a client that only speaks HTTP — let FLUJO re-host it: install the server in FLUJO as above, then toggle "Expose to external apps" on the server. FLUJO's built-in mcp-proxy then serves it over HTTP at http://localhost:4200/mcp-proxy/mcp-abap-adt, and any HTTP-capable MCP client can connect with a config like:
{
"mcpServers": {
"mcp-abap-adt": {
"type": "http",
"url": "http://localhost:4200/mcp-proxy/mcp-abap-adt"
}
}
}FLUJO keeps your SAP credentials with the installed server, so the HTTP config itself carries none.
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 mcpServers object in the cline_mcp_settings.json file. The recommended way is to run the published npm package via npx and pass your SAP credentials as environment variables — no local build required:
{
"mcpServers": {
"mcp-abap-adt": {
"command": "npx",
"args": ["-y", "mcp-abap-adt"],
"env": {
"SAP_URL": "https://your-sap-system.com:8000",
"SAP_USERNAME": "your_username",
"SAP_PASSWORD": "your_password",
"SAP_CLIENT": "100"
},
"disabled": false,
"autoApprove": []
}
// ... other server configurations ...
}
}If you installed from source instead (see Manual Installation), point command at node with an absolute path to the build output, e.g. "args": ["C:/PATH_TO/mcp-abap-adt/dist/index.js"], and configure credentials via the .env file.
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
Claude Desktop can run this server directly via the published npm package.
Open Claude Desktop → Settings → Developer → Edit Config. This opens claude_desktop_config.json. The file lives at:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Add an mcp-abap-adt entry under mcpServers, filling in your SAP credentials:
{
"mcpServers": {
"mcp-abap-adt": {
"command": "npx",
"args": ["-y", "mcp-abap-adt"],
"env": {
"SAP_URL": "https://your-sap-system.com:8000",
"SAP_USERNAME": "your_username",
"SAP_PASSWORD": "your_password",
"SAP_CLIENT": "100"
}
}
}
}Save the file and restart Claude Desktop. The ABAP tools appear under the tools (🔨) menu.
Windows tip: if
npxisn't found, set"command": "npx.cmd", or use the full path tonodewith the absolute path todist/index.jsfrom a source install.
Claude Code reads MCP servers from a .mcp.json file in your project root (shared with your team) or from user/project scope via the CLI.
Option A — .mcp.json in your project root:
{
"mcpServers": {
"mcp-abap-adt": {
"command": "npx",
"args": ["-y", "mcp-abap-adt"],
"env": {
"SAP_URL": "https://your-sap-system.com:8000",
"SAP_USERNAME": "your_username",
"SAP_PASSWORD": "your_password",
"SAP_CLIENT": "100"
}
}
}
}Because this file is committed to your repo, avoid putting real passwords in it — either use placeholder values that each developer fills in locally, or reference environment variables (Claude Code expands ${VAR} in .mcp.json), e.g. "SAP_PASSWORD": "${SAP_PASSWORD}".
Option B — add it from the CLI:
claude mcp add mcp-abap-adt \
--env SAP_URL=https://your-sap-system.com:8000 \
--env SAP_USERNAME=your_username \
--env SAP_PASSWORD=your_password \
--env SAP_CLIENT=100 \
-- npx -y mcp-abap-adtAdd --scope project to write it to the shared .mcp.json, or --scope user to make it available across all your projects. Verify with claude mcp list.
All text-returning tools support the optional startLine and maxLines arguments: GetProgram, GetClass, GetFunctionGroup, GetFunction, GetStructure, GetTable, GetTableContents, GetPackage, GetTypeInfo, GetInclude, SearchObject, GetTransaction, GetCDSView, GetInterface, GetBehaviorDefinition, and GetServiceDefinition. GetTableContents.max_rows and SearchObject.maxResults still limit upstream records; paging independently protects the textual response size.
startLine is a 1-based integer. It defaults to 1.
maxLines is an integer from 1 through 100,000. When omitted, the tool requests all remaining lines.
A small response with neither paging argument keeps the existing raw content[0].text exactly.
Any explicit paging request returns a JSON envelope in content[0].text.
An unpaged result that exceeds the conservative 40,000-byte UTF-8 budget is automatically reduced and returned in the same envelope with autoPaged: true and capped: true.
A request beyond EOF returns content: "", returnedLines: 0, and hasMore: false.
The envelope has this shape:
{
"content": "...returned source lines...",
"totalLines": 7745,
"startLine": 1,
"returnedLines": 1200,
"hasMore": true,
"autoPaged": true,
"capped": true
}content is the selected text, totalLines describes the full serialized result, and returnedLines counts source lines consumed. Continue ordinary paging with startLine + returnedLines while hasMore is true. autoPaged appears only when the caller did not request paging. capped means the requested/default range was reduced to meet the final content[0].text UTF-8 byte budget.
If one source line alone exceeds the budget, the envelope also contains truncatedMidLine: true. The returned prefix is UTF-8 safe and does not split a Unicode surrogate pair, but the omitted suffix cannot be recovered with line-based paging. That line counts as consumed; hasMore only indicates whether later source lines exist.
Clients that previously treated every result as raw source should parse content[0].text as JSON whenever they explicitly request paging or when automatic capping returns an envelope. Small unpaged responses remain backward compatible.
The default npm test run is credential-free and skips the live SAP integration suite. Maintainers can opt in by setting RUN_SAP_INTEGRATION=1 before running npm test -- src/index.test.ts.
node -v or npm -v gives an error:
Make sure Node.js is installed correctly. First try closing the Terminal/Powershell/cmd.exe in which you were executing the command. Try restarting your computer. 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!
This server provides the following tools, which can be used through FLUJO, Cline, Claude Desktop, Claude Code, or any other MCP client. Every listed tool also accepts the shared optional startLine and maxLines pagination parameters described above:
Tool Name | Description | Input Parameters | Example Usage (in Cline) |
| Retrieve ABAP program source code. |
|
|
| Retrieve ABAP class source code. |
|
|
| Retrieve ABAP Function Group source code. |
|
|
| Retrieve ABAP Function Module source code. |
|
|
| Retrieve ABAP Structure. |
|
|
| Retrieve ABAP table structure. |
|
|
| Retrieve contents of an ABAP table. |
|
|
| Retrieve CDS view (DDL source) source code. |
|
|
| Retrieve ABAP package details. |
|
|
| Retrieve ABAP type information. |
|
|
| Retrieve ABAP include source code |
|
|
| Search for ABAP objects using quick search. |
|
|
| Retrieve ABAP interface source code. |
|
|
| Retrieve ABAP transaction details. |
|
|
| Retrieve RAP Behavior Definition (BDEF) source. Requires ~NW 7.54 / S/4HANA. |
|
|
| Retrieve RAP Service Definition (SRVD) source. Requires ~NW 7.54 / S/4HANA. |
|
|
Retrieve ABAP class source code
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | Name of the ABAP class |
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.
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.
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.
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.
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.
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.
Retrieve ABAP Function Module source code
| Name | Required | Description | Default |
|---|---|---|---|
| function_name | Yes | Name of the function module | |
| function_group | Yes | Name of the function group |
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.
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.
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.
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.
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.
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.
Retrieve ABAP Function Group source code
| Name | Required | Description | Default |
|---|---|---|---|
| function_group | Yes | Name of the function module |
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.
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.
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.
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.
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.
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.
Retrieve ABAP Include Source Code
| Name | Required | Description | Default |
|---|---|---|---|
| include_name | Yes | Name of the ABAP Include |
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.
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.
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.
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.
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.
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.
Retrieve ABAP interface source code
| Name | Required | Description | Default |
|---|---|---|---|
| interface_name | Yes | Name of the ABAP interface |
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.
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.
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.
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.
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.
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.
Retrieve ABAP package details
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | Yes | Name of the ABAP package |
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.
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.
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.
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.
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.
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.
Retrieve ABAP program source code
| Name | Required | Description | Default |
|---|---|---|---|
| program_name | Yes | Name of the ABAP program |
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.
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.
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.
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.
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.
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.
Retrieve ABAP Structure
| Name | Required | Description | Default |
|---|---|---|---|
| structure_name | Yes | Name of the ABAP Structure |
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.
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.
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.
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.
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.
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.
Retrieve ABAP table structure
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the ABAP table |
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.
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.
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.
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.
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.
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.
Retrieve contents of an ABAP table
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the ABAP table | |
| max_rows | No | Maximum number of rows to retrieve |
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.
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.
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.
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.
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.
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.
Retrieve ABAP transaction details
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_name | Yes | Name of the ABAP transaction |
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.
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.
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.
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.
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.
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.
Retrieve ABAP type information
| Name | Required | Description | Default |
|---|---|---|---|
| type_name | Yes | Name of the ABAP type |
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.
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.
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.
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.
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.
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.
Search for ABAP objects using quick search
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string (use * wildcard for partial match) | |
| maxResults | No | Maximum number of results to return |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0GetClassGetFunctionGetFunctionGroupGetIncludeGetInterfaceGetPackageGetProgramGetStructureGetTableGetTableContentsGetTransactionGetTypeInfoSearchObjectScored across 13 tools
Every tool has a clearly distinct purpose targeting specific ABAP object types or operations. The 'Get' tools each retrieve different ABAP artifacts (class, function, interface, etc.), while SearchObject provides a distinct search capability. No ambiguity exists between tools.
All tools follow a consistent verb_noun pattern with 'Get' prefix for retrieval operations and 'SearchObject' as the only exception that still maintains clear verb_noun structure. The naming is perfectly predictable and readable throughout the set.
13 tools is well-scoped for an ABAP development tool server, providing comprehensive coverage of different ABAP object types. Each tool earns its place by addressing a specific retrieval need in the ABAP domain without being overwhelming.
The server provides excellent retrieval coverage for ABAP development objects, but lacks modification capabilities (create, update, delete). For a read-only development tool interface, this is reasonable, though agents cannot perform full lifecycle operations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
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.
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
