An MCP server is a phone line. What matters is who picks up. Most ABAP MCP servers connect an agent to the SAP system itself: they read source, create objects, activate, transport. The Sysparency MCP server connects the agent to something the system cannot tell it: the whole picture of the custom code, with every dependency, every usage counter and every business rule cited to its source line. This article lists the seven tools, the questions each one answers, and what an agent did with them.
Two kinds of ABAP MCP server
The Model Context Protocol is an open standard that lets an agent call tools on a server, whichever client the agent runs in: Claude, ChatGPT, Copilot, VS Code, Codex or a framework of your own. For SAP there are two kinds of server, and an agent needs both.
The first kind talks to the system. SAP's ADT MCP server exposes the ABAP Development Tools: create a class, set its source, activate it, run a syntax check. It is the hand that writes.
The second kind talks about the system. The Sysparency MCP server sits on a knowledge graph that is built deterministically from an export of the custom code, and it only reads. It knows which program writes which table, which transaction is still used, which exit enhances which standard object and what a program does in business terms. It is the eye that understands. An agent that has only the first kind sees one program at a time; an agent that has both sees the system and then changes it.
What the graph holds
The graph is not a copy of the source. It is a model with 26 node types and 57 relationship types, extracted from the export and refreshed on every upload. Programs, classes, function groups and includes are code units; screens, forms, transactions, CDS views, tables and their columns are their own nodes; enhancements, customer exits, modifications and ATC findings hang on the code they touch; business processes and modules group everything from the top; runtime entry points carry the observed usage. The relationships are the questions people ask: calls, reads, updates, selects from, enhances, implemented in, observed starts, affected by.
Every fact carries its source line, so an agent can cite what it found rather than paraphrase it.
The seven tools
| Tool | What the agent asks | Example |
|---|---|---|
| get_neo4j_schema | What does the graph know, and under which names? | Called first, so a query uses real labels and properties instead of guesses. |
| read_neo4j_cypher | Any question about relationships, as a read-only graph query. | Which programs write the booking table, and how often does each one run? |
| search_functional_documentation | Where is a business concept handled, without knowing any Z name? | Where are credit limits checked? Returns screens, tables, exits and programs by their business description. |
| list_abap_objects | What exists, by type, package or name pattern? | All function modules in package ZSD that start with Z_PRICING. |
| read_abap_metadata | What was defined or enhanced that the code alone does not show? | For a BAdI implementation: the standard enhancement spot and the implementing class. For a table: the DDIC fields and types. |
| read_abap_source | What does the code do exactly? | The SELECT, the hard-coded value, the condition in line 112. |
| search_abap_source | Where does a pattern occur across the whole custom code? | Every COMMIT WORK inside a BAdI, grouped by package. |
The order matters. A good agent starts with the schema, asks the graph for relationships and usage, searches the business descriptions when it does not know a name, and reads source last, only where the exact logic decides.
What an agent did with them
In the rebuild of a 25-year-old Dynpro application the agent had two servers: Sysparency MCP to understand, SAP ADT MCP to write. Before it generated anything it asked the graph, and three answers changed the design.
- Eleven applications write the booking table, not just the three dialog programs: a function group inserts and updates, a BAPI group updates, an ALE generator deletes, and 35 RFC-enabled function modules sit on the same tables. A new app that only replaced the dialogs would have been one more writer among many, so the rules went into the business objects instead.
- A check program with usage 0 repaired overnight what the dialogs failed to validate. The rules it applied became validations on save.
- 4,870 display calls against 158 edits. The application is read far more than written, so read mode became the default and editing a deliberate step.
None of this is visible in a single program. All of it is one query away.
Back to standard, with the SAP documentation next to it
The Sysparency server knows the as-is. It does not know what the SAP standard offers today. Connect an SAP documentation MCP server alongside it and the agent can ask both sides: what does this Z program do, and is there a released standard object that does the same? Where the answer is yes, the extension can go back to standard; where it is no, the remaining gap is documented with evidence on both sides. That is how clean core becomes a decision per program rather than a slogan.
Guardrails
- Read-only. All seven tools are declared read-only; write operations in a query are rejected before they reach the database.
- Your code only. The graph holds the customer namespaces, never SAP standard source. Standard objects appear as references, not as code.
- One environment per customer. Graph and server run in a dedicated environment; access goes through Microsoft Entra ID with OAuth bearer tokens validated against your tenant.
- Any client. The server speaks standard MCP over HTTP. The connection dialog sits in the report header: copy the URL, add it to your client, ask.
What it is not
It is not a code generator; that is what the ADT server is for. It is not a chat over source files; the graph is built deterministically, and the same export yields the same graph. And it is not a substitute for a person deciding what to change. It gives the agent, and the person reviewing the agent, the same evidence to decide on.
Getting started
- Open your Sysparency report and copy the MCP URL from the header.
- Add it to your client as a remote MCP server and sign in with your company account.
- Ask the first question: "Which of my programs still run and write table X?" The answer comes with call counts and source lines.
For the whole picture of what an agent can do on that basis, see agentic re-engineering, or book a demo and ask the graph of your own system.