mcp-abap-adt

GetAbapSystemSymbols

Resolve ABAP symbols from source code using semantic analysis to return types, scopes, descriptions, and packages from your SAP system. Use it to identify what each symbol means before changing code.

Instructions

[read-only] Resolve ABAP symbols from semantic analysis with SAP system information including types, scopes, descriptions, and packages. Runs on an ABAP session of its own. Optional timeout (seconds): when it passes, the read is cancelled, its ABAP session logged off, and the system stays as it was. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a client's cancel ends only the client's wait, and SAP runs the read on. Runs outside batch mode.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "GetAbapSystemSymbols"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes	ABAP source code to analyze and resolve symbols for
`timeout`	No	Seconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv20.1.0Oct 24, 2026

addedInput schema / properties / timeout

Added value: +{
+  "description": "Seconds to wait for the answer: a whole number, at least 1, no default — without it the call waits until SAP answers. When it passes, the read is cancelled (its ABAP session is logged off) and the call answers that nothing was changed. Set it below your MCP client's request limit — the TypeScript SDK's client cancels at 60 s; a cancel does nothing to SAP.",
+  "maximum": 2147483,
+  "minimum": 1,
+  "type": "integer"
+}

Changed1 schema field changedv6.11.0May 28, 2026

removedInput schema / properties / filePath

Removed value: -{
-  "description": "Optional file path to write the result to",
-  "type": "string"
-}

First observedDec 29, 2025

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does so strongly: it declares read-only behavior, states that it runs on a dedicated ABAP session, explains that timeout cancels the read and logs off the session while leaving the system unchanged, and clarifies that a client-side cancel only ends the client's wait while SAP continues. It also notes it runs outside batch mode. What it does not cover is error behavior or response shape.

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

Conciseness4/5

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

The description is front-loaded with a bracketed read-only marker followed immediately by purpose, then moves to session/timeout behavior. It is generally efficient, though the timeout explanation is lengthy and overlaps with the schema's timeout description, adding some redundancy.

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

Completeness4/5

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

For a tool with no annotations and no output schema, the definition covers the operationally critical facts: read-only nature, dedicated session, timeout cancellation semantics, logoff behavior, client-vs-SAP cancellation distinction, and batch-mode exclusion. It is less complete on sibling differentiation and on error or prerequisite behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema descriptions for both 'code' and 'timeout' are already detailed, including the client-cancel nuance. The description adds little parameter-specific detail beyond restating that resolution acts on ABAP source and that timeout is optional; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Resolve ABAP symbols') and enumerates the returned content (types, scopes, descriptions, packages). However, it does not distinguish this tool from closely related siblings such as GetAbapSemanticAnalysis, GetAbapAST, or GetTypeInfo, leaving the agent to infer the boundary.

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

Usage Guidelines3/5

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

Usage is implied by 'from semantic analysis with SAP system information', suggesting it should be chosen when system-level metadata is needed alongside symbols. But there is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer selection among semantic-analysis siblings.

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

Deploy Server