CE-RISE Digital Passport Engineering Assistant

CE-RISE Digital Passport Engineering Assistant

A repo-native stdio MCP server that helps AI agents and human users make better use of existing CE-RISE Digital Passport components, services, schemas, documentation, and deployment workflows.

This assistant is not a replacement for CE-RISE assets. Its role is to guide discovery, configuration, implementation planning, readiness checks, and appropriate reuse of the existing CE-RISE ecosystem.

CE-RISE components and models can be selected individually and combined with external software, models, and deployment workflows. The assistant preserves those choices; it does not require a complete CE-RISE stack or treat an external alternative as a missing component. Its configuration review assesses only the supplied, supported CE-RISE settings and declared CE-RISE connections. External implementations and their interoperability remain outside that assessment.

The main workflow is general Digital Passport adoption: helping an organization understand compliance drivers, value-chain information flows, implementation readiness, and value opportunities from shared information, regardless of company size or organizational label.

The main human-facing CE-RISE solution entry point is:

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

The public documentation for this MCP server is published at:

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

---

What this repository contains

• A minimal stdio MCP server in server/mcp_server.py
• A deterministic initial CE-RISE capability and component catalog in data/solution_catalog.json
• A curated connected-source manifest in data/connected_sources.json
• A read-only live service connection manifest in data/live_service_connections.json
• A deployment artifact manifest in data/deployment_artifacts.json
• A reference-example generalization manifest in data/reference_examples.json
• An update channel manifest in data/update_channels.json
• MCP registry metadata in server.json
• A container runtime skeleton in Dockerfile
• Local run, smoke, and validation scripts in scripts/
• Runtime dependencies in requirements.txt, including the YAML parser used for configuration review
• A first deterministic design workflow example in examples/01-design-workflow/
• Documentation in docs using Book
• GitHub mirror automation for release, OCI image publication, and MCP registry publication
• Codeberg Pages automation for the documentation site

The server is intentionally repo-native at this stage. It does not introduce an installable Python package.

MCP Tool Shape

The initial tool surface is catalog-backed and deterministic:

• list_solution_capabilities
• list_solution_components
• map_user_goal_to_ce_rise_capabilities
• recommend_passport_architecture
• generate_implementation_plan
• assess_implementation_readiness
• assess_adoption_context
• map_value_chain_flows
• identify_value_opportunities
• recommend_adoption_path
• generate_implementation_roadmap
• list_deployment_artifact_templates
• generate_deployment_artifact_plan
• generate_deployment_artifacts
• assess_deployment_artifact_readiness
• review_configuration_consistency
• list_reference_examples
• generalize_reference_example
• list_update_channels
• check_update_channels
• build_update_aware_solution_context
• discover_model_repositories
• list_connected_sources
• check_connected_sources
• inspect_connected_source
• build_connected_solution_snapshot
• list_live_service_connections
• probe_live_service
• inspect_live_service_openapi
• build_live_service_readiness_snapshot

The initial resource surface is:

• ce-rise://solution/catalog
• ce-rise://solution/scope
• ce-rise://sources/manifest
• ce-rise://services/live-connections
• ce-rise://deployment/artifact-templates
• ce-rise://examples/reference-generalization
• ce-rise://updates/channels

The first implementation is documentation/resource-oriented with a small read-only service discovery layer, a deployment-artifact output layer, a reference-example generalization layer, and an optional update-awareness layer. It connects to curated CE-RISE repositories and documentation references, can inspect local sibling repositories when they are available, can optionally check remote repository/documentation URL availability, can probe read-only live service endpoints such as health, readiness, version, and OpenAPI, can return Docker Compose or Kubernetes starter file contents derived from the existing CE-RISE GitOps template, can generalize reusable patterns from the local demonstrator without copying its concrete demo data or local-only settings, and can check configured release/tag/documentation channels for current upstream metadata when requested.

Normal component-aware outputs include an update_awareness field. This makes update needs visible even when the user did not explicitly ask about versions: the field lists relevant configured update channels and recommends the update-aware tools before implementation, deployment, or detailed technical decisions.

Generation tools can carry update context directly. For example, generate_deployment_artifacts accepts check_remote_updates; when enabled, it checks configured update channels, includes version_context, writes a generated VERSION-CONTEXT.md file into the returned artifact set, and uses checked model_artifact_version tags where they map safely to generated registry catalog entries.

The update layer covers software components, reference examples, deployment templates, documentation availability, and known data model repositories through explicit read-only channels. The server can also discover additional CE-RISE model repositories under the configured model namespace with discover_model_repositories; newly discovered repositories are returned as candidate update channels for review instead of being silently trusted as implementation inputs. Template and model-architecture repositories can be tracked for version awareness without being treated as deployable data model artifacts.

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

Adoption, architecture, value-chain, and roadmap outputs include source_references and live_service_connections fields where relevant, so recommendations are grounded in CE-RISE assets rather than presented as standalone advice.

Deployment artifact outputs are starter planning artifacts only. They do not replace the canonical dp-system-gitops-template repository or the component-specific deployment documentation.

review_configuration_consistency checks supplied Compose or Kubernetes configuration contents for mismatched ports and service URLs, missing required models, catalog URL policy violations, and authentication inconsistencies. It accepts resolved Compose files or rendered Kubernetes manifests and reports findings by field. Missing referenced configuration is reported as incomplete. External components and endpoints are listed separately as out_of_scope, not as missing or incomplete. A configuration containing no supported CE-RISE component returns not_applicable. It does not open the supplied paths, contact services, or run deployment commands. See Configuration Consistency Review.

The deployment tools support RE Indicators and SEE Impacts independently or together. Select see_impacts_calculation_service in selected_components, or pass include_see_impacts: true, to include SEE in the generated Compose and Kubernetes files. The files use pinned service images from the GitOps template. Kubernetes outputs include SEE-only and, when both services are selected, combined calculation overlays.

An explicit selected_components list generates only those supported CE-RISE parts; external labels are retained without generating or assessing their implementations. Selecting SEE without HEX Core produces standalone service fragments, not a local core or registry. Use hex_core_base_url to configure the chosen validation endpoint, including an external compatible implementation. Omitting selected_components requests the optional HEX Core reference baseline. Architecture and implementation tools likewise preserve declared mixed selections rather than adding a required CE-RISE component set.

For environmental footprint workflows, the assistant points to Product System and LCI Dataset inputs, the caller's functional unit, and the complete Integrated LCA output containing all 25 configured indicators. SEE supplies the shared BONSAI background and fixed EF 3.1 methods; these are service configuration, not per-request characterization-factor inputs. The assistant can inspect SEE's health, capabilities, methods, and OpenAPI endpoints but does not run calculations.

The local demonstrator provides chair, laptop RE-indicator, and PV impact workflows. The PV case demonstrates numerical comparison, live input/output validation, and persistence; it does not limit SEE to photovoltaic products. See examples/02-deployment-artifacts for an environmental footprint deployment request.

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

Local Use

Install the runtime dependencies in the Python environment used to run the MCP server:

python -m pip install -r requirements.txt

The container image includes these dependencies.

Run the MCP server:

./scripts/run-local.sh

Run a local MCP smoke check:

./scripts/smoke-mcp.sh

Run a container MCP smoke check:

./scripts/smoke-container.sh

Run local validation:

./scripts/validate-local.sh

Equivalent make targets are available:

make smoke

make smoke-container make test make validate

Minimal local MCP client configuration:

{

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

Publication Model

Development happens on Codeberg:

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

The documentation site is published from the Codeberg repository:

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

The GitHub repository is a mirror used for release-side automation, following the CE-RISE MCP publication pattern:

• build and publish the MCP OCI image to GitHub Container Registry;
• update server.json for the release version and image tag;
• publish the MCP server metadata to the official MCP Registry using GitHub OIDC;
• create GitHub releases for Zenodo integration.

After release, the server is expected to be reachable in two ways:

• MCP Registry and OCI package: MCP clients can discover the stdio server by the registry identity below and run the published GHCR image.
• MCPO/OpenAPI gateway: when 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. The gateway URL is deployment metadata and is not hardcoded in this repository.

The MCP registry identity is:

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

The OCI image pattern is:

• ghcr.io/ce-rise-software/dp-engineering-assistant-mcp:

License

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