Las agencias sienten el costo de los cambios pequeños más que nadie. Un cliente quiere la barra de fiestas publicada hoy, otro quiere pausar el widget de la página de precios durante un rediseño, un tercero quiere las cifras del mes pasado para un informe. En un panel, eso son tres inicios de sesión y muchos clics. Con el servidor MCP de Provedly, pueden ser tres frases en el editor que ya tienes abierto.
Este artículo explica cómo configurarlo para que siga ordenado a medida que crece la lista de clientes. Para el caso general de las agencias, incluido cómo hablar con los clientes sobre prueba social honesta, consulta prueba social para agencias.
Dos formas de estructurar las cuentas
Cómo te conectes depende de cómo estén organizadas las configuraciones de Provedly de tus clientes.
Una cuenta, muchos sitios. Si gestionas tu cartera de clientes desde una sola cuenta de Provedly, cada cliente es un sitio de esa cuenta. Una clave los cubre a todos y el asistente ve todos los sitios. Es lo más sencillo de conectar, y significa que tienes que poner nombres con cuidado, porque "pausa el widget de la página de inicio" es ambiguo cuando doce sitios tienen uno.
Una cuenta por cliente. Si cada cliente es dueño de su propia cuenta de Provedly y te ha dado acceso, cada cuenta necesita su propia clave. Es más configuración y te da límites más limpios: una clave del cliente A no puede tocar al cliente B, y cuando termina el contrato, el cliente revoca tu clave y se acabó.
Los límites del plan van con la cuenta. En la primera configuración, los límites de sitios, widgets y barras de tu plan se comparten entre todos los clientes. En la segunda, el plan de cada cliente se aplica a su propia cuenta.
Conectar varias cuentas
Los clientes MCP te permiten añadir más de un servidor. Dale a cada uno un nombre que diga a qué cliente pertenece:
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"
El asistente ve entonces dos conjuntos de las mismas herramientas, uno por servidor, y tú dices a qué cliente te refieres. En Cursor, el equivalente son dos entradas en mcp.json, como se muestra en la guía de Cursor.
Mantenlos a nivel de usuario y no en una configuración de proyecto que podría acabar en un commit. Un repositorio con las claves de varios clientes es un mal día esperando a ocurrir.
Nombres que sobreviven a una semana ajetreada
El asistente encuentra widgets y barras por su nombre. Los nombres genéricos causan confusiones, así que adopta una convención y respétala:
- Empieza los nombres de las barras con la campaña y termínalos con el cliente o el sitio: "BF 2026 oferta principal, Northwind".
- Nombra los widgets por su ubicación: "Páginas de producto", "Página de precios", "Checkout".
- Nombra las claves por la persona y el cliente: "Maria, Harbor, lectura y escritura".
También puedes referirte a los elementos por su id (un UUID) o por su token, así que cuando un nombre sea realmente ambiguo, pídele al asistente que liste los elementos con sus ids y actúa sobre el id.
Un día en la práctica
Una mañana realista podría ser así.
Para Northwind, crea una barra de cuenta regresiva llamada "Lanzamiento de invierno, Northwind" que termine el 1 de diciembre a las 9 a. m. con el mensaje "La colección de invierno abre en {timer}".
La barra se crea en pausa. Envíale al cliente una captura de la vista previa desde el panel, o léele el mensaje. Cuando lo apruebe:
Para Northwind, activa la barra del lanzamiento de invierno.
Después:
Para Harbor, pausa el widget de la página de precios. La están rediseñando esta semana.
Y para los informes:
Para cada cliente, dame impresiones, clics, pedidos verificados y pedidos asistidos por la prueba con sus ingresos de octubre.
El asistente llama a get_stats una vez por cuenta. Pega las cifras en tu informe, con una línea que explique qué significa "asistido por la prueba"; en cómo medir los pedidos asistidos por la prueba social hay una redacción que puedes reutilizar.
Niveles de acceso para una agencia
No todo el equipo necesita cambiar cosas. Un reparto razonable:
| Rol | Nivel de clave |
|---|---|
| Gestor de cuenta, informes | Read only |
| Responsable de campañas | Read and write |
| Desarrollador, instalaciones | Read only, más el fragmento de instalación |
| Backend que envía registros | Read and write, con su propia clave |
Las claves de solo lectura pueden llamar a get_install_snippet, así que un desarrollador que instala el script no necesita acceso de escritura. El razonamiento detrás de cada nivel está en claves de solo lectura frente a claves de escritura.
Lo que no cambia para los clientes
A veces los clientes temen que una agencia con herramientas de IA pueda inflar sus cifras. No puede. Los registros añadidos mediante la API o por un asistente llevan una etiqueta visible "Imported" en el widget y nunca la marca de verificado, y la página de verificación del cliente los lista en "Site owner's backend (API)". Solo los webhooks firmados de la tienda producen registros verificados. La página de verificación pública del cliente muestra las fuentes. Es algo que conviene decir en voz alta en una presentación comercial, y el límite de la verificación lo explica con más detalle.
Preguntas frecuentes
¿Una clave puede acceder a varias cuentas de Provedly?
No. Una clave pertenece a una cuenta. Conecta un servidor MCP por cuenta, cada uno con su propia clave y un nombre claro.
¿Qué pasa con mis claves cuando un cliente se va?
Si el cliente es dueño de la cuenta, revoca tu clave en su Settings y el acceso termina de inmediato. Si el sitio está en tu cuenta, gestiónalo según lo acordado con el cliente y revoca cualquier clave que existiera solo para su trabajo.
¿Hay un costo extra por cliente?
Las claves, la API y el servidor MCP están incluidos en todos los planes. El plan de cada cuenta fija sus propios límites.
Consulta los límites de sitios, widgets y barras de cada plan en la página de precios.