Provides tools to interact with SAP ABAP systems, enabling retrieval of source code, table structures, and other development objects 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 source code for program ZHELLO_WORLD"
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 checkout uses TypeScript MCP SDK 2 and supports modern protocol 2026-07-28 plus legacy 2025-11-25 over stdio, using the SDK's first-message routing. Node.js 22 or 24 LTS is required. The advertised server version comes from package.json. Tool discovery works without SAP credentials; calls that access SAP require the configuration below. See protocol migration guidance.
The sixteen tools are read-only. Native HTTP is not exposed by this executable; any HTTP bridge has its own authentication, Origin and deployment requirements. Classic screen creation/update requested in #17 remains an open enhancement; see the supported workflow and implementation prerequisites.
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, SAP_CA_FILE). See the integration sections below for FLUJO 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 ciThis 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!
Certificate and hostname verification is enabled by default. For a SAP system signed by your organization's private CA, set SAP_CA_FILE=/absolute/path/sap-ca.pem to a readable PEM CA bundle. It augments Node's bundled roots. When running in Docker, mount the bundle read-only and provide its container path. This follows Node TLS trust configuration.
SAP_URL must be the canonical HTTP(S) origin, such as https://sap.example:443, without a path, query, fragment or embedded credentials. Use HTTPS for SAP credentials. Redirects are rejected so authentication and session cookies cannot be forwarded to another server. Configure the final origin when a reverse proxy redirects requests.
The previously documented TLS_REJECT_UNAUTHORIZED=0 is now an explicit troubleshooting opt-out and emits a warning on stderr; 1 is the default. Previously certificate verification was disabled unconditionally regardless of that setting. A custom CA is the normal way to trust a private certificate; the global NODE_TLS_REJECT_UNAUTHORIZED setting is not used by this server.
SAP_LANGUAGE accepts a two-letter language code, for example EN or de. The SAP client and optional language are sent as query parameters on every ADT/CSRF request. Each request has a 30-second timeout and a 16 MiB response limit; tool calls have a 60-second total deadline and propagate cancellation. Existing returned-text pagination stays bounded at 40,000 UTF-8 bytes. Narrow the query if the upstream response exceeds the download limit.
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.
For a private CA or self-signed server certificate, configure SAP_CA_FILE and verify the certificate hostname matches SAP_URL. HTTP status codes are returned without upstream bodies; inspect the SAP server logs for authentication/authorization details.
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. |
|
|
Run npm ci && npm run check with Node 22 or 24 and OpenSSL available. The credential-free suite covers existing pagination and ADT fallbacks, a local HTTPS server (trust, hostname checks, redirects, limits, cancellation, cookies/CSRF), actual modern/legacy SDK clients and a production-only packed npm installation. CI also builds and starts the Docker image.
The 12 existing live SAP integration tests remain opt-in with RUN_SAP_INTEGRATION=1 and valid SAP configuration. A successful mock/CI run does not establish a customer's ADT service activation, authorizations, release-specific endpoint support or network access. No live SAP system was contacted for this repair.
Retrieve RAP Behavior Definition (BDEF) source code (requires ~NW 7.54 / S/4HANA). For large definitions, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| behavior_definition_name | Yes | Name of the RAP Behavior Definition (e.g. I_MY_ENTITY) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds behavioral value by disclosing that large definitions should be paged and that a minimum NetWeaver version is required, which an agent would not infer from the schema alone.
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?
Two sentences, front-loaded with the core action and resource, followed by a useful paging tip. There is no filler or repetition of schema details.
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 read-only source retrieval tool, the description plus the fully documented input schema is sufficient to call it correctly. It does not describe the output format, but the schema's startLine hint about hasMore partially covers pagination behavior, so nothing critical is missing.
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%, so the input schema already documents all three parameters with types, constraints, and defaults. The description reinforces the paging strategy but does not add new semantic meaning 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 names the exact resource ('RAP Behavior Definition (BDEF) source code') and the action ('Retrieve'), leaving no doubt about what is returned. This object type is clearly distinct from the sibling tools such as GetCDSView, GetFunction, and GetStructure.
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?
It gives a system prerequisite (~NW 7.54 / S/4HANA) and concrete advice to page large definitions with startLine/maxLines. It does not explicitly contrast with sibling tools, but the unique resource type makes the choice obvious, so this is clear context rather than no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve CDS view (DDL source) source code. For large views, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| cds_view_name | Yes | Name of the CDS view (DDL source name, e.g. I_CURRENCY) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about paging and that the tool returns source code, which is useful but not exhaustive. No contradictions with annotations; the description appropriately avoids repeating them.
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?
Two sentences, no fluff. The primary purpose is front-loaded, and the paging guidance is directly actionable. Every word earns its place.
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?
The tool has no output schema, so the description's mention of returning source code provides the essential expected result. Paging behavior is explained. The annotations cover safety and idempotency. For a read-only retrieval tool, this is sufficiently complete for an agent to call it 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 description coverage is 100%, with each parameter already well-documented in the schema. The description reinforces the paging use case for startLine/maxLines but does not add new semantic meaning beyond the schema. Baseline of 3 is appropriate when the schema does 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 verb 'Retrieve' and the resource 'CDS view (DDL source) source code'. It distinguishes from sibling tools by specifying the object type (CDS view), which is unique among the listed retrieval tools. The agent can immediately know what this tool is for.
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?
Provides explicit guidance on paging for large views via startLine/maxLines, which is a concrete usage scenario. It does not explicitly contrast with sibling tools, but the name and description make it clear it is for CDS views, so the agent can infer when to use it. The paging advice adds practical direction beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP class source code. For large classes, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| class_name | Yes | Name of the ABAP class |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining paging behavior for large classes. It doesn't contradict annotations and provides useful behavioral context beyond the 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 two concise sentences, front-loaded with the main purpose and followed by a targeted usage tip. Every sentence earns its place with no redundancy.
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 read-only retrieval tool with robust annotations and full parameter schema, the description covers the essential usage scenario (paging for large classes). It doesn't specify return format, but the lack of an output schema makes that less critical.
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%, so parameters are already documented. The description enhances understanding by linking startLine/maxLines to paging for large classes, which adds practical meaning beyond the raw 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 class source code'), distinguishing it from sibling tools that fetch other ABAP artifacts like functions, tables, or programs. The purpose is specific and unambiguous.
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 a clear usage hint for large classes, advising to page with startLine/maxLines. It doesn't explicitly contrast with alternatives, but the paging guidance is practical and context-specific.
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. For large function modules, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about paging and the byte cap potentially returning fewer lines, which is useful beyond the 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?
Two sentences with no waste. The core purpose is front-loaded, and the paging guidance is concise and actionable.
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 read-only retrieval tool with full schema coverage and no output schema, the description covers the essential usage. The paging behavior is explained, and the annotations cover safety. Minor gap: no mention of what the response format looks like, but that's not required without an output schema.
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 all parameters. The description adds the paging strategy context but doesn't add new parameter semantics beyond what the schema provides. 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 retrieves ABAP Function Module source code, with a specific verb and resource. It distinguishes itself from siblings like GetFunctionGroup and GetProgram by naming the exact artifact type.
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 explicit guidance for large function modules: use startLine/maxLines to page through source. It doesn't explicitly name alternatives or when not to use it, but the paging guidance is clear usage context.
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. For large function groups, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| function_group | Yes | Name of the function module |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: readOnlyHint, idempotentHint, and non-destructive. The description adds useful context about paging large function groups, but the paging semantics (hasMore, byte cap, EOF behavior) are already documented in the schema. It doesn't disclose return format, but none is needed for a straightforward read operation.
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?
Two sentences with no waste: the purpose is stated first, followed by the most important operational guidance about paging. Every sentence earns its place, and nothing in the description duplicates the schema.
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 read-only retrieval tool with full schema coverage and read-only annotations, the description covers the essential usage. It doesn't describe return values, but the absence of an output schema and the obvious nature of 'source code' make this acceptable.
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 all three parameters documented in detail including default startLine and byte cap behavior. The description reinforces the paging use case but doesn't add semantic information beyond what the schema already 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 uses 'Retrieve' as a specific verb and names the exact resource, ABAP Function Group source code. While it doesn't explicitly distinguish itself from siblings like GetFunction or GetProgram, the tool name and resource are unambiguous enough that an agent can identify its target.
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 clear operational guidance on using startLine/maxLines for large function groups. However, it doesn't state when to prefer this tool over alternatives like GetFunction or GetInclude, nor does it mention any exclusions or prerequisites.
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. For large includes, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| include_name | Yes | Name of the ABAP Include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a useful behavioral hint about paging large includes, but it does not disclose details like default line limits, byte caps, or what happens when paging is omitted. It adds some context beyond annotations but not a rich behavioral picture.
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?
Two sentences, no filler. The first sentence states the core purpose; the second provides actionable paging guidance. Every word earns its place.
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?
The tool is a simple read-only retriever, and annotations cover safety. The schema fully documents parameters, and the description gives the key paging context. It is complete enough for correct invocation, though it does not describe return formatting or error behavior explicitly.
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%, so the baseline is 3. The description adds meaning by explaining why startLine and maxLines matter together: they are for paging through large includes. This goes beyond individual parameter descriptions and tells the agent how to combine them effectively.
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 states a specific verb and resource: 'Retrieve ABAP Include Source Code.' It is distinct from sibling tools like GetProgram or GetFunction because it names the exact ABAP object type being retrieved. The paging hint reinforces the purpose without ambiguity.
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 gives clear guidance for large includes: use startLine/maxLines to page instead of retrieving everything at once. It does not explicitly compare GetInclude with sibling tools or state when not to use it, so it falls short of full alternative-selection guidance.
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. For large interfaces, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| interface_name | Yes | Name of the ABAP interface |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description doesn't need to repeat that. It adds a paging recommendation and implies that large responses are possible, but it doesn't describe return format or error behavior. That's acceptable but not rich.
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?
Two sentences with no filler. The core purpose is front-loaded, and the paging guidance is placed immediately after where it's most relevant. Every clause earns its place.
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?
The tool is a straightforward source-retrieval operation with annotations covering the safety profile and schema covering all parameters. The description adds the only missing piece — guidance on paging large interfaces — so an agent has everything needed to invoke it 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 description coverage is 100%, so the description doesn't need to re-document parameters. It does add value by connecting startLine/maxLines to the paging behavior, but it doesn't provide any syntax or format details beyond what the schema already states. 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?
States a specific verb ('Retrieve') and resource ('ABAP interface source code'), making the tool's function immediately clear. The sibling tools are all different object-type retrievers (GetClass, GetTable, etc.), so identifying 'ABAP interface' as the target sufficiently distinguishes this tool from 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?
The description gives a clear usage context: use this when you need ABAP interface source. It also provides an explicit in-tool directive for large interfaces ('use startLine/maxLines to page through the source'), which is actionable guidance. It doesn't name alternative sibling tools, but the object-type split makes exclusion unnecessary.
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. Use startLine/maxLines to page large serialized package listings.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| package_name | Yes | Name of the ABAP package |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing paging behavior for large listings, which is not covered by annotations or schema. No contradiction with 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 two concise sentences with no filler. It front-loads the core purpose and then adds a targeted usage hint. Every word earns its place.
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 a clear resource type, the description covers the essential behavior (retrieve details) and provides paging guidance. The lack of an output schema is acceptable given the tool's simplicity, and annotations cover the safety profile. Minor gaps like error handling or return format are not critical for correct 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?
The input schema has 100% parameter description coverage, so the baseline is 3. The description mentions paging but doesn't add semantic detail beyond what the schema already provides for startLine and maxLines. No additional parameter meaning is introduced.
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 verb 'Retrieve' and the resource 'ABAP package details', which is specific and distinct from sibling tools that target other ABAP object types (e.g., GetFunctionGroup, GetClass). The purpose is unambiguous.
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 concrete guidance on when to use paging parameters ('Use startLine/maxLines to page large serialized package listings'). While it doesn't explicitly contrast with sibling tools, the tool name and resource type make the usage context clear enough for an agent to select it appropriately.
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. For large programs, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| program_name | Yes | Name of the ABAP program |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that paging is available for large programs and suggests retrieving all at once may be problematic, which is useful context beyond annotations. However, it does not describe response format or error behavior, and the added behavioral value is modest.
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?
Two sentences, first states purpose, second gives actionable paging advice. No filler, front-loaded, and every sentence earns its place. Excellent conciseness 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?
With a clear purpose, fully documented parameters in the schema, and annotations covering safety, the description is nearly complete. It could explicitly state that the response contains source lines, but 'Retrieve ABAP program source code' implies that. Nothing critical is missing for an agent to call this tool 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 description coverage is 100%, with startLine and maxLines fully documented (including beyond-EOF behavior and byte cap). The description merely references these parameters for paging without adding new meaning. Baseline 3 is appropriate because the schema carries 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 states 'Retrieve ABAP program source code' with a specific verb and resource. It clearly distinguishes from sibling tools like GetFunction or GetInclude, which target different ABAP objects. No ambiguity about what this tool does.
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 clear guidance on paging for large programs ('For large programs, use startLine/maxLines to page through the source'), which is a usage context. However, it does not mention when to prefer GetProgram over its siblings (e.g., GetFunction, GetInclude), so alternative-selection guidance is absent. The paging advice is useful but not about tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve RAP Service Definition (SRVD) source code (requires ~NW 7.54 / S/4HANA). For large definitions, use startLine/maxLines to page through the source instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| service_definition_name | Yes | Name of the RAP Service Definition (e.g. Z_MY_SERVICE) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description correctly focuses on extra context: the ~NW 7.54 / S/4HANA requirement and the paging strategy for large definitions. It doesn't contradict annotations and adds useful operational behavior beyond what structured fields state.
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 two tight sentences: the first states purpose and prerequisite, the second gives the paging tip. There is no filler or redundant repetition of schema 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 read-only source-code retrieval with three self-describing parameters and no output schema, the description covers purpose, platform requirement, and large-definition handling. It doesn't describe the exact return envelope, but the schema's parameter descriptions and annotations provide enough surrounding context for an agent to call it 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?
The input schema already documents all three parameters thoroughly, including the maxLines cap and the startLine 'Beyond EOF' behavior, so the description doesn't need to repeat parameter details. It adds the strategic advice to page through large definitions, but it does not materially expand individual parameter semantics 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 opens with a specific verb ('Retrieve') and a precise resource ('RAP Service Definition (SRVD) source code'), making the tool's purpose unambiguous. It also differentiates the tool from the sibling Get* tools by naming the exact ABAP object type, SRVD, rather than a generic resource.
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 gives concrete usage context by recommending startLine/maxLines paging for large definitions instead of retrieving everything at once. However, it does not explicitly say when to prefer this tool over related siblings like GetBehaviorDefinition or GetCDSView, leaving tool selection partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve ABAP Structure. For large structures, use startLine/maxLines to page through the result instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| structure_name | Yes | Name of the ABAP Structure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds value by disclosing that large structures can be paged with startLine/maxLines, which is a behavioral trait about result size and iteration, not present in the annotations. It does not contradict any annotation.
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 that front-loads the core purpose ('Retrieve ABAP Structure') and immediately follows with the key usage tip about paging. No wasted words, fully 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?
For a retrieval tool with pagination parameters and no output schema, the description adequately covers the primary concern of handling large results. It does not describe the return format or what a structure contains, but given the schema's detailed parameter docs and the annotations covering safety, it is sufficiently complete for an agent to call it correctly. Minor gaps exist but are not critical.
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 all parameters including their ranges and semantics. The description adds a hint about paging behavior but does not introduce new meaning beyond what the schema's parameter descriptions already provide. 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 states a clear verb ('Retrieve') and resource ('ABAP Structure'), which is specific and distinguishes it from sibling tools like GetTable, GetFunction, etc., without needing to open their schemas. The resource type is unambiguous.
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 mentions paging for large structures, which gives some usage context, but it does not explicitly state when to choose this tool over alternatives or exclude situations. It lacks any direct comparison with sibling tools (e.g., when to use GetStructure vs GetTypeInfo), leaving tool selection to inference from the name.
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. For large tables, use startLine/maxLines to page through the result instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| table_name | Yes | Name of the ABAP table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context that the result can be large and that pagination is available instead of retrieving everything at once. It does not mention output shape or default limits, but those are partially covered by the 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?
Two sentences with a front-loaded purpose statement and a single actionable tip. The second sentence is slightly redundant since 'page through the result' already implies avoiding full retrieval, so it is not a perfect 5.
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 read-only tool with complete parameter schema, the pagination warning is helpful, but the description leaves ambiguity about what 'table structure' returns and never states the default response format. Given no output schema, this is a noticeable 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 description coverage is 100%, so all parameters are already documented. The description only groups startLine/maxLines into a pagination behavior without adding details beyond the schema, so the 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 opens with 'Retrieve ABAP table structure,' naming a specific verb and resource. It does not explicitly distinguish itself from sibling tools like GetTableContents or GetStructure, and the large-table pagination hint slightly muddies whether this returns metadata or row data, so it falls short of 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?
The only usage guidance is a pagination tip for large tables: 'use startLine/maxLines to page through the result instead of retrieving it all at once.' There is no explicit when-to-use vs. alternatives or exclusion statement, so an agent must infer tool selection from the name and first phrase.
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. max_rows limits SAP rows; startLine/maxLines page the returned textual XML when its serialized size is still large.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| max_rows | No | Maximum number of rows to retrieve | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| table_name | Yes | Name of the ABAP table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, but the description adds valuable context: max_rows bounds SAP rows, startLine/maxLines handle XML pagination, and a byte cap may truncate results. This goes beyond the schema by explaining the relationship between the two pagination mechanisms and the serialized-size nuance.
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?
Two focused sentences: the first states the core purpose; the second explains the two limiting parameters in a compact way. No wasted words, and the most important action is front-loaded.
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 read-only data retrieval tool with no output schema, the description covers the essential operational details: what it returns (textual XML), how pagination works, and a caveat about byte caps. It does not mention error handling or prerequisites, but those are not critical for a simple read operation, especially when annotations cover safety.
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%, so parameter names and descriptions already exist. The description adds meaning by clarifying that max_rows refers to SAP rows (not returned XML lines) and that startLine/maxLines apply specifically to the textual XML output when serialization is large. This nuance is not in the schema and improves understanding of how the parameters interact.
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 opens with a precise verb and resource: 'Retrieve contents of an ABAP table.' It immediately distinguishes this tool from sibling tools like GetTable or GetFunctionGroup, which are metadata/definition retrievers. The mention of 'max_rows limits SAP rows' and XML paging further clarifies scope.
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 usage (fetching table data) but does not explicitly state when to prefer this over alternatives, nor when to avoid it. There is no mention of exclusions or alternative tools, leaving the agent to infer from sibling names. Some guidance about the byte-cap behavior is given, but not tool-selection context.
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. For large results, use startLine/maxLines to page through it instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| transaction_name | Yes | Name of the ABAP transaction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by advising pagination for large results, which is useful beyond the annotations. It does not contradict annotations and adds practical usage advice, though it doesn't disclose any other edge cases like rate limits or error behavior. The additional context earns a solid score.
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 two sentences: the first states the purpose, the second gives actionable pagination advice. It is front-loaded with the core function and contains zero filler. Every sentence earns its place, making it an exemplar of concise, effective tool documentation.
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 read-only retrieval tool with no output schema, the description is adequate. It provides the core purpose and the critical pagination guidance. Annotations cover safety and idempotency. It could mention what 'details' include (e.g., fields, structure) but that is a minor omission given the tool's simplicity. Overall, an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (transaction_name, startLine, maxLines) having descriptive text. The description mentions startLine/maxLines for pagination, reinforcing their purpose, but adds no new detail beyond what the schema already provides. Since the schema carries the semantic burden, the description's contribution is marginal, aligning with 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 'Retrieve ABAP transaction details', which is a specific verb and resource. While it doesn't explicitly differentiate from sibling tools like GetFunction or GetTable, the resource type (ABAP transaction) is distinct and the name reinforces the purpose. It's clear enough for an agent to know what it does, though it doesn't explicitly say what 'details' entails.
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 explicit guidance on pagination ('use startLine/maxLines to page through it') for large results, which is helpful. However, it does not give guidance on when to use this tool versus alternatives or when not to use it. Since siblings target different ABAP objects, the usage context is implied but not explicit. The pagination advice is a clear plus, but lacks comparative usage direction.
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. For large results, use startLine/maxLines to page through it instead of retrieving it all at once.
| Name | Required | Description | Default |
|---|---|---|---|
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| type_name | Yes | Name of the ABAP type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds useful context that results can be large and that pagination is available. The schema's maxLines note already covers the byte-cap truncation behavior, and nothing contradicts the 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?
Two sentences with no filler; the first establishes purpose and the second adds a concrete usage tip. The information is front-loaded and every clause earns its place.
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 read-only lookup with one required parameter and a well-documented schema, the description is largely sufficient. The main gaps are the lack of detail about what the returned 'type information' contains and no differentiation from sibling tools, but the current definition still enables a competent agent to invoke it 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 description coverage is 100%, with each parameter already documented, including paging semantics and EOF behavior. The description reinforces the pagination message but does not add parameter-level meaning beyond what the schema already 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 states 'Retrieve ABAP type information', which provides a clear verb and resource. It does not explicitly distinguish it from sibling getters like GetStructure or GetTable, but the 'ABAP type' phrasing narrows the target enough to be recognizable.
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 gives explicit guidance for large results: use startLine/maxLines to page instead of retrieving everything at once. It does not discuss when to choose this tool over alternatives, but the pagination when/when-not guidance is clear and practical.
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. maxResults limits matches; startLine/maxLines page the returned textual XML when its serialized size is still large.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string (use * wildcard for partial match) | |
| maxLines | No | Maximum lines to return (1-100000). Omit to request the rest; the byte cap may return fewer lines. | |
| startLine | No | 1-based line number to start from (default 1). Beyond EOF returns an empty page with hasMore=false. | |
| maxResults | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this tool readOnly, idempotent, and non-destructive, so the description need not repeat safety guarantees. It adds useful behavioral context beyond the annotations: results are returned as 'textual XML' and startLine/maxLines page that XML 'when its serialized size is still large.' This clarifies the response format and pagination behavior.
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 dense sentence with no filler. The main purpose comes first, followed by the two parameter groups that matter for controlling output volume and pagination. Every phrase earns its place.
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?
The schema covers parameters in detail, annotations cover the read-only/idempotent safety profile, and the description covers the otherwise undocumented response shape ('textual XML') and pagination semantics. It does not enumerate the XML contents, but with no output schema and a generic search tool, this is adequate for an agent to call it 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?
The input schema already documents all four parameters thoroughly, so the baseline is 3. The description adds a genuinely useful semantic distinction: maxResults limits the number of matched objects, while startLine/maxLines page the returned textual XML. This is meaningfully more than the individual schema descriptions provide.
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 states a specific action and resource: 'Search for ABAP objects using quick search.' This makes the tool's purpose clear and distinguishes it from the sibling Get* tools, though the differentiation is implicit rather than explicitly stated.
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 generic 'Search for ABAP objects' wording implies this is the right tool when the agent is not targeting one specific object type, but the description does not explicitly say when to use SearchObject instead of the Get* siblings. There are no exclusions or alternative routing conditions, so usage guidance relies on the sibling tool names for context.
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.2.0GetBehaviorDefinitionGetCDSViewGetClassGetFunctionGetFunctionGroupGetIncludeGetInterfaceGetPackageGetProgramGetServiceDefinitionGetStructureGetTableGetTableContentsGetTransactionGetTypeInfoSearchObjectScored across 16 tools
Most tools map clearly to a distinct ABAP object type, and SearchObject is distinct from the Get* retrievers. Mild ambiguity exists among GetStructure, GetTable, and GetTypeInfo, since structure and table type information can overlap conceptually.
All tools follow a consistent VerbObject pattern using capital camelCase (GetFunction, GetClass, SearchObject). The naming is uniform and predictable across the entire set.
Sixteen tools is slightly above the typical 3-15 sweet spot, but ABAP has many distinct object types and each tool targets a specific object, so none feel redundant. The count is reasonable for a read-only ABAP repository browser.
The server provides broad read coverage across source objects, metadata, table contents, and search. The obvious limitation is that it is entirely read-only with no create/update/activate tools, which would be a significant gap if the intended domain is full ABAP ADT development rather than source retrieval.
2,000+ MCP servers read at source level. Know what one does before you connect. Free, no key.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
