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, Codex CLI or Copilot query what your SAP system actually does — feature map, processes, custom developments, findings and knowledge base — and write back what they got done. 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.
Results that go nowhere
What the session worked out stays in the session. The next agent — or the same one tomorrow — starts from zero again.
What it asks Conjola 01 02 03 04
A few coarse tools that answer a business question — not a mapping of eighty endpoints.
Where does this live?
Search across business areas, capabilities, features and processes. The agent finds the functional home of a topic before it opens the first file.
What hangs off it?
Feature detail with custom logic, linked process steps, usage per company code, and the custom developments that overbuild the standard.
What has been written about it?
Functional specs, system documentation and decision papers from the knowledge base — versioned, linked to the same objects.
What is open?
Findings on capabilities, features and feature details: what somebody flagged, what nobody has answered, how long it has been sitting there.
What it writes back
The access is not one-way. Otherwise the knowledge base goes stale at exactly the moment it is used most.
Answer and close findings
A finding that has been dealt with is recorded as dealt with — with a reason, from the context in which the work happened. Not three days later from memory.
Attach insight to the object
What became clear about a feature during implementation ends up on that feature. Documentation grows as a by-product of the work instead of as an afterthought.
Write in the knowledge base
Carry functional specs and system documentation forward — versioned, with inline diff and restore like every other change. Nothing happens quietly.
Every write is in the log
Issuing, revoking and every writing call land in the tenant audit log — with the user the token belongs to. No service account with nobody behind it.
On your terms, not the model's
Letting a model read your system data is a decision, not an installation. So five 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 row-level policies. What a user may not see, their agent does not see either.
The tenant is fixed to the token
Tenant and landscape are set at issuing time and immutable afterwards. The model cannot choose them because it cannot name them — a call that carried a tenant along changes nothing about the answer.
Read-only by default
Every token carries a cap on the effective permission level, defaulting to read. The cap can only lower, never raise — and administrative functions stay closed to token sessions entirely.
The tenant enables it
Not the individual user: only once tenant administration opens MCP access can anyone issue a token. Without it, every request gets a reasoned refusal — never a silent empty result.
Custom 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.
Set up in three lines
One server, no client-specific detour. The config file has a different name everywhere; the pattern is the same.
Issue a token
In Conjola, for one tenant and one landscape. Hard expiry, revocable at any time, last use visible.
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.
What one finds out, everyone knows
The value is not that one agent gets smarter, but that it writes onto a surface everybody sees. What your colleague clarified about a feature yesterday, your agent finds waiting today. Without that shared place, ten developers work out the same thing ten times and none of it adds up.
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 document data into a basis for decisions.
Book a demo