Context by searching
With no source of knowledge, the agent reads through directories until it believes it has enough. That burns runtime, fills the context window with noise, and regularly lands on the second-best file.
MCP access
Your AI agent works with your system knowledge
Conjola ships an MCP server. Claude Code and other MCP-capable coding agents use it to query what your SAP system actually does — feature map, custom developments, data model and knowledge base. Instead of assembling context from tickets and source code, the agent asks a question.
Why your agent is guessing today
A language model asked to implement an SAP change has no model of your landscape. It has files.
Documentation it cannot find
What a feature means in your house, which special logic hangs off it, why a Z program exists — that lives in Confluence, in a ticket, or in nobody's head. For the agent it does not exist.
Source code without meaning
Even when it finds the right report, it sees code — not which capability it serves, what it was built for, or which tables stand behind it functionally.
What it asks Conjola 01 02 03 04
Five coarse tools that answer a business question — not a mapping of eighty endpoints.
What is there?
Which modules are readable in the current landscape and how much they hold. The starting point before the agent reads into anything.
overview Where does it live, and what is written about it?
Search across titles and texts — feature map, custom developments, knowledge base — then read the hit in full. The agent finds the functional home of a topic before it opens the first file.
search · read What does the table look like?
Table and fields from the extracted SAP data catalog: description, data type, length, key field. From your system, not from the model's memory.
catalog_lookup Where is it used?
Where a table field or term appears in the source code of your custom developments — per object with line numbers, an excerpt only if your tenant allows it.
source_search Read-only, by design
The access reads. It changes nothing in Conjola and certainly nothing in your SAP system. Writing back — say, attaching what became clear during implementation to a feature — is the next step and in development.
On your terms, not the model's
Letting a model read your system data is a decision, not an installation. So these boundaries do not depend on the client behaving — they sit in the access itself.
The token is a session
No second way into the application: the same chain of licence, role and record check as in the browser, the same tenant isolation. What a user may not see, their agent does not see either.
Tenant and landscape are fixed to the token
Both are set at issuing time and immutable afterwards. The model cannot choose them because it cannot name them.
Read-only, 90 days at most
Every token is read-only and expires after 90 days at the latest. It can be revoked at any time.
The tenant enables it
Not the individual user: only once tenant administration opens MCP access can anyone issue a token.
Source code is its own switch
Whether source code of your custom developments may leave through this access is your decision at tenant level — separate from enabling the access itself. If you want the feature map open and the code kept in, that is exactly what you get.
What matters is in the log
Issuing, revoking and every delivery of source code land in the tenant audit log — with the user the token belongs to. No service account with nobody behind it.
Set up in three lines
One server following the MCP standard, no client-specific detour. There is a guide for Claude Code; other MCP-capable clients such as Codex CLI or GitHub Copilot connect through the same standard.
Issue a token
In Conjola, for one tenant and one landscape. Read-only, valid for at most 90 days, revocable at any time.
Register the server
One entry in your client's MCP configuration — with Claude Code, the project's .mcp.json.
Token from the environment
Not in the file, but from an environment variable. The configuration may go into the repository; the secret may not.
One source for every agent
The value is not that one agent gets smarter, but that all of them read from the same source. What your team has captured in the feature map and knowledge base, every agent finds waiting — instead of ten developers working out the same thing ten times.
For consultancies
Five transformation projects, five tenants, one machine: with every access loaded at once, “compare customer A with customer B” becomes answerable — each individual call cleanly scoped, the question answerable anyway. Hence the recommendation of one server per working directory: while you work in customer A's project, customer B does not exist in that session. This does not protect our tenant isolation — that holds one layer down regardless — it protects your separation duty towards your own clients.
More for consultants →And if we hook the agent into the system?
Your call — and no contradiction to this access. An agent on the system gains reach: it can read everything, so it reads everything. What that does not give it is orientation. Having both is the normal case: one source for access, one for meaning. Conjola itself stays detached — the analysis runs exclusively on your extracts, with no live access and no way back.
AI on the SAP system: attached vs. detached →Ready to understand your SAP landscape?
In a short demo we'll show you how Conjola turns your system data into a basis for decisions.
Book a demo