SAP's ABAP MCP Server exposes RFC execution to outside agents through one bearer-token endpoint

The best available account of the server is a practitioner's guide on dev.to ^[1]. On that account, a call works like this. The agent opens an HTTP/S connection to /mcp, presents a bearer token, and invokes one of a fixed set of tools ^[4]. Each tool has a JSON input and output schema ^[3]. The guide says every action passes through those predefined tools and their specific authorizations, so the agent never gets an open session on the system ^[6]. Generated code is still compiled and executed on the AS ABAP, and the server runs beside ADT without replacing it ^[15]. The guide does not quote SAP documentation, so its tool descriptions are one team's reading of the release.

Transports are where the guide disagrees with itself. Its tool list includes activating transport requests ^[3]. Further down, it says agents can suggest or prepare transports but that activation still goes through standard channels ^[17]. Then it warns about granting Claude the transport_activate tool while restricting Copilot ^[11]. A tool cannot be both available and out of reach in the same deployment. Before any token gets transport_activate, someone should call it on a sandbox and check whether a transport actually moves.

The permission boundary is the token. According to the guide, the server treats every MCP client the same and enforces identical tool permissions and audit trails whichever agent connects ^[10]. Each agent gets its own bearer token, and the guide says to treat those like service accounts: rotate them and scope them to the minimum ^[12]. I think this is the right design. An RFC-capable bearer token is a service account that happens to take instructions from a language model, and S/4 basis teams already have processes for governing service accounts. The guide's author wrote, "You'll spend more time defining what agents can do than worrying about which agent is doing it." ^[16]

IDE choice depends on the codebase. Eclipse ADT has full MCP tool coverage for classic objects, with limited but growing support for CDS views and AMDP methods ^[7]. VS Code ADT is RAP-first, and its support for function modules and classic reports trails Eclipse ^[8]. Both IDEs can run against the same MCP server ^[9]. A team that mostly maintains procedural ABAP keeps Eclipse for this work.

The guide's subtitle promises to keep adoption within an AI Units budget ^[14]. Its text does not include unit prices or say which tool calls consume units. The operating cost it does describe is load. Several agents sending resource requests at once can push up response times, and the guide tells teams to watch ADT server logs for MCP-related latency ^[13]. Agents use the read-only resources, such as table structures and CDS view definitions, to gather context before generating code ^[5]. Agents that pull a lot of context are the ones to look for in those logs.