Related Pages

Related topics: Built-in Server Templates and Usage Guide, Deployment Backends, Configuration Flow, and Client API

Platform Overview and System Architecture

Purpose and Scope

MCP-Platform is a deployment framework for Model Context Protocol (MCP) servers. It packages a curated set of pre-built server templates (databases, developer tools, ticketing, messaging, search) and provides a unified CLI and runtime that turns a single command into a running, containerized MCP endpoint. The platform's stated goal is to let AI developers focus on integration rather than infrastructure, by replacing ad-hoc Docker, transport, and configuration plumbing with a templated, opinionated workflow. Source: README.md:9-15

The project supersedes the legacy mcp-templates package. Existing configurations, Docker images, and deployment workflows remain compatible, but the active development line is the mcp-platform distribution installed via pip install mcp-platform and operated through the mcpp command. Source: README.md:1-7

High-Level System Architecture

The platform is organized into three cooperating layers: a Template Library, a Core Engine, and a Client/CLI surface.

flowchart TB
    User([User / LLM Client]) --> CLI[mcpp CLI / Interactive REPL]
    CLI --> Core[Core Engine\nCacheManager · ConfigProcessor · ResponseFormatter]
    Core --> Discovery[Template Discovery]
    Discovery --> Library[(Template Library\ndemo · github · gitlab · slack · zendesk · postgres · bigquery · trino · elasticsearch)]
    Core --> Deployer[Containerized Deployer]
    Deployer --> Docker[(Docker Engine)]
    Docker --> MCPServer[MCP Server Process]
    MCPServer --> Tools[Tool Surface\nstdio · HTTP · SSE]
    User -.calls tools.-> Tools

The Template Library is the canonical set of directories under mcp_platform/template/templates/. Each template is a self-contained package (server code, configuration schema, documentation, and Docker assets) that the platform can list, validate, and deploy. Source: mcp_platform/template/utils/__init__.py:1-8

The Core Engine is a set of utilities for discovering templates, processing configuration, formatting responses, and caching template metadata. The README advertises a 6-hour template cache with automatic invalidation to accelerate repeated operations. Source: README.md:60-64

The Client/CLI surface is what the operator actually invokes. The non-interactive mcpp command handles one-shot lifecycle operations (list, deploy, logs, tools, call), while the interactive REPL — built on Typer — provides tab completion, command history, and session-style tool execution through MCPClient. Source: mcp_platform/cli/interactive_cli.py:7-19

Template System and Lifecycle

A template is more than a script — it is a deployable unit with a structured layout. The reference implementation in templates/demo/ demonstrates the contract: a server.py entry point, a config.py schema module, FastMCP-decorated tools, a requirements.txt, a Dockerfile, and a docs directory. Source: mcp_platform/template/templates/demo/README.md:9-14

Templates are discovered dynamically. The TemplateDiscovery utility (exported from mcp_platform.template.utils) scans the templates directory and surfaces each entry to the CLI. Source: mcp_platform/template/utils/__init__.py:7-12

When an operator needs a new integration that does not exist yet, the TemplateCreator class scaffolds one. It is an interactive Rich-based prompt flow that asks for an ID, name, and capabilities, then materializes a complete template directory (config, server stub, tests, docs) by adapting a shared config.py template. Source: mcp_platform/template/utils/creation.py:24-44

The platform encourages reuse of upstream MCP implementations rather than rewriting them. Several templates wrap existing open-source MCP servers and surface them through a uniform configuration and deployment layer:

Community requests have shaped recent additions. The Postgres template shipped in release 1.3.0, the gateway improvements in the same release, and a Snowflake template has been requested to follow the Postgres pattern (issues #24, #41). The Trino template was rewritten in release 1.2.0 and the Elasticsearch template added dual-engine support. Source: release notes referenced in community context

Configuration, Transports, and Execution

Configuration is intentionally multi-channel. A single deployment can receive values from JSON files, YAML files, environment variables, CLI --config key=value flags, or override parameters. The override path performs type conversion ("true" → bool, "123" → int, JSON-like strings → list/dict), which is exercised by the demo template's demonstrate_overrides helper. Source: mcp_platform/template/templates/demo/README.md:21-30

Transports are abstracted. Templates expose stdio (default for many wrapped servers), HTTP (the demo defaults to HTTP on port 7071), and SSE where the upstream server supports it. The interactive CLI routes tool calls through MCPClient rather than raw HTTP, ensuring the platform's own error handling and formatting apply uniformly. Source: mcp_platform/cli/interactive_cli.py:24-31, mcp_platform/template/templates/demo/README.md:37-47

The interactive REPL has been deliberately simplified: the prior implicit "select a template for the session and auto-inject it" behavior has been removed. Commands now require explicit template arguments and surface clear errors when omitted, trading a small ergonomic shortcut for predictable, scriptable behavior. Source: mcp_platform/cli/interactive_cli.py:42-47

Known Failure Modes and Community Notes

• Documentation drift across templates is a known issue (#28): the docs/ directory under each template is inconsistent in its usage instructions. New template authors should follow the demo's structure.
• Stale tool-calling examples have appeared in some template READMEs (e.g., BigQuery, #27) showing direct API calls rather than the mcpp / MCPClient flow. The platform's intended path is always through the client or CLI.
• Docs build workflow has failed on shallow clones due to setuptools_scm warnings (#43), which can break the GitHub Actions documentation pipeline if not handled.

See Also

• Template Creation Utility
• CLI Reference
• Configuration Schema and Overrides
• Demo Template Walkthrough
• Adding a New Template (Contributor Guide)

Related Pages

Related topics: Creating Custom Templates and Extensions, Deployment Backends, Configuration Flow, and Client API

Built-in Server Templates and Usage Guide

Overview and Purpose

The MCP Platform ships with a curated library of built-in server templates under mcp_platform/template/templates/. Each template wraps a real-world service (databases, code hosting platforms, ticketing systems, search engines, demos) into a deployable MCP server with consistent configuration, transport handling, and tool exposure. Templates expose template.json metadata alongside a FastMCP-based Python server, enabling one-command deployment via the mcpp CLI.

The platform's core promise is "zero-configuration deployment of production-ready MCP servers with Docker containers" (Source: README.md), and the template system is the mechanism that delivers it. Discovery, instantiation, and registration of templates are handled by the TemplateDiscovery and TemplateCreator classes exposed from the package entry point (Source: mcp_platform/template/utils/__init__.py).

Template Architecture

A template follows a modular layout: a config.py (typed config + env mapping), a tools.py (FastMCP tool definitions), and a server.py entrypoint. The demo template documents this structure explicitly, noting that the modular design makes each module "testable, maintainable, extensible, reusable" (Source: mcp_platform/template/templates/demo/README.md).

flowchart LR
    A[mcpp CLI] --> B[TemplateDiscovery]
    B --> C[Template Catalog]
    C --> D[config.py]
    C --> E[tools.py]
    C --> F[server.py]
    D --> G[FastMCP Server]
    E --> G
    F --> G
    G --> H[Docker Container]
    G --> I[stdio Transport]
    G --> J[HTTP/SSE Transport]
    H --> K[MCP Client / LLM]
    I --> K
    J --> K

TemplateDiscovery enumerates all templates under the TEMPLATES_DIR constant, while TemplateCreator generates new templates from a config.py base, scaffolding a directory tree complete with a Dockerfile, README.md, USAGE.md, docs/index.md, and pytest suite (Source: mcp_platform/template/utils/creation.py).

Built-in Template Catalog

The catalog spans demos, developer platforms, ticketing, search, and databases. The community has been actively extending this list — feature requests exist for Snowflake, Trino, Elasticsearch, BigQuery, and a Postgres-based Snowflake replica, reflecting user demand for broader enterprise data coverage (Source: GitHub issues #24, #33, #36, #41).

Demo Template Usage

The demo template is the canonical example. It exposes three tools — say_hello, get_server_info, and echo_message — and demonstrates both CLI and override-driven configuration (Source: mcp_platform/template/templates/demo/README.md). Local usage:

pip install -r requirements.txt
python server.py --hello-from "Custom Server" --log-level debug
python server.py --transport stdio

Docker usage binds port 7071 by default and can join the mcp-platform network for multi-container deployments.

GitHub Template Usage

The GitHub template wraps the official GitHub MCP server and exposes 77 tools grouped into repository, branch, issue, PR, Actions, and security categories. It emphasizes "dynamic tool discovery, comprehensive monitoring, auto-scaling, configuration management, and security" (Source: mcp_platform/template/templates/github/README.md). Users authenticate via GitHub tokens passed through the env block in their MCP client configuration.

GitLab Template Usage

The GitLab template supports stdio, SSE, and Streamable HTTP transports, plus a read-only mode (GITLAB_READ_ONLY_MODE=true) and feature toggles such as USE_GITLAB_WIKI, USE_MILESTONE, and USE_PIPELINE for granular capability control (Source: mcp_platform/template/templates/gitlab/README.md). Self-hosted GitLab Enterprise requires setting GITLAB_API_URL and optionally HTTP_PROXY.

Template Lifecycle and CLI Integration

The interactive CLI (mcpp) provides session-level commands for browsing templates, listing tools, and calling them. It requires readline for command history and tab completion and lazily imports typer, rich, and MCPClient to keep startup fast (Source: mcp_platform/cli/interactive_cli.py). Note that the previous "select template for session" injection logic has been removed — commands now require an explicit template argument to avoid ambiguity.

Creating a new template from scratch is interactive:

mcpp create my-template

The TemplateCreator.create_template_interactive method walks the user through id, name, description, image, capabilities, and config schema, then writes template.json, config.py, tools.py, server.py, Dockerfile, README.md, USAGE.md, and docs/index.md (Source: mcp_platform/template/utils/creation.py). It generates a class name like MyTemplateServerConfig from the kebab-case id and stamps metadata, env_mapping, and required fields directly from the gathered schema.

Common Failure Modes and Community Notes

Several recurring community pain points surface around templates:

• Documentation inconsistency — Per-template docs/ directories have historically differed in usage instructions (Source: GitHub issue #28). The TemplateCreator now generates docs/index.md from a shared layout to standardize the contract.
• Incorrect tool-call examples — Older BigQuery docs showed raw HTTP-style calls rather than the mcpp client flow; this is addressed by routing all examples through client.call (Source: GitHub issue #27, see mcp_platform/template/templates/demo/README.md for the canonical pattern).
• Docs build failures — The GitHub Actions build-docs workflow has been observed failing on shallow clones (Source: GitHub issue #43); this affects CI only and not runtime behavior.
• Extending to new data sources — Community requests consistently follow the same pattern: replicate an existing template's directory layout, map authentication env vars, and add a template.json entry (Source: GitHub issues #24, #33, #36, #41).

For advanced troubleshooting, the demo template documents debug logging via MCP_LOG_LEVEL=debug, port conflicts (python server.py --port 7072), and Docker network creation (docker network create mcp-platform) (Source: mcp_platform/template/templates/demo/README.md).

See Also

• README.md — Top-level project overview and migration from mcp-templates.
• mcp_platform/template/utils/creation.py — Reference for authoring new templates.
• mcp_platform/cli/interactive_cli.py — Interactive mcpp> shell internals.
• Release notes for release-pypi-1.1.0 through release-pypi-1.3.1 — Per-template changelog.

Related Pages

Related topics: Built-in Server Templates and Usage Guide, Deployment Backends, Configuration Flow, and Client API

Creating Custom Templates and Extensions

Overview and Scope

MCP-Platform ships a template system that lets developers package an MCP server, its configuration schema, Docker assets, and documentation into a single deployable unit. Once installed (pip install mcp-platform), every template becomes addressable through the unified mcpp CLI for operations such as mcpp deploy <template>, mcpp tools <template>, and mcpp call <template> <tool> (README.md).

The platform supports three modes of extension:

1. Author a brand-new template via the interactive TemplateCreator (mcp_platform/template/utils/creation.py).
2. Replicate an existing template by cloning its directory layout (the pattern requested by the community for Snowflake, Trino, and Elasticsearch — see issues #41, #36, #33).
3. Wire an external MCP server (such as the official GitHub or GitLab server) into the platform's configuration and discovery flow (mcp_platform/template/templates/github/README.md).

Discovery and runtime resolution are handled by TemplateDiscovery and MCPClient (mcp_platform/template/utils/__init__.py, mcp_platform/client/client.py).

Architecture of a Template

Every shipped template lives under mcp_platform/template/templates/<id>/ and follows a consistent four-module structure, as documented for the reference demo template (mcp_platform/template/templates/demo/README.md).

flowchart LR
    A[template.json<br/>metadata + config_schema] --> B[config.py<br/>typed ServerConfig]
    B --> C[tools.py<br/>FastMCP tool defs]
    C --> D[server.py<br/>CLI + transport]
    D --> E[Dockerfile + docs/]
    E --> F[mcpp deploy &lt;id&gt;]
    A --> G[TemplateDiscovery]
    G --> F

The template.json file declares the template's id, description, image reference, and the JSON Schema that drives runtime configuration. config.py exposes a typed ServerConfig class generated from that schema. tools.py registers FastMCP tool functions with @mcp.tool decorators, and server.py wires the FastMCP instance to the chosen transport (stdio, SSE, or streamable HTTP). Documentation under docs/ is consumed both by the deployer and by the scripts/build_docs.py GitHub workflow (mcp_platform/template/templates/demo/README.md).

Using the TemplateCreator

TemplateCreator is the primary authoring entry point. It accepts either an interactive prompt session or a YAML/JSON config file passed through create_template_interactive(template_id, config_file) (mcp_platform/template/utils/creation.py).

The interactive flow:

1. Verifies the destination directory under templates/<id>/. If the directory exists, the user is asked to confirm overwrite before any file is generated.
2. Collects template metadata (name, description, capabilities, image tag) and the list of config_schema properties plus their env_mapping names.
3. Renders a Rich Panel summary and requires a final confirmation before any disk mutation.
4. Generates config.py by loading the demo config.py and adapting class names (<CamelCase>ServerConfig) and template-specific labels (mcp_platform/template/utils/creation.py).
5. Writes server.py, tools.py, template.json, a Dockerfile, README.md, USAGE.md, and docs/index.md.

The non-interactive path (_create_from_config_file) is recommended for CI and for replicating an existing template from a versioned specification, mirroring how the community proposed Snowflake and Elasticsearch templates be derived from Postgres and the official Elastic MCP server (#41, #33).

Replication Pattern and External Integrations

The Postgres template, added in release 1.3.0, has become the reference blueprint for database-backed templates. Issue #41 explicitly asks contributors to "replicate the same pattern, same directory structure" when creating the Snowflake template, while issue #36 proposes the same for Trino, pointing to the upstream Docker image ghcr.io/tuannvm/mcp-trino:latest.

For external server integrations, the GitHub and GitLab templates demonstrate how to wrap an existing MCP server implementation rather than rewrite it. The GitLab template ships 66+ tools covering issues, merge requests, pipelines, wiki, and milestones, and exposes toggles such as GITLAB_READ_ONLY_MODE, USE_GITLAB_WIKI, USE_MILESTONE, and USE_PIPELINE for runtime feature control (mcp_platform/template/templates/gitlab/README.md). The GitHub template similarly advertises 77 tools with token-based authentication and dynamic discovery (mcp_platform/template/templates/github/README.md). Zendesk shows the data-API integration shape with rate-limiting and cache configuration (mcp_platform/template/templates/zendesk/README.md).

In every case, runtime validation flows through MCPClient.validate_template, which calls TemplateManager.validate_template to confirm schema correctness before deployment (mcp_platform/client/client.py).

Common Pitfalls and Failure Modes

Two recurring issues shape how new templates should be reviewed:

• Documentation inconsistency (#28): per-template docs under mcp_platform/template/templates/<id>/docs/ drift in format and content. Templates should follow the structure emitted by _create_docs_index — a top-level overview, a configuration table keyed on env_mapping, and per-capability usage sections with example arguments (mcp_platform/template/utils/creation.py).
• Documentation build failure (#43): the scripts/build_docs.py workflow fails on shallow clones because setuptools_scm cannot resolve git history. Templates should not depend on undocumented setuptools_scm state at build time.
• Tool-call instructions (#27): BigQuery docs originally described an API-style invocation. Templates must instead document the mcpp call <template> <tool> '<args>' flow, which is the only contract honored by the interactive CLI (mcp_platform/cli/interactive_cli.py).

Adhering to the TemplateCreator-generated skeleton avoids all three classes of bug and keeps templates consistent with the platform's discovery, configuration, and deployment pipeline.

See Also

• CLI Reference: mcpp deploy, mcpp tools, mcpp call (README.md)
• Interactive CLI usage (mcp_platform/cli/interactive_cli.py)
• Demo template walkthrough (mcp_platform/template/templates/demo/README.md)
• Postgres template release notes (release-pypi-1.3.0)

Related Pages

Related topics: Platform Overview and System Architecture, Creating Custom Templates and Extensions

Deployment Backends, Configuration Flow, and Client API

Overview

MCP-Platform exposes a uniform client API (MCPClient) that fronts multiple deployment backends (Docker, Kubernetes, Mock) so the CLI, interactive shell, and programmatic callers can deploy, introspect, and invoke MCP servers without backend-specific code paths. The platform's design — confirmed in release 1.3.1 which added a kubeconfig environment variable config for the Kubernetes backend — is "configure once, deploy anywhere" through a normalized configuration flow that flows from template schema → environment variables → backend runtime.

Source: README.md:1-60 Source: mcp_platform/cli/cli.py:1-80

Deployment Backends

The backend layer abstracts container orchestration so a single mcpp deploy call works against any registered backend. The CLI defaults to the active backend stored in cli_state["backend_type"], and users can override it per-invocation with --backend.

The CLI's list_templates(include_deployed_status=True, all_backends=not backend) call demonstrates the multi-backend design: the client can aggregate status across every registered backend or scope to one. The multi-manager internally exposes _multi_manager.get_available_backends() so the table renderer can dynamically add a column per backend.

Source: mcp_platform/cli/cli.py:40-90 Source: mcp_platform/cli/interactive_cli.py:55-90

Community note: Release 1.3.1 explicitly introduced "Kubeconfig environment variable config", reflecting user demand for the Kubernetes backend to be a first-class deployment target alongside Docker. See Release 1.3.1.

Configuration Flow

Configuration travels through four well-defined stages, each represented by a dedicated module or class in the codebase:

flowchart LR
    A[Template config_schema] --> B[ConfigProcessor]
    C[CLI flags / JSON / YAML] --> B
    D[Environment variables] --> B
    B --> E[Backend-specific env]
    E --> F[Deployment]

1. Template declaration — Each template ships a JSON schema describing its required and optional parameters. The schema is the single source of truth and is consumed by the ConfigProcessor to validate user input. Templates in mcp_platform/template/templates/ (e.g., gitlab, github, zendesk, demo) all follow this pattern.

1. User input — Users supply values through any of four channels: CLI flags, JSON files, YAML files, or environment variables. The interactive CLI additionally supports live configure <TEMPLATE> KEY=VALUE commands that mutate session state.

1. Normalization — ConfigProcessor (imported by the interactive CLI) merges inputs, applies precedence rules, and performs the type conversion documented in the demo template (booleans from "true"/"false", integers, floats, JSON arrays, JSON objects).

1. Backend materialization — The resolved configuration is translated into the backend's native representation (e.g., Docker --env flags or Kubernetes env entries in a Pod spec) and dispatched to the chosen backend for deployment.

Source: mcp_platform/cli/interactive_cli.py:55-65 Source: mcp_platform/template/utils/creation.py:140-200 Source: mcp_platform/template/templates/demo/README.md:80-140

Override Semantics

Overrides target two distinct layers:

The demo template exposes a demonstrate_overrides tool specifically to help users verify both override patterns against a running deployment.

Source: mcp_platform/template/templates/demo/README.md:60-110

Client API Surface

MCPClient is the single entry point used by both the one-shot CLI (cli.py) and the interactive REPL (interactive_cli.py). It is constructed with a backend_type argument and exposes methods that map 1:1 to the CLI's top-level commands:

• list_templates(include_deployed_status, all_backends) — enumerates templates; used by mcpp list.
• list_deployments(backend, output_format) — returns running deployments; powers mcpp list-deployments.
• deploy(template_id, config, ...) — deploys a template via the active backend.
• call_tool(template, tool_name, args) — invokes a tool on a running deployment.
• get_tools(template) — discovers and catalogs the tools a deployed server exposes.

The interactive CLI explicitly removes an older "template selection + auto-injection" feature, citing a comment in source: *"Selection/injection logic removed: commands must be called with an explicit template... that feature has been removed to simplify the interactive CLI."* This means every command now requires the template to be passed explicitly, producing clearer error messages.

Source: mcp_platform/cli/cli.py:1-90 Source: mcp_platform/cli/interactive_cli.py:55-100

Template Discovery and Creation Utilities

The mcp_platform.template.utils package provides two complementary helpers, exported from its __init__.py:

• TemplateDiscovery — locates templates on disk, reads their config_schema and metadata, and surfaces them to the client.
• TemplateCreator — generates a new, fully formed template directory (config.py, server module, tests, docs) by copying and adapting the demo template's config.py and prompting the user for template-specific fields such as name, description, and capabilities. It is the tool behind mcpp create-template and the workflow used to add new servers like Snowflake and Elasticsearch (community feature requests #24 and #33).

Source: mcp_platform/template/utils/__init__.py:1-15 Source: mcp_platform/template/utils/creation.py:1-200

Community note: Several open issues (#24 Snowflake, #33 Elasticsearch, #36 Trino, #41 "replicate postgres template for snowflake") follow exactly the workflow TemplateCreator codifies — clone the postgres / demo pattern, supply authentication config, generate docs under docs/. The recurring bug #28 ("Templates specific documentation inconsistent") is a known consequence of this hand-rolled replication and motivates stricter template scaffolding.

Common Failure Modes

1. Misaligned template docs — As reported in issue #28, per-template documentation under docs/ diverges because the generation step in creation.py produces free-form Markdown. Prefer running the generated docs through the docs build (the build failure tracked in issue #43) to surface inconsistencies early.

1. Wrong tool-call mechanism in template docs — Issue #27 shows the BigQuery template originally described tool invocation as raw HTTP calls. The correct path is the MCPClient.call_tool() API surfaced by the CLI, not bespoke HTTP.

1. Backend unavailable — The multi-backend list_templates call silently hides backends that are not installed (e.g., no kubectl configured). Confirm with the explicit --backend docker|kubernetes|mock flag.

1. Configuration precedence surprises — Environment variables win over CLI flags only when intentionally layered; consult the ConfigProcessor source when troubleshooting.

See Also

• Templates Catalog — full list of bundled templates
• CLI Reference — every mcpp subcommand
• Interactive Shell — REPL usage and tab completion
• Configuration Schema — authoring your own config_schema

Doramagic Pitfall Log

Found 14 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Capability evidence risk - Capability evidence risk requires verification.

1. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/Data-Everything/MCP-Platform

2. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/Data-Everything/MCP-Platform

3. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/Data-Everything/MCP-Platform

4. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/Data-Everything/MCP-Platform

5. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/27

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/43

7. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/28

8. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/20

9. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/41

10. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/24

11. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/33

12. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/Data-Everything/MCP-Platform/issues/36

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using MCP-Platform with real data or production workflows.

• [[BUG] Github workflow build-docs failing](https://github.com/Data-Everything/MCP-Platform/issues/43) - github / github_issue
• [[FEATURE] Snowflake MCP server](https://github.com/Data-Everything/MCP-Platform/issues/24) - github / github_issue
• [[FEATURE] Replicate postgres template to create new snowflake template](https://github.com/Data-Everything/MCP-Platform/issues/41) - github / github_issue
• [[FEATURE] Trino database template creation](https://github.com/Data-Everything/MCP-Platform/issues/36) - github / github_issue
• [[FEATURE] Support for elasticsearch MCP server](https://github.com/Data-Everything/MCP-Platform/issues/33) - github / github_issue
• [[BUG] Bigquery template docs has wrong information about how to call too](https://github.com/Data-Everything/MCP-Platform/issues/27) - github / github_issue
• [[BUG] Templates specific documentation inconsistent](https://github.com/Data-Everything/MCP-Platform/issues/28) - github / github_issue
• [[FEATURE] Bigquery mcp server](https://github.com/Data-Everything/MCP-Platform/issues/20) - github / github_issue
• Release 1.3.1 - Kubeconfig environment variable config - github / github_release
• Release 1.3.0 - Postgres Template - github / github_release
• Trino Template and many other improvements - github / github_release
• Slack & bigquery template release - 1.1.0 - github / github_release