Helps plan and reuse CE-RISE Digital Passport components, models, and deployment assets. It is a repo-native stdio MCP server intended for AI agents and human users to make better use of existing Digital Passport components, services, schemas, documentation, and deployment workflows.
🛠️ Key Features
Reuse and planning support for CE-RISE Digital Passport components
Access to Digital Passport models and deployment workflows
Covers components, services, schemas, and documentation
🚀 Use Cases
Planning reuse of existing Digital Passport engineering assets
Integrating or coordinating Digital Passport schema and service information
Supporting deployment workflow usage for Digital Passport assets
⚡ Developer Benefits
Repo-native stdio MCP server interface
Designed to help agents use documentation and deployment workflows
⚠️ Limitations
Source material does not specify available tools, endpoints, or configuration details
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.
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:
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
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.
Compliance-oriented outputs are planning aids only. They do not provide legal certification or legal advice.
Local Use
Run the MCP server:
bash
./scripts/run-local.sh
Run a local MCP smoke check:
bash
./scripts/smoke-mcp.sh
Run a container MCP smoke check:
bash
./scripts/smoke-container.sh
Run local validation:
bash
./scripts/validate-local.sh
Equivalent make targets are available:
bash
make smoke
make smoke-container
make test
make validate
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.
This repository is maintained on Codeberg as the canonical source of truth. The GitHub repository is a read mirror used for release archival, OCI image publication, MCP registry publication, and Zenodo integration. Issues and pull requests should be opened on Codeberg.
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.
