Agenturen spüren die Kosten kleiner Änderungen stärker als alle anderen. Ein Kunde will die Feiertagsleiste heute online haben, ein anderer will das Widget auf der Preisseite während eines Redesigns pausieren, ein dritter braucht die Zahlen vom letzten Monat für einen Bericht. Im Dashboard sind das drei Logins und viel Klickerei. Mit dem MCP-Server von Provedly können es drei Sätze in dem Editor sein, den du ohnehin offen hast.
Dieser Beitrag zeigt, wie du das so einrichtest, dass es auch mit wachsender Kundenliste ordentlich bleibt. Den größeren Rahmen für Agenturen, einschließlich der Frage, wie du mit Kunden über ehrlichen Social Proof sprichst, findest du unter Social Proof für Agenturen.
Zwei Möglichkeiten, Konten zu strukturieren
Wie du dich verbindest, hängt davon ab, wie die Provedly-Setups deiner Kunden organisiert sind.
Ein Konto, viele Websites. Betreust du eine Kundenliste aus einem einzigen Provedly-Konto, ist jeder Kunde eine Website in diesem Konto. Ein Schlüssel deckt alle ab, und der Assistent sieht jede Website. Das ist am einfachsten zu verbinden und bedeutet, dass du sorgfältig benennen musst, denn „pausiere das Homepage-Widget“ ist mehrdeutig, wenn zwölf Websites eines haben.
Ein Konto pro Kunde. Hat jeder Kunde sein eigenes Provedly-Konto und dir Zugriff gegeben, braucht jedes Konto einen eigenen Schlüssel. Das ist mehr Einrichtung und ergibt sauberere Grenzen: Ein Schlüssel für Kunde A kann Kunde B nicht anfassen, und wenn eine Zusammenarbeit endet, widerruft der Kunde deinen Schlüssel, und das war es.
Plan-Limits hängen am Konto. Im ersten Setup teilen sich alle Kunden die Limits deines Plans für Websites, Widgets und Leisten. Im zweiten gilt für jeden Kunden der Plan seines eigenen Kontos.
Mehrere Konten verbinden
MCP-Clients erlauben mehr als einen Server. Gib jedem einen Namen, der sagt, zu welchem Kunden er gehört:
claude mcp add --transport http provedly-northwind https://provedly.app/mcp \
--header "Authorization: Bearer provedly_NORTHWIND_KEY"
claude mcp add --transport http provedly-harbor https://provedly.app/mcp \
--header "Authorization: Bearer provedly_HARBOR_KEY"
Der Assistent sieht dann zwei Sätze derselben Tools, einen pro Server, und du sagst, welchen Kunden du meinst. In Cursor entspricht das zwei Einträgen in mcp.json, wie in der Cursor-Anleitung gezeigt.
Lege diese im Benutzerbereich ab und nicht in einer Projektkonfiguration, die committet werden könnte. Ein Repository mit den Schlüsseln mehrerer Kunden ist ein schlechter Tag, der nur darauf wartet, zu passieren.
Benennung, die eine stressige Woche übersteht
Der Assistent findet Widgets und Leisten über ihren Namen. Generische Namen führen zu Verwechslungen, also leg eine Konvention fest und halte dich daran:
- Leistennamen beginnen mit der Kampagne und enden mit dem Kunden oder der Website: „BF 2026 main sale, Northwind“.
- Widgets nach Platzierung benennen: „Product pages“, „Pricing page“, „Checkout“.
- Schlüssel nach Person und Kunde benennen: „Maria, Harbor, read and write“.
Elemente lassen sich auch über ihre ID (eine UUID) oder ihren Token ansprechen. Ist ein Name wirklich mehrdeutig, lass den Assistenten die Elemente mit ihren IDs auflisten und arbeite mit der ID.
Ein Tag in der Praxis
Ein realistischer Vormittag könnte so aussehen.
Erstelle für Northwind eine Countdown-Leiste namens „Winter launch, Northwind“ mit Ende am 1. Dez. um 9 Uhr und der Nachricht „Die Winterkollektion startet in {timer}“.
Die Leiste wird pausiert angelegt. Schick dem Kunden einen Screenshot der Vorschau aus dem Dashboard oder lies ihm die Nachricht vor. Wenn er freigibt:
Schalte für Northwind die Winter-Launch-Leiste ein.
Dann:
Pausiere für Harbor das Widget auf der Preisseite. Sie bauen sie diese Woche um.
Und für das Reporting:
Gib mir für jeden Kunden Impressionen, Klicks, verifizierte Bestellungen und durch Proof unterstützte Bestellungen mit Umsatz für Oktober.
Der Assistent ruft get_stats einmal pro Konto auf. Füge die Zahlen in deinen Bericht ein, mit einer Zeile, die erklärt, was „durch Proof unterstützt“ bedeutet; in durch Proof unterstützte Bestellungen messen findest du Formulierungen, die du übernehmen kannst.
Zugriffsstufen für eine Agentur
Nicht jeder im Team muss etwas ändern. Eine sinnvolle Aufteilung:
| Rolle | Schlüsselstufe |
|---|---|
| Account Manager, Berichte | Read only |
| Kampagnenmanager | Read and write |
| Entwickler, Installationen | Read only, plus das Installations-Snippet |
| Backend, das Einträge sendet | Read and write, eigener Schlüssel |
Schlüssel mit reinem Lesezugriff können trotzdem get_install_snippet aufrufen, ein Entwickler, der das Skript installiert, braucht also keinen Schreibzugriff. Die Überlegungen hinter jeder Stufe stehen in Lese- vs. Schreibschlüssel.
Was für Kunden gleich bleibt
Kunden befürchten manchmal, dass eine Agentur mit KI-Tools ihre Zahlen aufblähen könnte. Das geht nicht. Einträge, die über die API oder von einem Assistenten hinzugefügt werden, tragen im Widget ein sichtbares „Imported“-Label und nie die Kennzeichnung „Verifiziert“, und die Verifizierungsseite des Kunden führt sie unter „Site owner's backend (API)“. Nur signierte Shop-Webhooks erzeugen verifizierte Einträge. Die öffentliche Verifizierungsseite des Kunden zeigt die Quellen. Das solltest du in einem Pitch ruhig laut sagen, und die Grenze der Verifizierung erklärt es genauer.
Häufige Fragen
Kann ein Schlüssel auf mehrere Provedly-Konten zugreifen?
Nein. Ein Schlüssel gehört zu einem Konto. Verbinde einen MCP-Server pro Konto, jeden mit eigenem Schlüssel und einem klaren Namen.
Was passiert mit meinen Schlüsseln, wenn ein Kunde geht?
Gehört das Konto dem Kunden, widerruft er deinen Schlüssel in seinen Settings, und der Zugriff endet sofort. Liegt die Website in deinem Konto, regle es wie mit dem Kunden vereinbart und widerrufe jeden Schlüssel, der nur für seine Arbeit existierte.
Kostet jeder Kunde extra?
Schlüssel, die API und der MCP-Server sind in jedem Plan enthalten. Der Plan jedes Kontos legt dessen eigene Limits fest.
Die Plan-Limits für Websites, Widgets und Leisten findest du auf der Preisseite.