CDP MCP Server

Ein MCP-Server (Model Context Protocol), der die Customer Data Platform von Acquia für Ihr LLM zugänglich macht. Verbinden Sie Claude, Copilot oder einen beliebigen MCP-fähigen Client mit diesem Server, und er kann Ihre Tenants lesen, Kampagnen steuern, Workflows bearbeiten, Berichte abfragen und generell die langweiligen Verwaltungsaufgaben erledigen, damit Sie es nicht tun müssen.

Entwickelt, weil das Klicken durch CDP-Bildschirme um 2 Uhr morgens niemandem Spaß macht.

Was Sie bekommen

• ~300 Tools für Berechtigungen, Data Warehouse, Kampagnen, Konfiguration, Konnektoren, Berichte, Vorhersagen, Mailer, E-Mail-fähige Seiten, Sicherheit, Cache und Status-APIs — siehe SUPPORTED_TOOLS.md für den vollständigen Katalog

• 8 Playbook-Ressourcen, die dem LLM beibringen, wie man echte mehrstufige Abläufe sequenziert (Kampagnen-Assistent, C360-Profil-Rendering, Workflow-Erstellung, Konnektor-Onboarding, UDMP-Schema-Bearbeitungen usw.) — diese basieren auf dem Reverse-Engineering der Vega- und Config-UIs, damit das Modell nicht mehr raten muss

• Zwei Authentifizierungsmodi: OAuth2-Passwort-Grant (automatisch aktualisiert, 401-Retry, Lock-serialisiert) oder ein statischer Bearer-Token, falls Sie bereits einen haben

• Dev / QA / Prod-Umschaltung über eine einzelne CDP_ENVIRONMENT-Variable

• Stdio-Transport, sodass er direkt in Claude Desktop, VS Code Copilot, Continue, mcphost, Open WebUI (via supergateway) oder den MCP Inspector integriert werden kann

Wenn das oben Genannte wie Fachchinesisch klingt, überfliegen Sie TUTORIAL.md — es führt durch jeden Teil mit Befehlen zum Kopieren und Einfügen. Die vollständige Liste der Tool-Namen und deren Funktionen finden Sie in SUPPORTED_TOOLS.md.

Related MCP server: sitecore-mcp-server

Schnellstart

# 1. Clone and install
git clone https://github.com/atharva-joshi77/cdp-mcp.git
cd cdp-mcp
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

# 2. Configure
cp .env.example .env
# edit .env: CDP_ENVIRONMENT, CDP_TENANT_ID, and either
#   CDP_CLIENT_ID/SECRET + CDP_USERNAME/PASSWORD  (OAuth2)
# or CDP_AUTH_TOKEN                                (static token)

# 3. Run
cdp-mcp

cdp-mcp spricht JSON-RPC über stdio. Wenn Sie es also einfach so ausführen, sieht es so aus, als würde es hängen — das ist korrekt. Verbinden Sie es mit einem MCP-Client (siehe unten), und es wird zum Leben erweckt.

Verbindung mit Claude Desktop herstellen

~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "cdp": {
      "command": "/absolute/path/to/cdp-mcp/.venv/bin/cdp-mcp",
      "env": {
        "CDP_ENVIRONMENT": "dev",
        "CDP_TENANT_ID": "12345",
        "CDP_CLIENT_ID": "...",
        "CDP_CLIENT_SECRET": "...",
        "CDP_USERNAME": "...",
        "CDP_PASSWORD": "..."
      }
    }
  }
}

Starten Sie Claude neu, und Sie sollten sehen, dass ~300 cdp_*-Tools in der Tool-Auswahl erscheinen. Für VS Code, Continue, Ollama/Open WebUI und MCP Inspector-Setups finden Sie die vollständigen Anleitungen in TUTORIAL.md §5.

Anforderungen

Abhängigkeiten (automatisch installiert):

• mcp>=1.13.0 — FastMCP-Framework

• httpx>=0.27.0 — async HTTP

• pydantic + pydantic-settings — Konfiguration + Validierung

• python-dotenv — .env-Laden

Projektstruktur

src/cdp_mcp/
├── __main__.py           # entry point: `cdp-mcp` / `python -m cdp_mcp`
├── server.py             # FastMCP server, registers tools + resources
├── config.py             # env/.env loader
├── auth/                 # OAuth2 + static-token provider
├── utils/                # shared httpx client, error helpers
├── resources/            # MCP resource URIs (tenant/*, docs/*)
├── docs/                 # the eight playbooks, shipped as resources
├── types/                # pydantic request/response models
└── tools/                # one subpackage per CDP service area
    ├── permissions/      users, roles, clients
    ├── dw/               data warehouse, A360, audiences, offers, trackers
    ├── campaign/         defs, audiences, messages, dispatches, runs, exports
    ├── config_api/       tenants, workflows, schedules, UDMP, DQE, clusters…
    ├── connectors/       input + output connectors, templates
    ├── reports/          dashboards, widgets, cubes, QL
    ├── predictions/      prediction defs + content templates
    ├── mailer/           accounts, subusers, identifiers, batches
    ├── emailable_pages/  emailable-pages CRUD
    ├── security/         token, auth, SSO, password reset
    ├── cache/            cache ops
    ├── spam/             spam score
    ├── status/           status + orchestration/purge status
    ├── provisions/       self-service provisioning
    ├── global_actions/   platform-wide actions
    └── alerts/           stub (real Alerts API lives in a different stack)

Jedes Tool teilt sich einen einzigen HttpClient mit gepoolten httpx-Verbindungen, einen gemeinsamen Auth-Token-Cache, ein asyncio.Lock für Aktualisierungen, einen One-Shot-401-Retry, URL-kodierte Tenant-IDs und logger.info-Request/Response-Tracing. Wenn sich etwas falsch anfühlt, sagen die Logs normalerweise die Wahrheit.

Playbooks (das Geheimrezept)

Tool-Listen allein reichen nicht aus — viele CDP-Abläufe sind "POST einer Definition, dann POST ?action=publish, dann GET-Status, dann vielleicht POST ?action=schedule mit einer separaten Zeitplan-ID." Das LLM macht dies routinemäßig falsch, wenn es sich selbst überlassen bleibt.

Daher liefert der Server acht Markdown-Playbooks als MCP-Ressourcen:

MCP-Clients entdecken diese beim Verbinden automatisch, und der instructions-Block des Servers verweist das Modell auf jedes einzelne.

Hinweise zur Authentifizierung

• OAuth2 (bevorzugt): Der Provider ruft POST {baseUrl}/token?action=create mit Anmeldedaten in den Headern auf, speichert den Token im Arbeitsspeicher, serialisiert gleichzeitige Aktualisierungen hinter einem asyncio.Lock und aktualisiert ca. 60 Sekunden vor Ablauf. Jeder 401-Fehler von einem nachgelagerten Aufruf löst eine einmalige erzwungene Aktualisierung + Wiederholung aus.

• Statischer Token: Setzen Sie CDP_AUTH_TOKEN, und der OAuth2-Pfad wird komplett übersprungen. Sie sind selbst für die Rotation verantwortlich.

Speichern Sie niemals echte Geheimnisse in diesem Repository. .env ist in gitignore enthalten.

Entwicklung

# smoke test: should print the server's capabilities + tool list
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' | cdp-mcp

# interactive tool browser
npx @modelcontextprotocol/inspector cdp-mcp

# verify tool count
python3 -c "from cdp_mcp.server import create_server; import asyncio; \
  print(len(asyncio.run(create_server().list_tools())))"

Es gibt eine umfassendere Matrix zur Fehlerbehebung (Server startet nicht, 401s, Client kann nicht verbinden usw.) in TUTORIAL.md §9.

Status

• Tool-Anzahl: 301 über 12 CDP-Dienste

• Playbook-Ressourcen: 8

• Alerts-Tools sind absichtlich als Stubs vorhanden — die echte Alerts-API befindet sich auf einem separaten MuleSoft/Go-Stack, der eine eigene Basis-URL und Authentifizierung benötigt (PRs willkommen)

• Integrations-Test-Harness ist in Arbeit (Grundgerüst vorhanden, vollständige Vertragsabdeckung als Nachverfolgung geplant)

Mitwirken

1. Forken, Branch erstellen, hacken.

2. Führen Sie ./gradlew-equivalent aus — okay, einfach pip install -e . und den obigen Rauchtest.

3. Wenn Sie ein Tool hinzufügen, registrieren Sie es im passenden tools/<area>/__init__.py Registrar.

4. Wenn Sie einen mehrstufigen Ablauf hinzufügen, schreiben Sie ein Playbook dafür unter src/cdp_mcp/docs/ und registrieren Sie die Ressource in resources/resource_providers.py.

5. Öffnen Sie einen PR. Seien Sie nett in der Beschreibung.

Lizenz

Intern / proprietär — prüfen Sie dies mit Acquia, bevor Sie es außerhalb Ihres eigenen Tenants verwenden.

Erstellt mit gleichen Teilen httpx, pydantic und Trotz gegen fehlerhafte CDP-Assistenten.