Joule on Marian Zeis Blog

Testing Joule Work Desktop with Microsoft 365, Local Files, and SAP

Wed, 12 Aug 2026 03:00:00 +0200

You have probably seen Joule Work Desktop on LinkedIn by now. Sebastian Steinhaeuser showed how it prepares him for a customer meeting. Philipp Herzig called it the new SAP GUI, with a smile, and demonstrated a workflow across email, a spreadsheet, a Space, and PowerPoint.

Joule Work Desktop is now available to SAP employees after a test with more than 6,000 colleagues. Selected customers can also use it through the Early Adopter Care program on macOS and Windows.

The idea is simple: one desktop application that can combine local files, Microsoft 365, SAP knowledge, business systems, MCP connectors, and skills. That is much more interesting than another small Joule chat window inside one SAP application.

I already built similar setups with LibreChat and Microsoft Copilot Studio. A native application adds direct access to the files and applications people use every day.

Luckily, I was one of the few people who got access to the application and could test the currently available features. So here is my first hands-on experience with what I am allowed to show.

If you prefer to see the complete flow first, here is the 58-second demo video.

The application starts with Conversations. I can add files and select work sources or an external connector from the composer. Tool calls remain visible, and generated files open in their normal desktop application.

Email and calendar integration

I asked the application to prepare me for a meeting. It found the calendar entry, read related email messages, and created a brief with logistics, open points, risks, and questions. The calendar and email steps remained visible, and the answer included source references. For me, this is more useful than a general inbox summary because the message becomes the start of a task.

Local files, OneDrive, and real documents

I can attach Office documents, structured data, text, and images. Files synchronized through OneDrive are also available, so they can be combined with email, calendar, web research, or an external connector.

For the meeting-preparation example, I attached an existing Word template. The application filled the relevant sections and created a new document instead of giving me text to copy manually.

The files still need review, but reviewing a prepared document is often faster than starting with an empty one.

Spaces are more useful than I expected

SAP calls the generated work areas Spaces. They are persistent views that can be reopened without finding the original conversation. The most useful one in my test was a transport backlog based on data from my SAP system. It shows open and empty transports, their owners, and the biggest requests by object count.

This does not replace a proper application or reporting solution. But not every temporary question needs a new Fiori application, and a Space is more useful than a long chat answer.

Connecting the SAP system

The SAP system integration is what can make Joule Work Desktop more than a general desktop agent.

At the moment, the direct SAP business system integration available to me is for SAP S/4HANA Cloud Public Edition. I do not have such a system. My test system is SAP S/4HANA 2023 on-premise.

I therefore added ARC-1, my open-source ADT MCP server. ARC-1 can run locally or as a remote MCP server with OAuth, for example on SAP BTP Cloud Foundry.

I could then read transports, inspect ABAP objects, analyze custom code, check ATC findings, or compare a specification with what actually exists in the system.

The connector still needs valid authentication, and SAP user authorizations still apply. I would start with a development system and read-only access.

Connectors and one-click skills

Joule Work Desktop supports MCP connectors and skills, so SAP does not have to build every integration and workflow itself. The SAP AI Skills Library contains reusable skills that can be imported into Joule Work Desktop with one click.

The skill page shows the repository, license, trust level, and checks before installation. The SAP Fiori Guidelines skill, for example, can be added through the Add to Joule Work Desktop button.

MCP servers provide tools, while skills describe how the agent should use them and what it should verify. This keeps the application extendable without adding every possible SAP feature to the desktop client.

The open questions are broader SAP system support, connector governance, and pricing. Anything about future announcements or TechEd is still only speculation.

Something is strange

Anyone who already works with Joule Work Desktop may have noticed something by now.

Some details in my video and screenshots do not look exactly like the application SAP installed. The interface is very close, the workflows work, and the features are there, but a few things are just slightly different.

There is a simple reason for that.

I do not have access to Joule Work Desktop.

The screenshots and video in this post do not show an SAP application. They show an application I built myself.

After watching the public demos, I wanted to see how difficult it would be to rebuild the same core idea with open-source components. I spent roughly a day or two vibe coding it with Codex. The result is called Werkbank.

Werkbank is the German word for workbench, a place where different tools come together to get work done.

The current interface follows the public Joule Work Desktop videos closely because I wanted to reproduce the workflows shown there. But there is no internal SAP code behind it, I had no access to a Joule Work Desktop build, and I have no additional product information beyond public posts and videos.

What is actually inside Werkbank

Werkbank is a working MVP, not a static mock or a prerecorded animation. It can hold real streaming conversations, call tools, ask for permissions, and stop a running task. The agent behind it is goose, an open-source AI agent hosted by the Agentic AI Foundation. Werkbank communicates with Goose through the Agent Client Protocol.

The implemented features currently include:

Local active and archived conversations.
Word, PowerPoint, text, CSV, JSON, and image attachments, including files synchronized through OneDrive.
Generated Word and PowerPoint files that can be opened in the normal desktop application.
Persistent Spaces stored as sandboxed HTML views.
Live read-only Microsoft 365 email and calendar access.
Session-scoped MCP connectors, remote MCP OAuth through Goose, and reusable skills selected with /.

The demo uses these features rather than special video fixtures. The meeting brief comes from live calendar and email calls, the Word output is a real file, ARC-1 reads my SAP system, and the transport Space is generated from those results. The shipment-defect workflow uses an attached synthetic CSV file and creates a real Space and PowerPoint presentation.

For SAP, Werkbank uses the same MCP servers I can use from Claude Desktop, Codex, VS Code, LibreChat, or Copilot Studio. ARC-1 connects to the ABAP system. Connector secrets are stored through the operating system’s secure storage instead of being written into the normal configuration.

The project website is getwerkbank.com, and the source is in the public Werkbank repository. Development currently targets macOS, and there is no signed installer yet.

The Werkbank App Store

getwerkbank.com is not only a landing page. Its App Store already works with the desktop application, and I can use it to add both MCP servers and skills to Werkbank.

The small curated catalog currently contains nine entries: three MCP servers and six SAP development skills. I can search it, filter by type, inspect the original source, and then click Add to Werkbank or Add skill.

The website validates the request and opens the local application through a werkbank:// link. Werkbank then shows the connector command and configuration fields, or the skill repository and name. Nothing is installed until I confirm it inside the desktop application. After that, a connector is restarted and becomes available to the conversation, while an installed skill appears in the / picker.

The same flow can be linked from any project README with an Add to Werkbank button. Here is the skill used in the video:

Add the SAP Fiori Guidelines skill to Werkbank

To try it, clone the repository, run npm install, copy .env.example to .env, add the model configuration, and start it with npm run dev.

What this little experiment shows

Werkbank is not a replacement for Joule Work Desktop. It is a small MVP built in roughly two days, with bugs and much narrower workflows. But it is already a usable desktop application: I can chat with it, attach files, connect tools, install skills, and return to earlier conversations and Spaces.

SAP also has to solve the difficult enterprise parts: identity, authorizations, data protection, auditing, deployment, updates, model governance, and reliable operation for many users and systems. A local MVP does not solve these problems just because the demo looks similar. With more time, I could add SSO, authentication against IAS, a release pipeline with signed builds, automatic updates, and more enterprise controls. That was not the main point of this experiment.

But the experiment still shows something useful. The core workflows SAP currently demonstrates are already possible with open-source components:

Read email and calendar context.
Work with local files and OneDrive-synchronized files.
Analyze structured data.
Create persistent dashboards.
Generate real Word and PowerPoint files.
Connect SAP documentation and SAP systems through MCP.
Add reusable skills and new connectors.

Goose is only one possible base. LibreChat can provide a similar experience in the browser. Microsoft Copilot Studio can combine Microsoft 365 connectors and MCP servers. Claude Desktop can also work with local files, connectors, and skills. The individual building blocks already exist.

The real value of Joule Work Desktop will therefore not come only from having these features. It will come from how well SAP connects them to business context, SAP authorizations, supported applications, and real processes. It will also depend on how accessible it is. Are Signavio, LeanIX, or SAP S/4HANA Cloud Public Edition required? Can a customer use it with only on-premise systems? And what will it cost?

For now, I am impressed by the direction. I just could not test the real application yet, so I built the part I wanted to test myself.

Disclosure: Werkbank is an independent open-source project and is not affiliated with or endorsed by SAP. SAP, Joule, ABAP, SAP Fiori, SAP S/4HANA, and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP SE or its affiliates in Germany and other countries.

References and links

ARC-1 with Joule Studio: Bringing Real ABAP System Context into Joule

Wed, 06 May 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the previous post, I showed ARC-1 with Microsoft Copilot Studio. The idea was that SAP system context should not be locked inside a local IDE. If ARC-1 runs centrally on SAP BTP, it can also be used from Teams, Microsoft 365 Copilot, SharePoint, Jira, and other places where functional consultants, architects, support teams, and project leads already work.

This post is the SAP-native version of that idea. If Microsoft Copilot Studio is close to the Microsoft workday, then Joule is close to the SAP workday. SAP describes Joule as the unified assistant experience across SAP’s solution portfolio, and Joule Studio as the place to build custom Joule agents with SAP and non-SAP integrations.

So the question is not only: can Joule call another MCP server? The better question is: can the ARC-1 capabilities be brought to the place where SAP users already ask questions?

What Carries Over From Earlier Posts

ARC-1 is a secure ADT MCP server for ABAP systems. It connects AI clients to SAP systems through ABAP Development Tools APIs and exposes this through tools like SAPRead, SAPSearch, SAPWrite, SAPActivate, SAPContext, SAPDiagnose, SAPTransport, and SAPManage.

For this post, the important part is not the full tool list. It is the operating model from the earlier BTP post:

central server instead of every user laptop
safe by default instead of allow all by default
server ceiling + user permission + SAP authorization
audit logging instead of invisible local tool calls

In the BTP post, I described how ARC-1 can run as a central Cloud Foundry application with XSUAA, BTP destinations, Cloud Connector, Principal Propagation, roles, and BTP audit logging. For Joule Studio, I would not create a second SAP access architecture. I would reuse that controlled endpoint.

What ARC-1 Adds To Joule

Joule already has useful SAP context. SAP has Joule for Developers, Joule for Developers, ABAP AI capabilities, and Joule for Consultants. So this is not about pretending Joule cannot help with ABAP at all.

But there is a difference between a useful standard assistant and a tool that can query my actual ABAP system through ADT, read my custom code, inspect dependencies, run diagnostics, check release state, read ATC findings, and create a system-specific proposal.

That workflow is not something I get just by opening standard Joule. If SAP does not expose this level of ABAP system access in Joule today, a custom MCP server can still bring it there. With ARC-1, Joule is no longer limited to general SAP knowledge or predefined product capabilities. It can ask the real ABAP system.

Not because the model became smarter. Because the tool access became better.

That matters beyond pure development. The same ADT-backed context can help architects with Clean Core planning, functional consultants with impact analysis, support teams with dumps and bug analysis, quality leads with ATC reporting, and developers with implementation proposals.

The Architecture I Would Show

SAP’s Architecture Center describes A2A and MCP for interoperability. The important part for this post is the direction: Joule as the user-facing assistant, A2A for agent-to-agent collaboration, and MCP for tool access. SAP also describes an MCP Gateway in SAP Integration Suite as a governed way to expose SAP and non-SAP APIs, integrations, data sources, and external MCP servers as tools for AI agents.

ARC-1 fits that pattern as the ADT development-tooling adapter:

User in Joule
  -> Joule Studio Agent
  -> SAP Integration Suite API Management / future MCP Gateway
  -> ARC-1 on SAP BTP Cloud Foundry
  -> Destination Service + Connectivity Service
  -> SAP Cloud Connector
  -> SAP S/4HANA or ABAP system
  -> ADT development APIs

ARC-1 can fit the architecture pattern SAP describes. Joule is the user-facing AI entry point, Integration Suite is the governed access layer, ARC-1 is the ADT adapter, and the SAP system stays protected behind BTP connectivity and SAP authorizations.

There are still open points. Joule Studio already supports adding MCP servers through BTP destinations, but the documentation also lists restrictions: the destination must be streamable HTTP and MCP servers requiring interactive OAuth user authorization are not supported. SAP also shows MCP hub capabilities on the roadmap, but from what I can see this is still a future SAP Build capability and not the fully available enterprise MCP hub today.

So I would present this as a target architecture and showcase, not as a final productive setup guide yet.

For the showcase, I configured a Joule Studio agent with a small instruction set, Anthropic Claude Sonnet 4 as model, and two MCP servers: ARC-1 for the ABAP system and the SAP Docs MCP Server for official SAP documentation context. I condensed the screenshots here to show only the relevant configuration parts:

Use Cases I Would Show In This Post

I would not repeat all Copilot Studio examples. The Joule post should show scenarios that make sense because the user starts inside the SAP world, not in Teams or SharePoint.

One note before the screenshots: I was not able to change the language in this Joule setup, so the screenshots are in German. I describe the important parts in English below each screenshot.

The first task for the agent is a Clean Core readiness check for one object. It is narrow enough to be understandable and safe enough because it can be read-only:

Check whether ZCL_ARC1_DEMO_CCORE is clean-core ready.
Use the real SAP system, ATC where possible, API release state, and SAP documentation.
Do not change anything. Return risks, evidence, and suggested next steps.

This is a good first agent task because it shows the difference between “Joule explains Clean Core” and “Joule analyzes this class in this SAP system for Clean Core risk”. ARC-1 reads the ABAP source, dependencies, ATC findings, and API_STATE. mcp-sap-docs adds SAP guidance and released API context. Joule returns a short assessment with evidence.

This is the kind of result I mean:

The screenshot is still a rough showcase, but it already shows the value. Joule is not only giving generic Clean Core advice. It can show that the class is not released for the relevant contracts, that it uses USR02 and BUT000, and that there are no ATC findings in this small example. That is a much better starting point for an architect or developer than a general explanation of what Clean Core means.

I also asked a follow-up prompt for a dependency diagram. The result was almost the answer I wanted: not perfect, but useful because it returned a Mermaid diagram and an evidence table instead of only prose. You can open the translated and rendered full Joule reply here.

The second use case is package-level modernization planning. This is where an agent is useful because it needs multiple tool calls, grouping, prioritization, and a bit more reasoning:

Analyze package ZSD_LEGACY for Clean Core and ABAP Cloud risks.
Group the findings and create a modernization backlog.
Do not change code.

The same agent can combine ARC-1 for package content, dependencies, ATC, release state, and where-used information with SAP documentation for official guidance. The output should be a backlog, not a “fixed everything” claim:

Priority 1: direct SAP table usage with released successors
Priority 2: ATC findings with clear fix direction
Priority 3: objects that need architecture discussion
Priority 4: probably dead or low-value code to review later

This screenshot shows another interesting part of Joule. The response is not only a long text answer. Joule created a left-side list with grouped findings and backlog items, and the selected item is shown with details on the right side:

In this run, the package ZSD_LEGACY did not exist. Joule still searched the system and found 28 ZSD* objects that may represent legacy risks. It grouped them into high, medium, and low risk buckets, and then created a modernization backlog. The selected high-risk card shows temporary $TMP package objects, split into service definitions, tables, and message classes. That is not a final assessment, but it is a useful interactive starting point.

These examples have a better through line for this post than repeating the Copilot Studio demos. Copilot Studio is good when the work starts in Microsoft 365. Joule Studio is good when the work starts in SAP, but still needs real ABAP system context.

Why I Use An Agent Here

For this showcase an agent is perfectly fine. The interesting part is not the packaging. The interesting part is that Joule can call ARC-1 and the SAP Docs MCP Server, collect system evidence, and turn that into something useful for the user.

For ARC-1 I would still keep the first Joule Studio agent conservative: one object or one package, read-only by default, no automatic rewrite. I would not start with a big automation story. I would start with analysis, evidence, and a proposal.

And yes, you can also vibe code with this. If write access is enabled for a development or sandbox system, a Joule Studio agent can propose changes and call ARC-1 to apply them. I just do not want this to be the main story here, because the more important point is the architecture: first give Joule controlled access to real ABAP system context, then decide which write actions are safe enough.

Open Points

The SAP API Policy also matters here, but it should not become the whole post. ARC-1 should be positioned as ADT development tooling, not as a generic business-data extraction layer. Clean Core checks, ATC, code inspection, syntax checks, ABAP Unit, activation, and development support are the story. Data extraction is not the story.

This is also why the Joule Studio architecture is interesting. SAP’s architecture guidance describes SAP Integration Suite and API Management as part of a governed pathway for AI agents, including a governance layer like an MCP gateway in front of APIs. That is much closer to the setup in this post than a local MCP server on a developer laptop. It gives the agent a controlled entry point, central configuration, identity, monitoring, and auditability. It does not mean every possible ADT usage is automatically fine, but the architecture shape is much closer to what SAP is describing for API agents.

Why This Matters

Copilot Studio and Joule Studio are different surfaces:

Copilot Studio = close to Teams, Microsoft 365, SharePoint, Excel, Word, Jira
Joule Studio = close to SAP products, SAP Build, Joule agents, SAP users
ARC-1 = governed ABAP system access layer that can serve both

The client can change, but the security model should not. For me that is the main point. ARC-1 should not be locked to Claude, Cursor, Copilot Studio, or Joule Studio. If the company allows it, the same governed ARC-1 endpoint should be usable from different AI clients.

And ARC-1 is open source, which is important to me. If this kind of access layer becomes part of SAP AI architectures, then people should be able to inspect how it works, challenge the security model, test it against real systems, and decide for themselves if it fits their landscape.

Also, this does not have to start with write access. Even read-only mode is already very powerful. Reading code, dependencies, ATC findings, release state, dumps, messages, packages, and where-used information can help architects, consultants, support teams, and developers without the assistant writing a single line of ABAP.

The target picture is not “AI writes ABAP from a chat prompt”. The better target is:

the user asks inside Joule
Joule has access to the right tools
ARC-1 provides real ABAP system context
SAP documentation provides the official direction
Integration Suite provides governance
SAP authorizations still protect the backend
humans approve the risky parts

That is much more interesting than a local MCP demo. It is also much closer to what I think enterprise ABAP agentic development needs.

Discuss this post

References & links

Supercharged Local Open Source Joule for Consultants: Search Your Data & Code

Wed, 29 Oct 2025 09:30:00 +0100

This post is a mirrored copy of my LinkedIn article, kept here so it remains searchable and independent from external platforms. You can still find the original on LinkedIn: LinkedIn Pulse article.

Joule for Consultants costs 250 € and mainly searches SAP Help, SAP Community and SAP for Me (Notes). That is useful, but it stops where real projects start: your own systems, codebase and sensitive data. Even though public assistants like ChatGPT and Claude can already reach SAP Help and SAP Community, the real gap is internal/authenticated data and code.

For this case I created a LibreChat fork that includes and auto-starts SAP MCP servers (Docs, Notes, S/4 OData and ABAP ADT) via Docker. So the MCP Server are local inside your Docker and no external MCP Server is used. LibreChat is an open‑source local chat UI with MCP support and built‑in Ollama integration, and it also supports many other model providers. You get a private assistant that can read official docs, inspect code and data from your systems without sending customer context to third‑party clouds. The fork’s documentation is here: sap‑mcp‑docs.

Running the assistant locally means the client, tools and, if you choose, the model stay on your machine (LibreChat supports Ollama), so you avoid pasting sensitive context into public chats. By adding S/4 OData and ABAP ADT, you bring real metadata, code and data into the loop.

Which MCP servers are used here?

The SAP Docs MCP provides unified search and fetch across SAPUI5/OpenUI5, CAP, ABAP keyword docs, SAP Help and SAP Community. The SAP Notes MCP is for searching and fetching SAP Notes when you have an error, OSS number or concrete symptom; it requires an S‑User certificate (Passport). The ABAP ADT MCP reads ABAP sources, DDIC structures and tables content via ADT APIs so you never paste code into chat and still get precise context. The S/4 OData MCP discovers services and exposes safe CRUD tools so your assistant can read and write via approved APIs.

How this works in practice

In my example I used o4‑mini from OpenAI, but LibreChat supports many model providers including OpenAI, Anthropic, Google, Azure AI Foundry and even SAP AI Core (not tested by me). The key point: you can also use a local model via Ollama. Depending on your use case, a local model is smart enough to call the right tools and MCP servers. I also use an ABAP Cloud Developer Trial instance connected via the S/4 OData and ADT MCP servers.

SAP Notes lookup + ABAP table verification

This first example flow combines the SAP Notes MCP and ABAP ADT MCP. First the assistant searches and fetches a specific SAP Note (sap_note_search, sap_note_get), then verifies the relevant DDIC table and fields via ADT. This confirms the symptom and the fix steps before proposing a safe, auditable corrective action (for example, an OData action). This is the pattern for many “error → note → verify → fix” tasks.

Service metadata + ValueList guidance

The assistant uses the S/4 MCP to discover the Football service and inspect entity schema (search-sap-services, discover-service-entities, get-entity-schema). It then pivots to the SAP Docs MCP to sap_help_search and sap_help_get the ValueList documentation and shows exactly where to add annotations. This marries live service metadata with the official docs so consultants can implement confidently, then validate in a Fiori app.

CDS view Value Help research

For CDS‑centric cases, the assistant focuses on SAP Docs MCP to collect the canonical examples for Common.ValueList and relevant ABAP/CDS annotations. If needed, ABAP ADT MCP can retrieve the current CDS definition (GetStructure/GetInclude) to compare the as‑is state and generate the minimal edit plan.

Other options and clients

There are other options and clients to use these MCP servers. If you prefer the Microsoft ecosystem, Visual Studio Code’s GitHub Copilot Chat supports MCP servers so you can connect the same SAP MCP endpoints there, as described in the VS Code Copilot Chat MCP guide. This is a simpler setup compared to the LibreChat fork. For a more governed setup you can use Copilot Studio together with the hosted S/4 OData MCP server from Nessi NV and the SAP Docs MCP Server.

I talked about these MCP servers and showed a live example of Copilot Studio and other LLM clients at SAP Inside Track Munich 2025. The recording is here: SAP Inside Track Munich 2025.

You can also build your own LLM client and use the MCP servers directly. I tried a quick PoC with the current libraries and tools. It worked, but turning it into a production‑ready assistant with robust MCP support is non‑trivial; I would not recommend rolling your own for production. The PoC is here: Custom LLM Client.

Getting started

To run this on your own machine, clone the repository, configure the .env and librechat.yaml files and start the Docker container. The docs are in this folder and the setup guide is here: MCP_SETUP_GUIDE.md.

Minimal path (see guides for details):

# Clone and configure
git clone https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat
cd local-llm-client-for-sap-consultants-librechat
cp .env.example .env
cp librechat.example.yaml librechat.yaml

# Configure the .env and librechat.yaml files

# Start in Docker
docker compose up -d

Security: running AI and MCP locally

Because the client, MCP server and (optionally) the model run on your machine, prompts, retrieved docs and tool results stay inside your environment. When you do connect to external sources, do it intentionally and stick to trusted endpoints. Operationally keep it simple and start read-only by default and enable write tools only when you require it. The short version: a local, open-source stack is the safer option here; unlike cloud assistants, your information never leaves your machine unless you choose to send it.

Conclusion

With MCP servers, LLM clients become smarter and more useful in real projects. LLMs simply cannot know everything, especially internal context that lives on enterprise networks and changes quickly. Because the Model Context Protocol is still relatively new in the enterprise, treat adoption with care and integrate it securely. Keeping information on your own machine and using open-source libraries lets you see exactly what runs and how.

SAP clearly wants to position Joule for Consultants as a unique product; today it still lags behind community projects for these use cases. At TechEd next week we’ll see whether community MCP servers are embraced and whether SAP’s own products improve enough to justify the price.

References

Custom LLM Client PoC: https://github.com/marianfoo/custom-llm-client
SAP Inside Track Munich 2025 session: https://www.youtube.com/watch?v=vTZCeaxsOwU
SAP partner listing (S/4 integration via OAuth): https://www.sap.com/products/artificial-intelligence/partners/nessi-nv-ai-data-enabler.html?countryCode=US
MCP clients overview (Claude Desktop etc.): https://modelcontextprotocol.io/clients/
Copilot Studio: https://adoption.microsoft.com/ai-agents/copilot-studio/
VS Code Copilot Chat MCP docs: https://code.visualstudio.com/docs/copilot/chat/mcp-servers
CAP MCP server (official): https://github.com/cap-js/mcp-server
CAP MCP plugin (community): https://github.com/gavdilabs/cap-mcp-plugin
S/4 OData MCP: https://github.com/lemaiwo/btp-sap-odata-to-mcp-server
ABAP ADT MCP: https://github.com/mario-andreschak/mcp-abap-adt
SAP Notes MCP: https://github.com/marianfoo/mcp-sap-notes
SAP Docs MCP: https://github.com/marianfoo/mcp-sap-docs
LibreChat Ollama guide: https://www.librechat.ai/blog/2024-03-02_ollama#getting-started-with-ollama
LibreChat model providers: https://www.librechat.ai/docs/configuration/pre_configured_ai
LibreChat website: https://www.librechat.ai/
LibreChat fork setup guide: https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat/blob/main/sap-mcp-docs/MCP_SETUP_GUIDE.md
LibreChat fork docs folder: https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat/tree/main/sap-mcp-docs
LibreChat fork (SAP consultants, with MCP servers): https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat