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 "Install 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves source code, implying a read-only operation, but doesn't specify whether authentication is required, if there are rate limits, what format the source code is returned in, or if there are any constraints on accessible classes. The description is minimal and lacks crucial operational context.
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 just three words, with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by contributing essential information.
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, the description is incomplete for effective tool use. It doesn't explain what the tool returns (e.g., raw code, structured metadata, error handling), nor does it provide context about permissions, system dependencies, or common failure modes. For a retrieval tool with no structured output documentation, more descriptive guidance 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?
The input schema has 100% description coverage, with the single parameter 'class_name' documented as 'Name of the ABAP class'. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Since schema coverage is high, the 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 clearly states the verb ('Retrieve') and resource ('ABAP class source code'), making the purpose immediately understandable. It distinguishes this tool from siblings like GetFunction or GetProgram by specifying it retrieves class source code specifically. However, it doesn't explicitly contrast with all siblings (e.g., GetTypeInfo might also retrieve class-related information).
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. It doesn't mention when to choose GetClass over GetInterface for interface-related classes, or when to use SearchObject for broader searches. There's no context about prerequisites, limitations, or typical use cases beyond the basic purpose.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't specify whether this requires special permissions, what format the source code returns in, whether there are size limitations, or if there are rate limits. For a tool that accesses potentially sensitive source code, this 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 a single, efficient sentence that immediately communicates the core purpose without any wasted words. It's perfectly front-loaded and appropriately sized for this type of retrieval 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?
For a tool that retrieves source code with no annotations and no output schema, the description is inadequate. It doesn't explain what format the source code returns in (raw text, structured data), whether it includes metadata, or how to handle large function modules. Given the complexity of source code retrieval and lack of structured output documentation, 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?
The schema has 100% description coverage, with both parameters clearly documented in the schema itself. The description doesn't add any additional context about parameter semantics beyond what's already in the schema, so it meets the baseline for high schema 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 verb 'Retrieve' and the resource 'ABAP Function Module source code', making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'GetFunctionGroup' which might retrieve related metadata rather than source code.
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 'GetFunctionGroup' or 'SearchObject'. There's no mention of prerequisites, typical use cases, or comparison with sibling tools that might retrieve similar ABAP objects.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't specify whether authentication is needed, what format the source code returns in, if there are rate limits, or how errors are handled. This leaves significant behavioral gaps for a tool that accesses source code.
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 perfectly concise - a single sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core purpose and doesn't include any unnecessary information.
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 tool that retrieves source code with no annotations and no output schema, the description is insufficient. It doesn't explain what format the source code returns in (raw text, structured format), whether it includes metadata, or how to handle the result. The context signals show this is part of a larger ABAP development toolset, but the description doesn't leverage 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?
The schema has 100% description coverage, with the single parameter clearly documented as 'Name of the function module'. The description doesn't add any additional parameter semantics beyond what the schema already provides, which is acceptable given the high schema 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 verb ('Retrieve') and resource ('ABAP Function Group source code'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'GetFunction', which likely retrieves individual function modules rather than function groups.
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 'GetFunction' or 'SearchObject'. There's no mention of prerequisites, context, or exclusions that would help an agent choose appropriately among the many sibling tools.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Retrieve' implies a read operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what format the source code is returned in. For a tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 - a single phrase that communicates the essential purpose without any wasted words. It's front-loaded with the core functionality and contains no unnecessary elaboration. This represents optimal efficiency in description length.
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 retrieval tool with no annotations and no output schema, the description is insufficiently complete. While the purpose is clear, there's no information about what format the source code is returned in, potential limitations, error handling, or how this tool differs from similar retrieval tools in the sibling set. The description doesn't compensate for the lack of structured metadata.
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 schema has 100% description coverage, with the single parameter 'include_name' clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 verb 'Retrieve' and the resource 'ABAP Include Source Code', making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like GetClass or GetProgram, but the specificity of 'ABAP Include' provides some implicit distinction. The description avoids tautology by not simply restating the tool name.
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 GetProgram or SearchObject. There's no mention of prerequisites, context for selecting this specific retrieval tool, or any exclusions. The agent must infer usage from the tool name and description alone without explicit direction.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves source code but doesn't describe what 'retrieve' entails (e.g., read-only operation, format of returned data, error handling, or authentication requirements). This leaves significant gaps for a tool that presumably accesses system resources.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'retrieve' returns (e.g., raw code, metadata, error formats) or address behavioral aspects like permissions or system impact, leaving the agent with incomplete context for safe and effective use.
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%, with the single parameter 'interface_name' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as naming conventions or examples, so it meets the baseline for high schema 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 action ('Retrieve') and the resource ('ABAP interface source code'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like GetClass or GetFunction, which follow the same pattern for different ABAP 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 like GetClass or GetFunction. The description doesn't mention prerequisites, context for interface retrieval, or any limitations compared to other retrieval tools in the sibling list.
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?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It lacks information on permissions needed, error handling, rate limits, or what 'details' include, which is critical for a read operation without output schema.
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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete for a tool that retrieves details. It doesn't specify what details are returned, error cases, or behavioral context, leaving significant gaps for agent understanding.
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 the schema already documents the single parameter 'package_name'. The description adds no additional meaning beyond implying retrieval of details, which aligns with the schema but doesn't enhance parameter understanding. 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 clearly states the verb 'Retrieve' and the resource 'ABAP package details', making the purpose understandable. It distinguishes from siblings like GetClass or GetTable by specifying package details, but doesn't explicitly contrast with other package-related tools (none listed).
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. The description doesn't mention prerequisites, context, or comparisons to sibling tools like SearchObject, leaving the agent to infer usage 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Retrieve' implies a read operation, but the description doesn't specify whether this requires special permissions, what format the source code is returned in, if there are size limitations, or how errors are handled. For a tool with zero annotation coverage, this 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
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 single-parameter retrieval tool with no output schema and no annotations, the description is minimally adequate. It identifies what's being retrieved but lacks important context about return format, error conditions, and differentiation from sibling tools. The simplicity of the tool keeps it from being completely inadequate.
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 the schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format examples, naming conventions, or valid program types). With complete schema coverage, the 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 clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('ABAP program source code'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings like GetClass or GetFunction, which likely retrieve different types of 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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for retrieving different ABAP objects (GetClass, GetFunction, GetInclude, etc.), there's no indication that this tool is specifically for programs rather than other object types.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Retrieve' which implies a read operation, but doesn't specify permissions needed, rate limits, error handling, or what the return format looks like. This is inadequate for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's front-loaded and clear, though it could benefit from more detail to improve other dimensions without sacrificing 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Retrieve' entails (e.g., returns metadata, fields, or full definition), making it hard for an agent to understand the tool's behavior and output without additional 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?
The input schema has 100% description coverage, with 'structure_name' fully documented. The description doesn't add any parameter details beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter semantics.
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 resource (ABAP Structure), but it doesn't differentiate from siblings like GetClass, GetFunction, GetTable, etc. It's vague about what specifically distinguishes retrieving a structure from retrieving other ABAP objects, though the purpose is understandable.
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. The description doesn't mention prerequisites, context for use, or comparisons to sibling tools like GetTypeInfo or SearchObject, leaving the agent with no usage instructions.
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 provided, the description carries the full burden of behavioral disclosure. It states 'retrieve' but doesn't clarify if this is a read-only operation, what permissions are needed, how errors are handled, or the format of the returned structure. This leaves significant gaps for a tool that likely interacts with a database system.
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, efficient sentence with no wasted words. It is appropriately sized for a simple tool and front-loaded with the core action, making it easy to understand at a glance.
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 complexity of retrieving database table structures, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'structure' entails (e.g., fields, types, keys), potential errors, or usage context, leaving the agent with insufficient information for reliable invocation.
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%, with the parameter 'table_name' fully documented in the schema as 'Name of the ABAP table'. The description adds no additional meaning beyond this, such as syntax examples or constraints, so it meets the baseline for high schema 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 verb 'retrieve' and the resource 'ABAP table structure', making the purpose understandable. However, it doesn't differentiate from sibling tools like GetStructure or GetTableContents, which likely retrieve similar ABAP objects, so it doesn't fully distinguish itself.
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 GetStructure or GetTableContents. The description lacks context about prerequisites, such as whether the table must exist or be accessible, or any exclusions for usage.
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 are provided, so the description carries the full burden of behavioral disclosure. It states the action 'retrieve' but lacks details on permissions required, error handling, rate limits, or what the output looks like (e.g., format, pagination). This is a significant gap for a read operation tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
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, the description is incomplete. It does not explain behavioral aspects like what 'contents' includes (e.g., rows, columns), potential limitations, or error cases. For a tool with two parameters and no structured output information, more context is needed to guide effective use.
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 100% description coverage, clearly documenting both parameters ('table_name' and 'max_rows') with defaults and requirements. The description does not add any additional meaning beyond this, such as examples or constraints, so it meets the baseline for adequate but not enhanced parameter semantics.
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 verb 'retrieve' and the resource 'contents of an ABAP table', making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'GetTable' (which might retrieve table metadata rather than contents) or 'SearchObject' (which might search across objects), leaving some ambiguity about when to choose this specific tool.
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. It does not mention prerequisites, such as needing the table name, or compare it to siblings like 'GetTable' or 'SearchObject', leaving the agent to infer usage context without explicit direction.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Retrieve' which implies a read operation, but doesn't cover aspects like error handling, authentication needs, rate limits, or what 'details' includes. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
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 annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, error cases, or how this fits with sibling tools. For a retrieval tool in a complex SAP environment, more context is needed to guide effective use.
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 100% description coverage, with the parameter 'transaction_name' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema 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 verb ('Retrieve') and resource ('ABAP transaction details'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings like GetClass or GetFunction, which follow similar patterns for different SAP objects, so it misses full sibling distinction.
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. With siblings like SearchObject that might find transactions, there's no indication of when retrieval by exact name is preferred over search, or any prerequisites for usage.
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 carries full burden for behavioral disclosure. It only states what the tool does ('Retrieve'), but doesn't describe any behavioral traits such as whether it's read-only, if it requires specific permissions, error handling, or what format the information is returned in. This is inadequate for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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, the description is incomplete. It doesn't explain what 'ABAP type information' includes, the return format, or any behavioral context needed for effective use. For a tool with no structured metadata, this minimal description leaves significant gaps.
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 100% description coverage, with the single parameter 'type_name' clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples or constraints. With high schema coverage, the 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 clearly states the verb ('Retrieve') and resource ('ABAP type information'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from its sibling tools (like GetStructure or GetTable), which also retrieve ABAP metadata, so it doesn't reach the highest score.
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. With multiple sibling tools retrieving different ABAP metadata (GetClass, GetFunction, GetStructure, etc.), there's no indication of when this specific tool for type information is appropriate versus other options.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a search but doesn't describe what 'quick search' entails (e.g., search scope, performance implications, or result format). It lacks details on permissions, rate limits, or error handling, leaving significant gaps 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, efficient sentence with zero waste. It is front-loaded and appropriately sized, clearly stating the tool's purpose without unnecessary elaboration.
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 annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., object types, fields) or behavioral aspects like pagination or errors. For a search tool with 2 parameters and multiple siblings, more context is needed to guide effective use.
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 the schema already documents both parameters (query and maxResults) with descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 tool's purpose as 'Search for ABAP objects using quick search', which includes a specific verb ('Search') and resource ('ABAP objects'). It distinguishes from siblings like GetClass or GetTable by focusing on search functionality rather than direct retrieval, though it doesn't explicitly contrast with them.
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. The description mentions 'quick search' but doesn't specify scenarios where this is preferred over sibling tools like GetTable or GetProgram, nor does it mention prerequisites or exclusions.
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. Dates show when Glama detected each change.
v1.0.0GetClassGetFunctionGetFunctionGroupGetIncludeGetInterfaceGetPackageGetProgramGetStructureGetTableGetTableContentsGetTransactionGetTypeInfoSearchObjectEvery 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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mario-andreschak/mcp-abap-adt'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
