CAP MCP and Agentic Workflow with LangGraph and Fiori

Introduction

CAP applications are usually created to expose business data and processes through OData services. This is still the main goal of CAP, but now there are new possibilities available for the same business service.

With MCP (Model Context Protocol), an AI agent can use a CAP service as a tool. With an agent workflow, the business service can also become part of an automated decision-making process.

I created the CAP Magic project to demonstrate these possibilities in one working CAP application.

The repository is available here:

https://github.com/attilaberencsi/capmagic

What Is CAP Magic ?

CAP Magic is a Node.js and TypeScript CAP application implementing the backend of a fictional wheel and tire shop.

The project contains a business data model for products, manufacturers, purchase orders, sales orders and stock. The service is available as a standard OData v4 service, but it can also be consumed through an MCP server.

This means that the same CAP business logic can be used by:

• SAP Fiori or UI5 applications through OData
• Other external service consumers
• AI assistants and coding agents through MCP
• Agent workflows, such as LangGraph-based workflows

The goal is not to replace the classic CAP application architecture. The goal is to extend it with agentic possibilities.

The Business Scenario

The application is based on a simple wheel shop scenario.

The shop sells wheels and tires, manages manufacturers, creates purchase orders, processes sales orders and keeps track of stock.

This is a familiar business scenario, but it is complex enough to demonstrate real application concepts:

• Product catalog management
• Sales and procurement processes
• Stock and inventory overview
• Out-of-stock forecasting
• Replenishment planning

The project also contains a generated SAP Fiori application for the stock overview including a custom view interacting with the CAP service via MCP Protocol.

CAP Service as OData API

The first scenario is the traditional CAP application.

The WheelService exposes the business entities as an OData v4 service. A UI application can consume the service in the usual way, for example with SAP Fiori elements or SAPUI5.

This is the normal CAP development experience:

• CDS data model
• Service definitions
• TypeScript service implementation
• SQLite database for local development
• OData v4 endpoint
• Fiori application on top of the service

There is nothing special or AI-specific required for this part. It is a regular CAP application which can be extended, deployed and consumed like any other CAP service.

CAP Service as MCP Server

The interesting part starts when the CAP service is also exposed through MCP.

MCP is a protocol which allows AI clients and agents to discover and call tools in a structured way. Instead of manually creating a separate AI integration API, the CAP service can be made available as an MCP server.

In the project this is handled by the @cap-js/mcp package.

An MCP-capable client can access the business service and work with the available business data. For example, an agent can ask about available products, check stock levels or support a procurement-related process.

The important point here is that the business logic remains in CAP.

The AI client is not directly connected to the database. It uses the service layer. Authorization, validations, actions and business logic can stay where they belong: in the CAP application.

CAP actions are exposed as tools and may invoke LLMs to do some job, like it is done in our wheel shop service.

Why MCP Is Interesting for CAP Developers

Many AI demonstrations are focused on chat interfaces. But an enterprise application needs more than a chat window.

The real value comes when an agent can use controlled business capabilities.

For a CAP application this can mean:

• Reading business data through an existing service
• Executing well-defined actions
• Calling workflows
• Using validations already implemented in the service layer
• Integrating AI assistance without moving the domain logic outside of the application

MCP makes this integration more standardized. Instead of implementing a custom integration for every AI client, the service can expose its capabilities through a common protocol.

Of course, exposing a service to an agent also requires proper governance. Not every entity, action or operation should automatically be available. This is exactly why the CAP service layer is a good place for such integration.

LangGraph Procurement Workflow

The second scenario in CAP Magic is a LangGraph-based procurement workflow.

The workflow uses the business data from the wheel shop and supports procurement-related decisions. It contains actions for out-of-stock forecasting and replenishment planning.

This is a different use case than simply asking an AI assistant to query data.

The workflow can evaluate the available stock situation and support the next business step. For example, when products are expected to go out of stock, the workflow can help prepare a replenishment plan.

The CAP application remains the source of truth for the business data. LangGraph is used to orchestrate the workflow around this data including LLM calls.

Local LLM Support

The project also contains local LLM configuration.

For development and experimentation, a local model can be a useful option. It gives more control over the environment and makes it possible to test the workflow without depending on a cloud-based model provider.

The model itself is only one component of the solution.

The more important parts are still:

• The business data model
• The service contract
• The available actions
• The workflow steps
• The validation of generated results
• The separation between AI reasoning and business transactions

An LLM can help analyse the situation and propose the next step. The actual business operation should still be handled through controlled application logic. Keep what is deterministic and don’t burn tokens or slow the process down with unnecessary LLM invocation when it is not needed at all. Do not be an AI maniac.

Invoke CAP MCP from a Fiori UI

Why not to do some experiment, and invoke CAP service actions via MCP protocol using Fiori Flexible Programming Model and sap.m.FormattedText control .

Project Structure

CAP Magic follows the usual CAP project structure.

The application uses TypeScript and includes generated CAP types through @cap-js/cds-typer. For local development, SQLite is used as the database.

Getting Started

Clone the repository and install the dependencies:

git clone https://github.com/attilaberencsi/capmagic.git
cd capmagic
npm install
npm run watch

The full setup and available scenarios are documented in the repository README.

Start first with the classic CAP application and explore the OData service and Fiori stock overview. After that, try the MCP server scenario and the LangGraph procurement workflow.

This makes it easier to understand that MCP and agent workflows are not separate applications. They are additional ways to use the same CAP domain model and business service.

Conclusion

CAP Magic is an experiment around a simple question:

How can a CAP application be used in an AI and agentic development world without losing the benefits of a structured enterprise application?

The answer is not to put AI directly into the database or to replace the application service with a prompt.

Instead, CAP can remain responsible for the business model, service contract and transactions. MCP and agent workflows can use these controlled capabilities to provide a new interaction layer on top of the existing application.

This is still an early area, but the combination of CAP, OData, MCP and agent workflows is already very interesting for enterprise development.

You can find the complete example in the repository:

https://github.com/attilaberencsi/capmagic