{ "markdown": "# CE-RISE Digital Passport Engineering Assistant\n\n[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.20066903.svg)](https://doi.org/10.5281/zenodo.20066903)\n[![MCP Registry](https://img.shields.io/badge/MCP%20Registry-DP%20Engineering%20Assistant%20MCP-0A7B83)](https://registry.modelcontextprotocol.io/?q=dp-engineering-assistant)\n\n\n\nA 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.\n\nThis 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.\n\nThe 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.\n\nThe main human-facing CE-RISE solution entry point is:\n\n- https://solution.ce-rise.eu/\n\nThe public documentation for this MCP server is published at:\n\n- https://ce-rise-software.codeberg.page/dp-engineering-assistant/\n\n---\n\n## What this repository contains\n\n- A minimal stdio MCP server in `server/mcp_server.py`\n- A deterministic initial CE-RISE capability and component catalog in `data/solution_catalog.json`\n- A curated connected-source manifest in `data/connected_sources.json`\n- A read-only live service connection manifest in `data/live_service_connections.json`\n- A deployment artifact manifest in `data/deployment_artifacts.json`\n- A reference-example generalization manifest in `data/reference_examples.json`\n- An update channel manifest in `data/update_channels.json`\n- MCP registry metadata in `server.json`\n- A container runtime skeleton in `Dockerfile`\n- Local run, smoke, and validation scripts in `scripts/`\n- A first deterministic design workflow example in `examples/01-design-workflow/`\n- Documentation in `docs` using [Book](https://book.deno.land/)\n- GitHub mirror automation for release, OCI image publication, and MCP registry publication\n- Codeberg Pages automation for the documentation site\n\nThe server is intentionally repo-native at this stage. It does not introduce an installable Python package.\n\n## MCP Tool Shape\n\nThe initial tool surface is catalog-backed and deterministic:\n\n- `list_solution_capabilities`\n- `list_solution_components`\n- `map_user_goal_to_ce_rise_capabilities`\n- `recommend_passport_architecture`\n- `generate_implementation_plan`\n- `assess_implementation_readiness`\n- `assess_adoption_context`\n- `map_value_chain_flows`\n- `identify_value_opportunities`\n- `recommend_adoption_path`\n- `generate_implementation_roadmap`\n- `list_deployment_artifact_templates`\n- `generate_deployment_artifact_plan`\n- `generate_deployment_artifacts`\n- `assess_deployment_artifact_readiness`\n- `list_reference_examples`\n- `generalize_reference_example`\n- `list_update_channels`\n- `check_update_channels`\n- `build_update_aware_solution_context`\n- `discover_model_repositories`\n- `list_connected_sources`\n- `check_connected_sources`\n- `inspect_connected_source`\n- `build_connected_solution_snapshot`\n- `list_live_service_connections`\n- `probe_live_service`\n- `inspect_live_service_openapi`\n- `build_live_service_readiness_snapshot`\n\nThe initial resource surface is:\n\n- `ce-rise://solution/catalog`\n- `ce-rise://solution/scope`\n- `ce-rise://sources/manifest`\n- `ce-rise://services/live-connections`\n- `ce-rise://deployment/artifact-templates`\n- `ce-rise://examples/reference-generalization`\n- `ce-rise://updates/channels`\n\nThe 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.\n\nNormal 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.\n\nGeneration 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.\n\nThe 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.\n\nIt does not call live CE-RISE business operations such as record creation, validation, query, indicator computation, or registry refresh.\n\nAdoption, 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.\n\nDeployment artifact outputs are starter planning artifacts only. They do not replace the canonical `dp-system-gitops-template` repository or the component-specific deployment documentation.\n\nCompliance-oriented outputs are planning aids only. They do not provide legal certification or legal advice.\n\n## Local Use\n\nRun the MCP server:\n\n```bash\n./scripts/run-local.sh\n```\n\nRun a local MCP smoke check:\n\n```bash\n./scripts/smoke-mcp.sh\n```\n\nRun a container MCP smoke check:\n\n```bash\n./scripts/smoke-container.sh\n```\n\nRun local validation:\n\n```bash\n./scripts/validate-local.sh\n```\n\nEquivalent make targets are available:\n\n```bash\nmake smoke\nmake smoke-container\nmake test\nmake validate\n```\n\nMinimal local MCP client configuration:\n\n```json\n{\n \"mcpServers\": {\n \"dp-engineering-assistant\": {\n \"command\": \"/home/riccardo/code/CE-RISE-software/dp-engineering-assistant/scripts/run-local.sh\"\n }\n }\n}\n```\n\n## Publication Model\n\nDevelopment happens on Codeberg:\n\n- https://codeberg.org/CE-RISE-software/dp-engineering-assistant\n\nThe documentation site is published from the Codeberg repository:\n\n- https://ce-rise-software.codeberg.page/dp-engineering-assistant/\n\nThe GitHub repository is a mirror used for release-side automation, following the CE-RISE MCP publication pattern:\n\n- build and publish the MCP OCI image to GitHub Container Registry;\n- update `server.json` for the release version and image tag;\n- publish the MCP server metadata to the official MCP Registry using GitHub OIDC;\n- create GitHub releases for Zenodo integration.\n\nAfter release, the server is expected to be reachable in two ways:\n\n- MCP Registry and OCI package: MCP clients can discover the stdio server by the registry identity below and run the published GHCR image.\n- 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.\n\nThe MCP registry identity is:\n\n- `io.github.CE-RISE-software/dp-engineering-assistant`\n\nThe OCI image pattern is:\n\n- `ghcr.io/ce-rise-software/dp-engineering-assistant-mcp:`\n\n## License\n\nLicensed under the [European Union Public Licence v1.2 (EUPL-1.2)](LICENSE).\n\n## Contributing\n\nThis repository is maintained on [Codeberg](https://codeberg.org/CE-RISE-software/dp-engineering-assistant) 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.\n\n---\n\n\n \"EU\n\n\nFunded by the European Union under Grant Agreement No. 101092281 - CE-RISE.\n\nViews 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).\nNeither the European Union nor the granting authority can be held responsible for them.\n\n(c) 2026 CE-RISE consortium.\n\nLicensed under the [European Union Public Licence v1.2 (EUPL-1.2)](LICENSE).\n\nAttribution: CE-RISE project (Grant Agreement No. 101092281) and the individual authors/partners as indicated.\n\n\n \"NILU\n\n\nDeveloped by NILU (Riccardo Boero - ribo@nilu.no) within the CE-RISE project.\n", "bytes": 9987, "sha": "eb85bda6f8915058497112d522010cb1afd26b9009fcea50722683a4e1ebfe8e", "repo_slug": "ce-rise-software/dp-engineering-assistant", "fonte": "repo", "truncated": false, "api": "https://agentalog.com/api/listings/mcp_io_github_ce_rise_software_dp_engineerin_ca474f54/readme" }