CE-RISE Digital Passport Engineering Assistant

The CE-RISE Digital Passport Engineering Assistant is a stdio MCP server for AI-assisted reuse of existing CE-RISE Digital Passport assets.

Its purpose is to help users discover CE-RISE components, understand how they fit together, map engineering goals to available capabilities, plan implementation steps, and assess readiness before moving into more specific CE-RISE tools or deployment workflows.

It does not replace CE-RISE services, schemas, methods, documentation, or deployment assets. It guides users toward them.

The main product workflow is general Digital Passport adoption. The assistant should help an organization clarify compliance drivers, value-chain information flows, implementation readiness, and value opportunities from shared information. This workflow is not tied to a company-size label.

Initial Scope

The first implementation is intentionally small and deterministic:

• a local CE-RISE capability and component catalog;
• a curated connected-source manifest for CE-RISE repositories, documentation, model assets, and service references;
• a read-only live service connection manifest for health, readiness, version, and OpenAPI probes;
• a deployment artifact manifest for Compose and Kubernetes starter outputs derived from the CE-RISE GitOps template;
• a reference-example manifest that treats the local demonstrator as an example to generalize from, not a mandatory target architecture;
• an update channel manifest for optional current release, tag, documentation, and artifact metadata checks;
• MCP tools for discovery, architecture guidance, adoption context assessment, value-chain flow mapping, value-opportunity identification, implementation planning, and readiness checks;
• MCP tools for listing, checking, inspecting, and snapshotting connected CE-RISE sources;
• MCP tools for read-only live service discovery;
• MCP tools for planning, generating, and readiness-checking deployment artifact outputs;
• MCP tools for listing reference examples and generalizing reusable workflow patterns from them;
• MCP tools for optional update-aware context over configured CE-RISE upstream channels;
• MCP resources exposing the catalog, source manifest, live service manifest, deployment artifact manifest, reference-example manifest, update channel manifest, and core scope rule;
• a first design workflow example under examples/01-design-workflow/;
• local validation and smoke scripts;
• release-side metadata for OCI image publication and MCP registry publication from the GitHub mirror.

The first server connects to curated CE-RISE repositories and documentation references. It can inspect local sibling repositories when they are available, optionally check remote repository/documentation URL availability, and probe read-only live service discovery endpoints.

It can also return Docker Compose and Kubernetes starter file contents for planning deployment handover. These outputs are derived from the existing CE-RISE GitOps template and are not a replacement deployment framework.

It does not call live CE-RISE business operations such as record creation, validation, query, indicator computation, or registry refresh.

Compliance-oriented outputs are planning aids only. They are not legal certification or legal advice.

Main Reference

The human-facing CE-RISE solution entry point remains:

• https://solution.ce-rise.eu/

Local Commands

./scripts/run-local.sh
./scripts/smoke-mcp.sh
./scripts/smoke-container.sh
./scripts/validate-local.sh

Repository

The canonical repository is maintained on Codeberg:

• https://codeberg.org/CE-RISE-software/dp-engineering-assistant

The published documentation for this MCP server is:

• https://ce-rise-software.codeberg.page/dp-engineering-assistant/

The GitHub mirror is used for release automation, OCI image publication, MCP registry publication, and Zenodo integration.

After release, MCP clients can discover the server through the MCP Registry identity io.github.CE-RISE-software/dp-engineering-assistant. When the server is registered behind the CE-RISE MCPO gateway, HTTP/OpenAPI clients can reach it through the gateway endpoint published in this documentation.

Funded by the European Union under Grant Agreement No. 101092281 - CE-RISE.

Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the granting authority (HADEA). Neither the European Union nor the granting authority can be held responsible for them.

(c) 2026 CE-RISE consortium.

Licensed under the European Union Public Licence v1.2 (EUPL-1.2).

Attribution: CE-RISE project (Grant Agreement No. 101092281) and the individual authors/partners as indicated.

Developed by NILU (Riccardo Boero - ribo@nilu.no) within the CE-RISE project.

MCP Server

The repository ships a thin stdio MCP server in server/mcp_server.py.

Design Rule

The server is an assistant over existing CE-RISE assets. It must guide discovery, configuration, planning, and readiness assessment without substituting for CE-RISE components.

The current runtime is repo-native and uses only the Python standard library. It is not packaged as an installable Python project.

Runtime Shape

• local entry point: ./scripts/run-local.sh
• transport: stdio
• message framing: newline-delimited JSON-RPC 2.0
• exposed MCP capabilities: tools, resources
• catalog source: data/solution_catalog.json
• connected-source manifest: data/connected_sources.json
• live service connection source: data/live_service_connections.json
• deployment artifact source: data/deployment_artifacts.json
• reference example source: data/reference_examples.json
• update channel source: data/update_channels.json

Tools

Resources

Result Contract

Tool results use a deterministic envelope:

• result_type
• inputs
• content
• diagnostics

MCP tool responses include the same payload in both content[0].text and structuredContent.

Compliance-oriented outputs are planning aids only. They do not provide legal certification or legal advice.

Adoption, value-chain, architecture, and roadmap tools include grounding fields where relevant:

• source_references: curated CE-RISE repositories, documentation sites, and model assets related to the recommendation;
• live_service_connections: read-only service discovery connections related to the selected components.

Connected Sources

The connection layer is curated through data/connected_sources.json.

The server can:

• list connected CE-RISE repositories, documentation sites, model assets, and service references;
• inspect local sibling repositories when they are available in the same workspace;
• extract Markdown headings from curated key files;
• check remote repository and documentation URLs when check_remote is explicitly enabled.

It does not automatically call live CE-RISE business services in this first connected version.

Reference Examples

The reference-example layer is curated through data/reference_examples.json.

The local demonstrator is treated as an illustrative workflow. The server can generalize reusable patterns from it, such as scope declaration, service selection, registry adaptation, representative payload design, lifecycle operations, and operational checks.

The server should not treat demonstrator-specific products, payloads, no-auth settings, ports, or local persistence decisions as defaults for other adopters.

Update Awareness

The update-awareness layer is curated through data/update_channels.json.

Stable tools remain deterministic by default, but component-aware outputs include an update_awareness block so users are not expected to know on their own when upstream changes may matter. When current upstream metadata is needed, clients can call:

• list_update_channels to discover configured release, tag, documentation, and artifact channels;
• check_update_channels to fetch current metadata from selected channels;
• build_update_aware_solution_context to combine stable catalog components with optional remote update checks;
• discover_model_repositories to check the configured CE-RISE model repository namespace and propose channels for model repositories that are not yet explicitly tracked.

Generation tools can also include update checks directly when they expose check_remote_updates. In that mode, generated outputs include version_context and a generated VERSION-CONTEXT.md file.

This avoids needing a new MCP server release for every upstream model, component, or example update. It also keeps network access explicit instead of making every planning call depend on remote availability.

Discovered model repositories are treated as candidates. A generated artifact should only use a model version after an explicit model tag channel exists and has been checked.

Deployment Artifact Outputs

The deployment artifact layer is curated through data/deployment_artifacts.json.

The server can return starter file contents for:

• Docker Compose baseline with HEX Core Service, a local registry catalog, and an external IO adapter URL;
• optional Compose profiles for the internal adapter and RE Indicators Calculation Service;
• Kubernetes base, development overlay, production overlay, and optional RE indicators extension.

The generated outputs are intended for planning, review, and handover into the canonical dp-system-gitops-template workflow. The server does not write files to disk and does not deploy anything.

Users must still review secrets, image tags, domains, registry entries, authentication mode, resource settings, and environment overlays against the existing CE-RISE template and component documentation.

Live Service Discovery

The live service layer is curated through data/live_service_connections.json.

The server can probe:

• HEX Core Service: GET /admin/health, GET /admin/ready, GET /admin/version, GET /admin/models/count, GET /openapi.json
• Digital Passport JSON DB Storage Service: GET /health, GET /ready, GET /openapi.json
• RE Indicators Calculation Service: GET /health, GET /openapi.json

The server intentionally does not call write or domain-operation endpoints such as:

• record creation or query;
• model validation, create, or query operations;
• indicator computation;
• registry refresh.

Local URL overrides are restricted to localhost addresses.

Local Use

./scripts/run-local.sh
./scripts/smoke-mcp.sh
./scripts/smoke-container.sh
./scripts/validate-local.sh

Minimal local MCP client configuration:

{
  "mcpServers": {
    "dp-engineering-assistant": {
      "command": "/home/riccardo/code/CE-RISE-software/dp-engineering-assistant/scripts/run-local.sh"
    }
  }
}

Publication

Project documentation is published at:

• https://ce-rise-software.codeberg.page/dp-engineering-assistant/

The MCP registry identity is declared in server.json:

• io.github.CE-RISE-software/dp-engineering-assistant

Once a release is published, MCP clients can discover the stdio server through the MCP Registry identity and run the published OCI package:

• ghcr.io/ce-rise-software/dp-engineering-assistant-mcp:<release-version>

When the server is registered behind the CE-RISE MCPO gateway, HTTP/OpenAPI clients can reach the same MCP tools through the gateway endpoint published in the project documentation. That MCPO/OpenAPI URL is deployment metadata, so it is documented when provisioned rather than embedded in the server code.

The GitHub mirror workflow .github/workflows/publish-mcp.yml is responsible for:

• validating the local server;
• updating server.json for the release version;
• building and pushing ghcr.io/ce-rise-software/dp-engineering-assistant-mcp:<release-version>;
• publishing the server metadata to the MCP Registry using GitHub OIDC.

Solution Catalog

The initial MCP server is backed by data/solution_catalog.json.

The catalog is deliberately small and deterministic. It is not a source of truth replacing CE-RISE documentation or services. It is an assistant-facing routing layer that helps agents point users toward existing CE-RISE assets.

The connected-source layer is backed by data/connected_sources.json. It records curated links to CE-RISE repositories, documentation sites, model assets, and service references that ground the assistant’s guidance.

The live service discovery layer is backed by data/live_service_connections.json. It records read-only GET probes for health, readiness, version, and OpenAPI discovery.

The deployment artifact layer is backed by data/deployment_artifacts.json. It records Compose and Kubernetes starter artifact profiles derived from the existing CE-RISE GitOps deployment template.

The reference-example layer is backed by data/reference_examples.json. It records illustrative CE-RISE workflows and the reusable patterns that can be generalized from them.

The update-awareness layer is backed by data/update_channels.json. It records read-only release, tag, repository-discovery, documentation, and generated-artifact metadata channels that can be checked at tool-call time.

Catalog Sections

• capabilities: assistant-facing CE-RISE capability families.
• components: existing CE-RISE assets and their intended reuse role.
• architecture_patterns: reusable Digital Passport implementation paths.
• adoption_context_fields: fields used to assess general Digital Passport adoption context.
• compliance_drivers: broad planning drivers for compliance-oriented adoption, without legal certification.
• value_chain_flow_types: information flow categories across value-chain actors.
• value_opportunity_patterns: practical value opportunities from shared information.
• adoption_paths: phased CE-RISE reuse paths for adoption workflows.
• readiness_fields: fields used by readiness assessment.
• deployment_artifacts: generated through a separate manifest for Compose/Kubernetes artifact profiles and readiness fields.
• reference_examples: generated through a separate manifest for illustrative examples, reusable patterns, non-assumptions, and adaptation questions.
• update_channels: generated through a separate manifest for version-sensitive upstream metadata checks.

Current Component Coverage

The initial catalog includes:

• CE-RISE Solution Portal
• HEX Core Service
• Digital Passport JSON DB Storage Service
• Digital Passport System Local Demonstrator
• Digital Passport System GitOps Template
• CE-RISE Models
• RE Indicators Calculation Service

This list is expected to grow as the server is connected to more detailed CE-RISE documentation and workflows.

Maintenance Rule

Catalog entries should stay factual, conservative, and reuse-oriented. When a workflow needs implementation detail, the assistant should point to the relevant CE-RISE component or documentation rather than duplicating or replacing it.

Adoption and compliance entries should remain general planning guidance. They should not assert legal compliance or imply certification.

Connected-source entries should stay curated and explicit. The assistant should only inspect listed files from listed sources, and live service calls should be introduced separately with clear scope and tests.

Live service entries must stay read-only unless the project explicitly expands scope. Domain operations such as record creation, validation, query, computation, and registry refresh are intentionally excluded from the initial service connection layer.

Deployment artifact entries must stay grounded in the canonical dp-system-gitops-template repository. Generated artifacts are starter outputs for planning and review; they should not drift into a parallel deployment framework.

Reference-example entries must distinguish concrete demo details from reusable patterns. The assistant should generalize from examples, not imply that the example product, payload, auth mode, storage, or local stack is mandatory.

Update-channel entries must stay read-only and explicit. Stable architecture and scope guidance should remain in the local catalog; version-sensitive facts should come from update checks when current metadata is needed. Repository-discovery channels may propose new model update channels, but the server should not silently turn unknown repositories into generated deployment inputs. Model artifact channels should use model_artifact_version; model architecture documentation and model templates should use separate update roles.

Reference Examples

The server can use CE-RISE examples as examples, then generalize from them.

The first curated reference example is the Digital Passport System Local Demonstrator. It is useful because it shows existing CE-RISE components working together locally, but its concrete products, payloads, local no-auth settings, storage choices, and ports are not defaults for adopters.

Use generalize_reference_example to extract reusable patterns such as:

• declaring the adopter’s scope and value-chain roles;
• selecting required CE-RISE services and optional services;
• adapting the model registry catalog;
• preparing adopter-specific valid and invalid payloads;
• exercising the intended record lifecycle;
• turning demo checks into environment-appropriate operational checks.

The result separates:

• reusable pattern;
• contextualized action for the declared adoption context;
• CE-RISE assets to reuse;
• assumptions from the example that should not be carried over.

This keeps the demonstrator useful without making it a hidden architecture mandate.

Update Awareness

The server separates stable guidance from version-sensitive facts.

Stable guidance lives in the local catalog:

• scope rules;
• non-substitution boundaries;
• component roles;
• architecture and adoption patterns;
• reference-example generalization;
• deployment artifact shape.

Version-sensitive facts live in configured update channels:

• repository releases;
• repository tags;
• repository discovery;
• documentation availability;
• generated artifact availability.

Use list_update_channels to inspect the configured channels, then check_update_channels when current metadata is needed. Use build_update_aware_solution_context when a workflow should combine stable component guidance with optional current upstream metadata.

Generation tools can also carry this context directly. For deployment artifact generation, pass check_remote_updates: true to generate_deployment_artifact_plan or generate_deployment_artifacts. The result includes version_context, and generated artifact sets include VERSION-CONTEXT.md. Where a checked model_artifact_version tag maps cleanly to registry catalog fields, the generated registry catalog uses the checked version. Model template and architecture/documentation channels are included in version context but excluded from registry catalog entries.

See examples/03-update-aware-generation for a request and expected response shape.

Use discover_model_repositories when the current question is whether the CE-RISE model namespace contains additional model repositories that are not yet explicitly tracked. The tool checks the configured CE-RISE model repository root and returns candidate gitea_tags update channels for new repositories. Those candidates are review inputs; generated artifacts should use a newly discovered model only after it has an explicit model-artifact update channel. Template and architecture/documentation repositories can still be tracked for version awareness, but they are not treated as data model artifact inputs.

Normal workflow tools also include an update_awareness field whenever they select or expose CE-RISE services, models, examples, deployment templates, or source references. That field is deliberately non-blocking:

• it says whether current metadata was checked;
• it lists the configured update channels relevant to the selected components;
• it recommends build_update_aware_solution_context or check_update_channels before implementation, deployment, or detailed technical decisions.

Remote checks are explicit. The server does not silently call upstream repositories from every planning tool, because deterministic behavior and offline use are still important.

This means the MCP server does not need a new release just because a CE-RISE model, service, example, or deployment template publishes a new version. A new MCP release is needed only when the stable guidance, tool behavior, manifests, generated artifact logic, or supported update channels themselves change.

Deployment Artifacts

The server can return starter deployment files through generate_deployment_artifacts.

These outputs are derived from the existing CE-RISE Digital Passport System GitOps Template:

• Docker Compose baseline with hex-core-service;
• optional Compose profiles for internal-adapter and re-indicators-calculation-service;
• Kubernetes base aligned with the existing template’s overlay workflow;
• development and production overlays;
• optional Kubernetes extension for RE indicators.

The generated files are returned as structured MCP content:

• path: relative file path, such as compose/docker-compose.yml;
• mime_type: content type hint;
• description: short file purpose;
• content: complete file content.

generate_deployment_artifact_plan and generate_deployment_artifacts accept check_remote_updates. When this is true, the same generation call checks configured update channels and returns a version_context. Generated artifact sets also include VERSION-CONTEXT.md. Checked model_artifact_version tags are used where they map cleanly to generated registry catalog entries. Model architecture documentation and model template channels remain visible in version context but are not emitted as registry catalog model entries.

The server does not write these files to disk and does not deploy anything.

Recommended Flow

1. Use generate_deployment_artifact_plan to map the adoption context and selected CE-RISE services to artifact profiles.
2. Use assess_deployment_artifact_readiness to check whether runtime, service, adapter, registry, auth, overlay, and operational-check decisions are declared.
3. Use generate_deployment_artifacts to return starter files.
4. Validate and adapt those files against the canonical dp-system-gitops-template repository.

The concrete Digital Passport scenario in examples/02-deployment-artifacts shows the expected profile selection and file list for a Compose plus Kubernetes output set with the RE indicators extension enabled.

Boundary

Deployment artifacts are planning and handover outputs. They help a user make the most of the existing CE-RISE deployment template, but they do not replace that template, its validation scripts, or the deployment documentation of the underlying services.