MCP en el panel SMM: conecta tu asistente de IA a tu cuenta

MCP (Model Context Protocol) es un protocolo abierto que permite a un asistente de IA usar las herramientas de un servicio externo, y en un panel SMM significa que tu asistente puede buscar servicios, calcular precios, crear pedidos y seguir su estado dentro de tu propia cuenta, sin que le entregues tu contraseña. Esa es la definición corta. El resto de esta guía es la definición larga: qué herramientas existen exactamente, qué puede y qué no puede tocar el asistente, cómo se autoriza la conexión, cuánto duran los permisos y qué pasa cuando algo falla.

Panel Follows expone un servidor MCP en POST /api/mcp/user. Cualquier cliente de IA compatible con MCP (Claude, Cursor, VS Code, un bot propio) puede añadir esa dirección, pasar por una pantalla de autorización en el propio panel y, a partir de ahí, trabajar contra tu cuenta con dieciocho herramientas concretas. La página del panel se llama "Asistente IA" en el menú lateral y vive en /es/dashboard/mcp.

Conviene aclarar desde el principio qué tipo de documento es este. No es un argumento de venta de la IA ni una promesa de que el asistente vaya a gestionar tu negocio solo. Es la descripción operativa de un mecanismo: qué llamadas se hacen, qué campos devuelven, qué comprobaciones existen antes de que se gaste dinero y en qué puntos concretos el modelo puede equivocarse si no lees la respuesta. Cuando termines de leer sabrás decidir si esto te sirve, y sabrás usarlo sin sorpresas en el saldo.

Tres advertencias antes de entrar en materia. La primera: crear un pedido gasta dinero real y no se puede deshacer. El servidor obliga al modelo a calcular el importe y pedirte confirmación antes de crearlo, pero la última palabra siempre es tuya. La segunda: la reposición y la cancelación dependen del servicio, no del asistente; si un servicio no admite cancelación, el asistente tampoco podrá cancelarlo. Y la tercera: todo lo que leas aquí sobre precios, tiempos o cantidades es método, no cifra. La cifra buena es la que devuelve el panel en el momento de la consulta.

¿Qué es MCP y para qué sirve en un panel SMM?

MCP es un estándar que describe cómo un modelo de lenguaje descubre y llama funciones de un servicio externo. En vez de que cada aplicación invente su propia forma de "enseñarle" herramientas a la IA, MCP fija un contrato común: el servidor publica una lista de herramientas con sus nombres, sus descripciones y el esquema de sus parámetros, y el cliente de IA las llama cuando el usuario pide algo que encaja con una de ellas.

La comparación más útil es con un enchufe. Antes de que existiera un estándar de enchufes, cada aparato necesitaba su propio conector. MCP hace lo mismo con las herramientas de IA: el panel publica su lista una sola vez y cualquier cliente compatible sabe leerla, sin integración a medida por cada asistente.

En un panel SMM eso se traduce en algo muy concreto. Sin MCP, si quieres pedir mil seguidores tienes que abrir el panel, elegir plataforma, elegir categoría, buscar el servicio entre miles, leer su ficha, pegar el enlace, escribir la cantidad y comprobar el total. Con MCP le dices al asistente "busca servicios de seguidores de Instagram con reposición por debajo de un dólar por mil y dime cuánto costarían tres mil unidades", y el asistente hace esas mismas consultas por ti, en segundos, con los precios de tu propia cuenta.

Lo importante es que el asistente no está adivinando. No está leyendo una página web ni interpretando capturas de pantalla. Está llamando a las mismas funciones que usa la API del panel, recibiendo JSON estructurado y contándotelo en lenguaje natural. Si el precio de un servicio cambió esta mañana, el asistente ve el precio de esta mañana.

Hay un segundo efecto, menos obvio y a menudo más valioso: el asistente lee mucho más rápido que tú. Comparar quince servicios equivalentes por precio, mínimo, máximo, garantía de reposición y tiempo medio es una tarea que a mano lleva diez minutos de saltar entre fichas. Para el asistente es una llamada a search_services y una tabla. Ese es probablemente el uso más rentable de todos, y no gasta ni un céntimo porque las herramientas de consulta no crean nada.

Y un tercer efecto que solo se nota cuando gestionas volumen: el asistente no se equivoca de tecla. La mayor parte del dinero que se pierde en un panel se pierde en errores de dedo, un cero de más en la cantidad, un enlace de perfil donde tocaba un enlace de publicación, una casilla marcada sin querer. El asistente puede equivocarse de otras formas (puede elegir mal el servicio, puede malinterpretar tu petición), pero el paso de previsualización obligatorio te enseña el importe exacto antes de que se gaste nada.

¿Por qué no basta con darle la clave de la API al asistente?

Porque una clave API es un permiso total y opaco, mientras que una conexión MCP con OAuth es un permiso acotado, visible y revocable en un clic. La diferencia parece burocrática hasta que la vives.

Cuando le pegas una clave API a un cliente de IA, esa clave queda escrita en un archivo de configuración, muchas veces sin cifrar. Quien tenga acceso a ese archivo tiene acceso a tu saldo. Y desde el lado del panel no hay forma de distinguir un cliente de otro: todas las llamadas llegan con la misma clave, así que "revocar el acceso de Cursor" significa en realidad "regenerar la clave y romper todas las demás integraciones a la vez".

Con OAuth 2.1 el reparto es distinto. Cada cliente de IA se registra por su cuenta, recibe su propio identificador, y el token que se le entrega está ligado a esa pareja de cliente y cuenta. En la sección "Asistentes conectados" de /es/dashboard/mcp ves cada uno por separado, con su nombre, su insignia de "Acceso completo" o "Solo lectura", su fecha de conexión y su fecha de último uso. El botón "Desconectar" corta ese cliente sin tocar los demás.

Hay una segunda razón, más práctica: con OAuth no tienes que copiar nada. No hay que generar una clave, ni pegarla en un archivo, ni acordarse de dónde quedó guardada. Añades la dirección del servidor en tu cliente, el cliente abre el navegador, tú apruebas y ya está. El flujo completo está descrito más abajo paso a paso.

Dicho esto, la clave API sigue siendo una vía legítima y a veces la más cómoda. El servidor la acepta y hay un apartado entero dedicado a cuándo tiene sentido cada una. Lo que no tiene sentido es usar una clave por desconocimiento del otro camino.

Los dos servidores MCP del panel: ¿cuál te corresponde a ti?

El panel expone dos servidores MCP distintos y confundirlos es el primer error conceptual que conviene evitar. Uno es para clientes del panel y el otro es para quien administra el panel. Comparten el mismo núcleo de transporte, pero no comparten ni la autenticación ni las herramientas.

	Servidor de usuario	Servidor de administración
Dirección	POST /api/mcp/user	POST /api/mcp
Quién se conecta	el cliente del panel	el propietario del panel
Identidad	token OAuth 2.1 o la clave API de la cuenta	una única clave secreta (MCP_SECRET)
Alcance	solo su propia cuenta, 18 herramientas	el panel entero, 57 herramientas
Registro de auditoría	aiAuditLog con el identificador de cuenta	aiAuditLog sin identificador de cuenta

Si eres cliente y compras servicios, el tuyo es el primero, y todo lo que viene a continuación se refiere a él salvo que se diga lo contrario. El servidor de administración tiene su propio apartado corto más adelante, sobre todo para que entiendas que el panel se gestiona con el mismo protocolo y con la misma disciplina de registro.

El detalle importante del servidor de usuario es que está atado a una sola cuenta en cada petición. No existe ningún parámetro con el que una herramienta pueda mirar los datos de otro usuario, porque la identidad no viaja como argumento: viaja en la cabecera de autorización y el servidor la resuelve antes de ejecutar nada. Tampoco hay herramientas de administración disponibles en ese servidor, así que ni siquiera un modelo mal instruido puede cambiar un precio o consultar el saldo de otra persona.

¿Qué hay debajo? Transporte, JSON-RPC y versiones del protocolo

Esta sección es técnica y puedes saltártela si solo quieres conectar tu asistente. Está aquí porque explica varios comportamientos que, sin contexto, parecen fallos.

El transporte es Streamable HTTP sin estado con mensajes JSON-RPC 2.0. Sin estado significa que el servidor no guarda un identificador de sesión entre llamadas: cada petición se autentica y se resuelve por sí sola. Eso hace la conexión mucho más robusta frente a reinicios y despliegues, porque no hay nada que se pueda perder por el camino.

No hay flujo SSE. Si abres la dirección del servidor en el navegador con una petición GET, recibes un HTTP 405 con un mensaje que dice que SSE no está soportado y que uses POST para JSON-RPC. Esto confunde a mucha gente que prueba la dirección pegándola en la barra del navegador y concluye que el servidor está caído. No lo está: simplemente ese método no existe aquí.

Método JSON-RPC	Qué hace
initialize	Negocia la versión del protocolo y presenta el servidor
tools/list	Devuelve la lista de herramientas con sus esquemas
tools/call	Ejecuta una herramienta con sus argumentos
prompts/list	Devuelve los comandos preparados
prompts/get	Devuelve el texto de un comando preparado
ping	Comprobación de vida
resources/list	Responde vacío (el servidor no publica recursos)
resources/templates/list	Responde vacío

Sobre las versiones: la nativa es 2025-06-18, y por compatibilidad también se aceptan 2025-03-26 y 2024-11-05. La versión se acuerda durante el initialize, así que un cliente algo antiguo sigue funcionando sin que tengas que hacer nada.

Cuatro comportamientos más que conviene conocer:

1. Se admiten lotes JSON-RPC. Puedes enviar un array de peticiones en un solo cuerpo. Si ese cuerpo contiene únicamente notificaciones, la respuesta es un HTTP 202 sin contenido, que es exactamente lo que manda la especificación.
2. Un error de herramienta no es un error de protocolo. Cuando algo sale mal dentro de una herramienta, la respuesta llega con isError: true y un texto explicativo, no con un error JSON-RPC. Esto es deliberado: el modelo puede leer el mensaje, entender qué falló y corregirse solo, en vez de quedarse bloqueado.
3. La salida se recorta a 100.000 caracteres. Es un límite de seguridad para que una respuesta gigantesca no inunde el contexto del modelo ni dispare el coste de la conversación.
4. Cada herramienta viene etiquetada. En la respuesta de tools/list, cada herramienta lleva las pistas readOnlyHint y destructiveHint. Los clientes que las respetan pueden avisarte antes de ejecutar algo destructivo o incluso pedirte confirmación por su cuenta.

¿A qué dieciocho herramientas accede el asistente?

El servidor de usuario publica dieciocho herramientas, repartidas en cinco áreas. Los nombres no se traducen: son identificadores técnicos y son los mismos en todos los idiomas del panel.

Área	Herramientas
Cuenta	get_account
Catálogo	list_platforms, list_categories, search_services, get_service
Pedidos	preview_order, create_order, create_orders_bulk, list_orders, get_order, cancel_order, refill_order
Reposición	list_refills, get_refill
Automatización	list_events, list_webhooks, create_webhook, delete_webhook

La división que de verdad importa no es por área, sino por si la herramienta lee o escribe:

• Doce herramientas son de solo lectura: get_account, list_platforms, list_categories, search_services, get_service, preview_order, list_orders, get_order, list_refills, get_refill, list_events y list_webhooks. Ninguna de ellas cambia nada ni gasta saldo. Puedes dejar que el asistente las use con total tranquilidad.
• Seis herramientas escriben: create_order, create_orders_bulk, cancel_order, refill_order, create_webhook y delete_webhook.

Dentro de las que escriben hay otra distinción, la que marca la etiqueta destructiveHint. refill_order y create_webhook escriben pero no se consideran destructivas, porque una pide una reposición gratuita y la otra da de alta una dirección de notificación. En cambio create_order, create_orders_bulk, cancel_order y delete_webhook sí están marcadas como destructivas, porque gastan dinero, cancelan trabajo en curso o borran configuración.

Un detalle que ahorra mucho tiempo si ya conoces el panel: cada herramienta es el espejo de un endpoint de la API v3, y los nombres de los parámetros son idénticos. Los campos de pedido son service, link, quantity, runs, interval, comments, username, posts, min, max, usernames, hashtag, hashtags, answer_number, groups, keywords y media. Si ya integraste la API, no tienes que aprender un segundo vocabulario, y la referencia completa sigue estando en la documentación de la API.

Herramienta por herramienta: qué hace cada una y cuándo se llama

Saber los nombres sirve de poco si no sabes qué devuelve cada uno. Este es el detalle que importa, ordenado por el orden natural de uso.

get_account devuelve la identidad de la cuenta, su correo, el saldo disponible en dólares y el límite de peticiones. Es la primera llamada que hace casi cualquier asistente cuando le preguntas "¿cuánto saldo me queda?", y también la que usa antes de proponerte un pedido para verificar que el importe cabe.

list_platforms devuelve las plataformas del catálogo (instagram, tiktok, youtube y las demás) con el número de servicios de cada una. Sirve para que el modelo sepa qué valores son válidos en el filtro platform en vez de inventárselos.

list_categories devuelve las categorías con servicios activos, cada una con su slug, su nombre y su recuento. El filtro category de la búsqueda acepta esos slugs.

search_services es la herramienta central del catálogo. Admite filtros por search (texto en el nombre), platform, category, type, refill, cancel, dripfeed, min_rate y max_rate. El tamaño de página es 20 por defecto y 50 como máximo. Ese límite es deliberado: el resultado entra como texto en el contexto del modelo, y una página de quinientos servicios sería cara y además le nublaría el criterio. Si hacen falta más resultados, se pide la página siguiente con el cursor.

get_service devuelve la ficha completa de un servicio: precio, mínimo y máximo, soporte de reposición, de cancelación y de drip-feed, tiempo medio y, sobre todo, la lista de campos de pedido (fields). Esa lista es la que evita que el modelo adivine qué campos son obligatorios. Un servicio de comentarios personalizados no pide cantidad, uno de encuesta pide el número de opción, uno de suscripción pide usuario y publicaciones. Todo eso sale de aquí, no de una suposición.

preview_order valida el pedido sin crearlo y devuelve charge (el importe), balance_after (el saldo que quedaría) y sufficient_balance (si te llega). Es una herramienta de solo lectura, así que puedes pedirle al asistente que previsualice veinte combinaciones distintas sin gastar nada.

create_order crea el pedido de verdad. Gasta dinero real y no se puede deshacer. El propio texto de la herramienta se lo recuerda al modelo, y las instrucciones del servidor le prohíben llamarla sin confirmación explícita.

create_orders_bulk abre hasta 50 pedidos en una sola llamada. Los elementos se procesan en orden y de forma independiente: si uno falla, los demás siguen adelante y cada uno devuelve su propio resultado. Para saber el importe total antes de lanzarlo, la vía correcta es pasar los elementos uno a uno por preview_order.

list_orders lista tus pedidos, del más nuevo al más antiguo. Acepta filtro por estado (pending, in_progress, completed, partial, canceled, refunded, failed), por servicio y por fecha de creación, y puede incluir los datos del servicio en cada fila. El tamaño de página es 20 por defecto y 100 como máximo.

get_order devuelve el estado actual de un pedido concreto: contador inicial, cantidad restante, importe y, si lo hay, el error del proveedor.

cancel_order cancela un pedido y devuelve al saldo la parte no consumida. Solo funciona si el servicio admite cancelación (features.cancel en la ficha) y si el pedido todavía no está completado. Si no se admite, la respuesta es cancel_not_supported y la vía correcta es abrir un ticket.

refill_order pide una reposición. Solo funciona en pedidos completados y en servicios con garantía de reposición. Es gratuita y no toca el saldo.

list_refills y get_refill listan tus solicitudes de reposición y consultan el estado de una concreta. La consulta individual trae el estado fresco del proveedor.

list_events recorre el flujo de eventos de la cuenta, del más antiguo al más nuevo, con cursor. Es la forma de seguir cambios de estado sin perderse ninguno.

list_webhooks, create_webhook y delete_webhook gestionan las direcciones a las que se envían los eventos. Hay una sección entera sobre esto más adelante.

Una nota común a todas las herramientas de listado: se paginan con cursor. Se envía starting_after con el valor next_cursor que devolvió la respuesta anterior. En la primera página ese parámetro se deja vacío. Si le pides al asistente "sácame todos mis pedidos del último trimestre", esto es lo que hará por debajo, varias llamadas encadenadas.

¿Cómo conectas tu asistente de IA al panel?

La página del panel es "Asistente IA" en el menú lateral, y su dirección es /es/dashboard/mcp. Está organizada en cuatro bloques y el primero es el que necesitas para empezar.

El bloque "Dirección de conexión" muestra la URL del servidor y debajo tres pasos, escritos casi con estas palabras:

1. Copia la dirección y añádela a tu cliente de IA como servidor MCP.
2. El cliente te trae hasta aquí; autoriza la conexión (solo lectura si lo prefieres).
3. Ya puedes decirle "muéstrame precios de seguidores de Instagram" o "cómo van mis últimos pedidos".

La nota que acompaña al bloque es la parte que más tranquiliza a quien nunca ha hecho esto: "La autorización se hace aquí, en el panel; tu contraseña nunca se comparte con el cliente."

El segundo bloque se llama "Configuración por cliente" y trae ejemplos listos para copiar. Para Claude Code:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user

Para clientes que se configuran con un archivo JSON, como Cursor o VS Code:

{ "mcpServers": { "panel": { "type": "http", "url": "https://panelfollows.com/api/mcp/user" } } }

Si prefieres autenticarte con una clave API en vez de pasar por OAuth, el mismo comando admite una cabecera:

claude mcp add --transport http panel https://panelfollows.com/api/mcp/user \
  --header "Authorization: Bearer pf_live_..."

Y si lo que quieres es probar el servidor a mano antes de conectar nada, una llamada con curl te devuelve la lista de herramientas:

curl -s https://panelfollows.com/api/mcp/user \
  -H "Authorization: Bearer pf_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

La nota del panel sobre compatibilidad es escueta y exacta: funciona con cualquier cliente MCP compatible con OAuth 2.1, y los clientes que envían cabeceras también pueden usar una clave API. Esa clave se crea en /es/dashboard/api, donde el propio panel enlaza con el texto "Claves API".

Si eres cliente de un panel de marca blanca, la dirección que verás no es panelfollows.com sino el dominio de tu panel. Eso es intencionado y tiene su propia sección más adelante.

¿Qué hace exactamente el flujo OAuth 2.1 por detrás?

Desde tu lado, conectar un asistente son dos clics: añades la dirección y apruebas en el navegador. Por debajo ocurren seis pasos, todos estándar y todos documentados en RFC públicos. Merece la pena conocerlos porque explican los mensajes de error que puedes encontrarte.

1. El cliente llama sin identificarse y recibe un 401. La respuesta incluye la cabecera WWW-Authenticate con un resource_metadata que apunta a /.well-known/oauth-protected-resource/api/mcp/user. Esto es el mecanismo de RFC 9728: el servidor no rechaza y calla, sino que le dice al cliente dónde averiguar cómo autenticarse.
2. El cliente descubre el servidor de autorización. Lee ese documento y desde ahí llega a /.well-known/oauth-authorization-server, el documento de metadatos de RFC 8414, que enumera todos los endpoints y capacidades.
3. El cliente se registra solo. Hace un POST /api/mcp/oauth/register (RFC 7591) y recibe un identificador propio. Es un cliente público, es decir, sin secreto propio: la autenticación se resuelve con PKCE. El registro está limitado a 10 intentos por hora y por IP, que es suficiente para uso normal y demasiado poco para un abuso automatizado.
4. Se abre el navegador. El cliente te lleva a GET /api/mcp/oauth/authorize, que redirige a la pantalla de autorización del propio panel, en la ruta /mcp/connect. Si no tienes la sesión abierta, primero te manda a iniciar sesión y después vuelve exactamente a la misma pantalla, sin perder la solicitud por el camino.
5. Tú apruebas. Aquí decides, entre otras cosas, si marcas la casilla de solo lectura.
6. El código se canjea por un token. El cliente hace POST /api/mcp/oauth/token. PKCE con S256 es obligatorio: el método plain no se acepta, porque OAuth 2.1 lo prohíbe. El verificador PKCE debe tener entre 43 y 128 caracteres.

Cuatro cosas más que conviene saber sobre este flujo:

• Se puede revocar desde ambos lados. El cliente puede llamar a POST /api/mcp/oauth/revoke, y tú puedes cortar la conexión desde el panel con un clic.
• Las direcciones de retorno están restringidas. Se aceptan https, http de loopback (127.0.0.1 y localhost) y esquemas propios de aplicación como cursor:// o vscode://. Un http plano hacia una dirección remota se rechaza, porque el código de autorización viajaría en claro.
• La dirección de retorno tiene que coincidir con la registrada. La única flexibilidad admitida es el puerto de loopback, tal y como recomienda RFC 8252 para aplicaciones de escritorio que abren un puerto local cualquiera.
• El documento de descubrimiento no miente por omisión. Declara response_types_supported: ["code"], grant_types_supported: ["authorization_code", "refresh_token"], token_endpoint_auth_methods_supported: ["none"], code_challenge_methods_supported: ["S256"], authorization_response_iss_parameter_supported: true (RFC 9207, para que un cliente conectado a varios servidores no confunda de dónde vino un código) y resource_indicators_supported: true (RFC 8707, para que el token se pida explícitamente para este recurso).

Hay un detalle de arquitectura que pasa desapercibido y que importa mucho a los revendedores: todas esas direcciones se generan a partir del origen de la petición. Si un cliente se conecta desde el dominio de un panel hijo, el emisor declarado es ese dominio, y la dirección del panel principal no aparece en ningún punto del flujo.

¿Qué ves en la pantalla de autorización y qué estás aprobando?

La pantalla de autorización vive en la ruta /mcp/connect y es la única parte del flujo donde tú decides algo. No tiene sentido visitarla directamente: solo funciona dentro de una solicitud iniciada por un cliente, y está marcada como no indexable para los buscadores.

Lo que muestra es corto y deliberadamente literal:

• El título con el nombre del cliente que pide entrar, en la forma "X quiere conectarse a tu cuenta".
• Una línea que explica el alcance: "Si lo autorizas, esta aplicación podrá hacer lo siguiente en tu nombre."
• El bloque "Cuenta", con el correo de la cuenta que va a quedar conectada.
• El bloque "Te redirigirá a", con la dirección de retorno exacta a la que se enviará el código.
• La lista de permisos que el cliente ha solicitado.
• La casilla "Dar acceso solo de lectura (sin crear pedidos)".
• Los botones "Autorizar conexión" y "Rechazar".

Dos de esos elementos merecen que te detengas medio segundo. El primero es el correo de la cuenta: si tienes varias cuentas, ahí ves cuál se está conectando de verdad, no la que creías. El segundo es la dirección de retorno: es la prueba visible de a dónde va el código de autorización. Si el nombre del cliente no te suena, o la dirección de retorno apunta a un sitio que no reconoces, el botón correcto es "Rechazar".

Si la solicitud caducó o el cliente no está registrado, verás el mensaje "La solicitud de conexión no es válida o ha caducado. Inténtalo de nuevo desde tu cliente.". No es un fallo de tu cuenta: el código de autorización dura diez minutos y es de un solo uso, así que basta con reiniciar el proceso desde el asistente.

¿Qué apaga exactamente el permiso de "Solo lectura"?

Existen dos permisos, ni uno más: account:read y account:write. Si un cliente no pide ninguno en concreto, se le conceden los dos. Si marcas la casilla de solo lectura en la pantalla de autorización, el token recibe únicamente account:read.

Y aquí está la decisión de diseño que conviene entender bien, porque es la diferencia entre una promesa y una garantía técnica: cuando la conexión es de solo lectura, el servidor no filtra las llamadas, filtra la lista de herramientas. Las seis herramientas de escritura sencillamente no aparecen en la respuesta de tools/list. El modelo no sabe que existen. No puede llamarlas mal, no puede llamarlas "sin querer" y no puede ser convencido de llamarlas por un texto astuto en algún sitio.

La alternativa habitual, decirle al modelo "no llames a esta herramienta", se descartó por una razón muy simple: cumplir una instrucción queda a criterio del modelo, y eso no es un control de seguridad. Quitar la herramienta de la lista sí lo es. Como refuerzo, además, a las instrucciones del servidor se les añade una nota que dice que esa conexión es de solo lectura y que, si quieres pedir, tienes que quitar ese permiso y volver a conectar desde el panel.

Con "Acceso completo"	Con "Solo lectura"
18 herramientas visibles	12 herramientas visibles
Puede crear, cancelar y reponer pedidos	No puede crear, cancelar ni reponer
Puede crear y borrar webhooks	No puede tocar los webhooks
Consulta saldo, catálogo, pedidos y eventos	Consulta saldo, catálogo, pedidos y eventos
Puede previsualizar precios	Puede previsualizar precios

Fíjate en la última fila, porque es la que hace útil el modo de solo lectura: preview_order es una herramienta de lectura. Con una conexión restringida el asistente sigue pudiendo calcularte el importe exacto de cualquier pedido hipotético. Lo único que no puede es ejecutarlo. Para muchos usuarios ese es el punto de equilibrio ideal: la IA investiga y compara, la persona pulsa el botón.

Un apunte técnico menor: si el cliente pide permisos que el panel no reconoce, como openid, profile o email, se descartan en silencio en lugar de romper el flujo.

¿Conviene conectarse con OAuth o con una clave API?

Las dos vías funcionan y el servidor las acepta por igual. La cabecera aceptada es Authorization: Bearer y también se admite X-Api-Key. Los valores válidos son un token OAuth (pf_mcp_...), una clave de la API v3 (pf_live_...) o una clave heredada de revendedor de 64 caracteres hexadecimales. La vía se distingue únicamente por el prefijo del valor.

Hay una regla que no se puede pasar por alto: una conexión hecha con clave siempre es de acceso completo. La restricción de solo lectura solo existe en OAuth, porque es una propiedad del token concedido, no de la clave. Si te importa limitar lo que el asistente puede hacer, la respuesta es OAuth.

Criterio	OAuth 2.1	Clave API
Hay que copiar y pegar algo	No	Sí, la clave
Permiso de solo lectura	Sí, si marcas la casilla	No, siempre acceso completo
Se ve en "Asistentes conectados"	Sí, cliente a cliente	No aparece como conexión
Revocar un solo cliente	Sí, botón "Desconectar"	No, hay que regenerar la clave
Caducidad	Token de 8 horas, renovado automáticamente	Hasta que la revoques
Requisitos del cliente	Compatibilidad con OAuth 2.1	Poder enviar cabeceras HTTP
Bueno para	Asistentes de escritorio y del navegador	Scripts, servidores y automatizaciones sin navegador

En la práctica el criterio es este: si el cliente puede abrir un navegador, usa OAuth. Si el cliente es un proceso en un servidor sin interfaz, un contenedor o un cron, usa clave API, porque ahí no hay nadie que apruebe nada en pantalla. Y si usas clave, trátala igual que una contraseña: quien la tenga puede gastar tu saldo, y no hay forma de saber qué cliente la usó.

¿En qué orden crea un pedido el asistente?

El servidor no se limita a ofrecer herramientas: le impone al modelo un orden de trabajo. Esas instrucciones viajan en el initialize y son la razón por la que un asistente bien conectado no crea pedidos a ciegas.

1. Buscar el servicio con search_services, filtrando por plataforma, categoría o texto, y anotar el número de servicio.
2. Leer la ficha con get_service: mínimo y máximo, soporte de reposición y de cancelación, tiempo medio y campos obligatorios.
3. Calcular el importe con preview_order, y decirte con claridad el valor de charge y el de sufficient_balance.
4. Pedirte confirmación explícita. Sin ella, la instrucción prohíbe llamar a create_order, porque el pedido gasta dinero real y no se puede deshacer.
5. Crear el pedido con create_order y darte el número resultante.

Una conversación real se parece bastante a esto. Tú escribes algo como "quiero tres mil visualizaciones para este reel" y pegas el enlace. El asistente busca servicios de visualizaciones de Instagram, te enseña tres o cuatro opciones con su precio, su rango y si tienen reposición, tú eliges una, él previsualiza el importe, te dice cuánto se descontaría y cuánto saldo quedaría, tú dices que sí y entonces, y solo entonces, se crea el pedido.

Junto al orden, el servidor le comunica al modelo una lista de hechos que evitan los errores clásicos:

• Los importes están en dólares y se devuelven como cadenas decimales, para que el modelo no los convierta a coma flotante y los redondee mal por el camino.
• La cantidad tiene que caber siempre entre el mínimo y el máximo del servicio.
• En los servicios de tipo comentario no se envía cantidad: se escribe un comentario por línea y el número de líneas es la cantidad.
• La cancelación solo es posible si el servicio la admite y el pedido no está completado. La reposición solo es posible en pedidos completados y con garantía.
• El progreso de un pedido se consulta con get_order y los cambios de estado con list_events.
• Los códigos de error son fijos (insufficient_balance, quantity_out_of_range y compañía) y el mensaje llega en tu idioma. La instrucción es tajante: el modelo debe transmitir el mensaje tal cual y no inventarse una solución.

Ese último punto es más importante de lo que parece. Un modelo sin instrucciones tiende a rellenar huecos con explicaciones plausibles. Aquí se le pide justo lo contrario: si el servidor dice "saldo insuficiente", el asistente dice "saldo insuficiente", no "parece que hay un problema temporal, prueba en un rato".

El error de precio más caro: per_1000 frente a per_order

Si solo te llevas una idea técnica de toda esta guía, que sea esta. En las respuestas del catálogo hay un campo pricing.unit que puede valer per_1000 o per_order, y confundirlos multiplica o divide el cálculo por mil.

La inmensa mayoría de los servicios se cobra por cada mil unidades, y ahí pricing.unit vale per_1000. Si el precio es de un dólar y pides cinco mil unidades, el importe es de cinco dólares. Hasta aquí, la intuición funciona.

Pero existen servicios de precio plano, típicamente paquetes cerrados y, en general, servicios cuyo máximo es 1. En esos, pricing.unit vale per_order y el número que ves es el precio total del paquete, no el precio de mil unidades. Un paquete de veinte dólares cuesta veinte dólares, no dos céntimos.

El servidor avisa de esto al modelo con todas las letras, tanto en las instrucciones generales como en la descripción de search_services. Y aun así conviene que tú lo sepas, por una razón muy sencilla: la red de seguridad no es el cálculo del modelo, es preview_order. Esa herramienta no estima nada, consulta el importe real que se descontaría. Si el número que te dice el asistente de memoria y el número que devuelve la previsualización no coinciden, el bueno es el segundo, siempre.

La regla práctica es corta: antes de confirmar cualquier pedido, pide el importe de la previsualización. Si el asistente no te lo ha dado, pídelo con estas palabras: "pásame el charge del preview_order antes de crear nada". Es la misma disciplina que en la interfaz del panel consiste en mirar la fila "Total" antes de pulsar, y está explicada con más detalle en la guía de uso del panel.

Pedidos masivos, drip-feed y tipos de servicio especiales

El asistente no está limitado al pedido estándar. Puede trabajar con todo lo que soporta la API, y eso incluye tres escenarios que merecen explicación aparte.

Pedidos masivos. create_orders_bulk acepta hasta cincuenta elementos por llamada, cada uno con los mismos campos que un pedido individual. Los elementos se procesan en orden y de forma independiente, así que un error en el tercero no impide que se creen el cuarto y el quinto. Cada elemento devuelve su propio resultado, lo que te permite ver exactamente cuál falló y por qué. Si vas a lanzar un lote grande, la práctica sana es pedirle al asistente que previsualice cada línea antes, sume los importes y te enseñe el total; luego decides.

Drip-feed. Los campos son runs (número de tandas) e interval (minutos entre tandas), y solo tienen efecto en servicios que declaran soporte para ello. La trampa clásica del drip-feed es la misma en el asistente que en la interfaz: la cantidad se interpreta por tanda, así que mil unidades en diez tandas son diez mil unidades entregadas y diez mil unidades pagadas. preview_order refleja el importe real, que es otra razón más para no saltárselo. Sobre para qué sirve realmente repartir una entrega en el tiempo, la guía de entrega gradual entra en el detalle.

Tipos de servicio especiales. Cada tipo pide sus propios campos, y el asistente los descubre leyendo la lista fields de get_service. Los campos disponibles son comments (un comentario por línea), username, usernames (uno por línea), hashtag (uno solo), hashtags (uno por línea), answer_number (para encuestas), groups, keywords, media, y para los servicios de suscripción username, posts (entre 1 y 100), min y max por publicación.

Ese último grupo tiene una particularidad de precio que conviene decir en voz alta: en los servicios de suscripción el importe se calcula por el peor escenario, es decir, el máximo por publicación multiplicado por el número de publicaciones, y se cobra por adelantado. Si le pides al asistente un máximo generoso "por si acaso", pagarás ese máximo generoso. La previsualización te lo enseñará antes, si se la pides.

¿Qué no puede hacer el asistente?

Esta lista es tan importante como la de herramientas, porque marca el perímetro real. El propio panel la resume en tres frases en el bloque "Qué puede hacer el asistente":

• "Buscar servicios, calcular precios y ver tus pedidos y tu saldo."
• "Crear pedidos, cancelarlos y pedir recargas (refill). Te pide confirmación antes de crear un pedido."
• "No puede añadir saldo, retirar dinero, ver tu contraseña ni acceder a otras cuentas."

Desglosado, y sin adornos, el asistente no puede:

1. Recargar saldo. No existe herramienta de pago. Si te falta saldo, la respuesta correcta del asistente es decírtelo y mandarte al panel.
2. Retirar dinero. Tampoco existe esa herramienta, ni en modo de acceso completo.
3. Ver tu contraseña. No la tiene. La autorización ocurre en el panel y el cliente nunca recibe credenciales de inicio de sesión.
4. Cambiar precios. El precio del catálogo es el que es; el asistente lo lee, no lo escribe.
5. Abrir tickets de soporte. No hay herramienta de soporte en este servidor. Si algo requiere intervención humana, tienes que abrir el ticket tú, desde el panel.
6. Acceder a otras cuentas. La identidad se resuelve en la cabecera de cada petición. No hay ningún argumento con el que pedir los datos de otro usuario.
7. Cancelar lo que el servicio no deja cancelar. Si features.cancel es falso, la llamada devuelve cancel_not_supported. El asistente no tiene ninguna vía alternativa.
8. Reponer un pedido sin garantía. Si el servicio no incluye reposición, la herramienta no la va a conseguir. Por qué caen los seguidores y qué cubre en realidad una garantía está desarrollado en la guía sobre caídas y reposición.

Vale la pena insistir en el punto 1 porque es el que más gente espera y no está: el asistente puede gastar tu saldo, pero no puede reponerlo. Es una asimetría deliberada. El límite superior de lo que un asistente conectado puede llegar a gastar es, exactamente, el saldo que tengas en la cuenta en ese momento.

Seguridad: qué secretos existen, cómo se guardan y cuánto duran

Todo el flujo de conexión gira alrededor de cinco tipos de secreto. Conocer su duración evita la mitad de las dudas de soporte, porque casi todas las desconexiones inesperadas son en realidad una caducidad haciendo su trabajo.

Secreto	Prefijo	Duración
Código de autorización	pf_mca_	10 minutos, un solo uso
Token de acceso	pf_mcp_	8 horas
Token de refresco	pf_mcr_	90 días, rota en cada uso
Identificador de cliente	mcpc_	sin caducidad
Clave API (v3)	pf_live_	hasta que la revoques

Cuatro propiedades comunes a todos ellos:

Se generan con 32 bytes aleatorios, es decir 256 bits, codificados en base64url. No son secuencias, no son derivados de tu correo y no son adivinables.

En la base de datos solo vive un resumen HMAC-SHA256. El valor en claro no se guarda en ningún sitio. La clave de ese resumen (el pepper) se deriva de PANEL_SECRET_KEY y, si no está definida, de BETTER_AUTH_SECRET. La consecuencia práctica: un volcado de la base de datos no permite reconstruir ningún token.

La reutilización de un código se trata como un incidente. Si un código de autorización se intenta canjear dos veces, o si llega un token de refresco que ya fue revocado, el sistema no se limita a rechazar esa llamada: revoca todos los tokens de ese cliente para esa cuenta. Es la respuesta estándar ante una posible fuga, y es la razón por la que a veces un cliente mal configurado se queda fuera de golpe y hay que reautorizarlo.

El token de refresco rota. Cada vez que se usa, se emite uno nuevo y el anterior deja de valer. Eso limita mucho la ventana de utilidad de un token robado.

Sobre la duración de ocho horas del token de acceso, la lectura correcta es esta: no significa que tengas que reconectar cada ocho horas. El cliente renueva por su cuenta con el token de refresco, en silencio, y tú no ves nada. Solo tendrás que volver a autorizar si el cliente no guarda el refresco, si pasan noventa días sin usarlo o si tú mismo cortas la conexión.

Cada llamada queda registrada: qué guarda el registro de auditoría

Todas las llamadas a herramientas, tanto del servidor de usuario como del de administración, se escriben en la tabla aiAuditLog. El registro guarda el cliente (a partir de su User-Agent), el identificador de la cuenta, el nombre de la herramienta, los argumentos, el resultado, el error si lo hubo y la duración.

Sobre ese registro hay cuatro decisiones que conviene conocer:

1. Los campos con pinta de secreto se enmascaran. Cualquier argumento llamado apikey, api_key, secret, password, passphrase o token se guarda como ***. Un registro de auditoría no debe convertirse en un almacén de credenciales.
2. El resultado de las herramientas de lectura no se guarda. Ocupa muchísimo y aporta poco. El resultado de las herramientas de escritura sí se guarda, porque ahí es donde importa saber qué se creó.
3. El JSON de argumentos y resultados se recorta a 8.000 caracteres. Un lote de cincuenta pedidos no va a llenar el disco.
4. La escritura del registro es best effort. Si por lo que sea no se puede escribir la línea de auditoría, la operación principal no se rompe. Es preferible perder una línea de registro que perder un pedido.

El resultado práctico de todo esto es una propiedad muy concreta y muy útil: se puede saber después si un pedido se creó desde el panel o desde un asistente de IA, y con qué cliente. Si compartes la cuenta con un equipo, o si simplemente quieres reconstruir qué pasó una tarde, ese rastro existe.

Merece la pena decir también qué no hace el registro: no graba tus conversaciones con el asistente. Guarda las llamadas a herramientas y sus argumentos, que es otra cosa. El texto de lo que le escribes a tu modelo se queda entre tú y el cliente que estés usando.

¿Cómo ves los asistentes conectados y cómo los desconectas?

El cuarto bloque de /es/dashboard/mcp se llama "Asistentes conectados" y es tu panel de control de accesos. Si nunca has conectado nada, dice "Todavía no hay ningún asistente de IA conectado."

Cada conexión aparece como una fila con cinco datos:

• El nombre del cliente, tal y como se registró.
• Una insignia que dice "Acceso completo" o "Solo lectura". Es el reflejo directo de lo que decidiste en la pantalla de autorización.
• "Conectado", con la fecha en la que autorizaste.
• "Último uso", con la fecha de la última llamada. Si no ha llegado a usarse, pone "Nunca".
• El botón "Desconectar".

Al pulsar "Desconectar" el navegador te pide confirmación con el texto "Este asistente perderá el acceso a tu cuenta. ¿Continuar?", y al terminar verás "Conexión cerrada.". Si algo falla, el mensaje es "No se pudo desconectar."

Tres hábitos que hacen que esta pantalla valga para algo:

1. Revisa "Último uso" de vez en cuando. Una conexión que autorizaste hace meses y que nunca se ha usado no aporta nada y sí amplía la superficie expuesta. Córtala.
2. Desconecta antes de deshacerte de un equipo. Si cambias de portátil, el cliente de IA que quedó instalado en el antiguo puede seguir teniendo su token de refresco.
3. Ante la duda, corta y vuelve a conectar. Reautorizar cuesta dos clics. No hay penalización por hacerlo, ni pérdida de datos, ni efecto sobre tus pedidos.

Una precisión sobre el alcance de la desconexión: corta ese cliente, no la cuenta. Los demás asistentes conectados siguen funcionando y tu clave API, si tienes una, tampoco se ve afectada. Para revocar una clave hay que ir a /es/dashboard/api y regenerarla, que es una operación distinta.

Límites de peticiones: cuántas llamadas caben por minuto

El servidor MCP no tiene un límite propio: comparte techo con la API v3. Son 600 peticiones por minuto y por cuenta, y da igual si llegan desde un asistente o desde una integración HTTP clásica, porque el contador es el mismo.

Cuando se supera, la respuesta es un HTTP 429 con la cabecera Retry-After: 60. La lectura correcta es literal: espera ese minuto. Reintentar en bucle solo alarga el problema, porque cada reintento cuenta.

Hay además un segundo límite en la capa de la API v3, de 900 peticiones por minuto y por IP. Este rara vez se toca desde un asistente personal, pero puede aparecer si varias cuentas trabajan desde la misma dirección, por ejemplo en una agencia con un servidor compartido.

Para poner esos números en perspectiva: una conversación normal con un asistente hace unas pocas llamadas por pregunta, quizá tres o cuatro, entre buscar, leer la ficha y previsualizar. Seiscientas por minuto es un techo pensado para automatizaciones, no para conversaciones. Si lo estás rozando, lo más probable es que tengas un bucle mal escrito o que estés sondeando el estado de los pedidos mucho más a menudo de lo necesario, y la solución a eso es el flujo de eventos que viene en la sección siguiente.

Automatización: flujo de eventos y webhooks

Consultar el estado de los pedidos uno por uno cada pocos minutos es la forma más cara y menos fiable de enterarse de que algo cambió. El panel ofrece dos alternativas y el asistente maneja las dos.

El flujo de eventos se lee con list_events, del más antiguo al más nuevo, avanzando con cursor. Guardas el último cursor, vuelves más tarde y recibes solo lo que ha pasado desde entonces. Nada se pierde y nada se repite.

Tipo de evento	Cuándo se emite
order.created	Se ha creado un pedido
order.processing	El proveedor lo ha aceptado y lo está ejecutando
order.completed	Se ha entregado por completo
order.partial	Se ha entregado solo una parte
order.canceled	El pedido se ha cancelado
order.updated	Ha cambiado algún dato del pedido
refill.created	Se ha creado una solicitud de reposición
refill.updated	Ha cambiado el estado de una reposición

Esos nombres no se traducen en ningún idioma del panel: son identificadores.

Los webhooks son la otra vía. Con create_webhook das de alta una dirección https a la que se enviarán los eventos, opcionalmente filtrando qué tipos quieres recibir y con una descripción corta. Hay un detalle crítico en la respuesta: el secreto de firma se muestra una sola vez. Es el valor con el que se firman los envíos para que tu servidor pueda verificar que vienen de verdad del panel. Si no lo guardas en ese momento, no hay forma de volver a verlo y tendrás que crear el webhook de nuevo.

list_webhooks te enseña las direcciones dadas de alta, los eventos a los que están suscritas y los resultados de los últimos envíos, lo que resulta muy práctico para depurar cuando tu servidor devuelve errores. delete_webhook borra una dirección de forma permanente y descarta también los envíos que estuvieran pendientes.

La regla para elegir entre las dos vías es sencilla: si puedes recibir peticiones entrantes, usa webhooks; si no, usa el flujo de eventos. Quien desarrolla en local, quien no tiene IP fija o quien no quiere exponer un endpoint público llega a la misma información con list_events y un cursor guardado. Ninguna de las dos es mejor en abstracto, dependen de tu infraestructura. La referencia completa de eventos y firmas está en la documentación de la API.

Comandos preparados: order_status, find_service y reorder

Además de las herramientas, el servidor publica tres comandos preparados que los clientes muestran como atajos. En MCP se llaman prompts, y su función es empaquetar una instrucción larga y bien redactada para que no tengas que escribirla tú cada vez.

Comando	Qué hace	Argumentos
order_status	Resume tus últimos pedidos y señala los atascados o incompletos	count (10 por defecto)
find_service	Compara entre tres y cinco servicios para una petición y calcula el precio, sin crear nada	request (obligatorio), quantity
reorder	Repite un pedido anterior, previa confirmación	order_id (obligatorio)

Vale la pena detallar qué hace cada uno por debajo, porque son un buen ejemplo de cómo se le puede pedir algo concreto a un asistente.

order_status llama a list_orders con el límite que le pases e incluyendo los datos del servicio, y luego te enumera cada pedido con su número, su servicio, su estado, su cantidad, lo que queda y el importe. Además resalta los que no se han completado o los que traen un error del proveedor, y para cada uno sugiere la vía disponible (cancelar, reponer o esperar). Es el sustituto natural de abrir "Mis pedidos" y leer la tabla a ojo.

find_service toma tu petición en lenguaje natural, busca en el catálogo y te presenta una comparación de tres a cinco servicios por precio, mínimo y máximo, garantía de reposición y tiempo medio. Si le das una cantidad, además previsualiza el importe del que le parezca más adecuado. Y hay una restricción escrita en el propio comando: no crea el pedido. Solo presenta opciones y deja la decisión en tus manos.

reorder lee un pedido pasado con get_order, monta la misma combinación de servicio, enlace y cantidad, la pasa por preview_order para enseñarte el precio actual (que puede no ser el de entonces) y te pide confirmación. Si dices que no, no hace nada. Y si detecta que ya hay un pedido en marcha sobre ese mismo enlace, te avisa antes, que es exactamente el aviso que uno agradece.

Si tu cliente no muestra los comandos preparados, no pasa nada: puedes pedir lo mismo con palabras. Los comandos son comodidad, no capacidad.

¿Qué cambia para revendedores y propietarios de paneles hijos?

Si tienes un panel de marca blanca montado sobre esta infraestructura, tus clientes también pueden conectar sus propios asistentes, y lo hacen contra tu dominio, no contra el principal.

Esto no es un detalle cosmético. Como todas las direcciones del flujo OAuth se generan a partir del origen de la petición, el emisor declarado en los documentos de descubrimiento, el endpoint de autorización, el de token y la pantalla de autorización son todos de tu dominio. Un cliente tuyo que conecte Claude o Cursor a su cuenta no verá en ningún punto del proceso la dirección del panel principal.

Las páginas también son las tuyas: tus clientes tienen su propia "Asistente IA" en su panel, con la dirección de conexión de tu dominio, sus propios ejemplos de configuración y su propia lista de asistentes conectados.

Una consecuencia operativa que conviene tener presente, porque genera tickets: una cuenta creada en un panel hijo solo existe en el dominio de ese panel. Si un cliente tuyo intenta conectar su asistente apuntando a la dirección del panel principal, no va a encontrar su cuenta. El síntoma que verás es "no encuentra mi cuenta" y la causa casi siempre es esa. La solución es usar la dirección correcta, que es la que aparece en su propio panel.

Para quien esté valorando montar este modelo, la página de panel hijo explica la propuesta y la guía de reventa SMM cubre la parte comercial. Y si tu caso es revender sin montar tu propia marca, la página de panel para revendedores describe la alternativa más ligera. Para agencias que gestionan muchas cuentas de cliente a la vez, el ahorro de tiempo del asistente se nota sobre todo en la fase de comparar y presupuestar, un tema que la guía de escalado de agencias trata desde el lado del proceso.

Del lado del propietario: el servidor de administración

Este apartado es corto a propósito y solo interesa a quien administra un panel. Se incluye porque explica una cosa que a los clientes les da confianza: el panel se gestiona con el mismo protocolo y con la misma disciplina de registro que se aplica a los clientes.

El servidor de administración está en POST /api/mcp, se autentica con una única clave secreta (MCP_SECRET) y publica 57 herramientas. Si esa clave no está definida, el endpoint no existe a efectos prácticos: responde 503 y no hay forma de llamarlo. La clave se puede enviar como Authorization: Bearer, como cabecera X-MCP-Secret o como parámetro ?key=, y la comparación se hace en tiempo constante.

Sus herramientas cubren visión general y búsqueda, auditoría, usuarios, pedidos, solicitudes de pedido, servicios, categorías, proveedores, pagos, tickets de soporte, cupones y ajustes. Con protecciones explícitas: el último administrador activo no puede perder su rol ni ser bloqueado, las operaciones con dinero son atómicas (transacción más bloqueo de fila) y cada llamada se escribe en el mismo registro de auditoría.

¿MCP, API o panel? Cuándo usar cada uno

Las tres vías llevan al mismo sitio y ninguna sustituye a las otras. Esta tabla resume para qué es buena cada una.

Situación	Panel web	API v3	Asistente por MCP
Un pedido puntual, sabiendo ya qué servicio quieres	La más rápida	Innecesaria	Válida, pero da un rodeo
Comparar quince servicios por precio y garantía	Lenta y tediosa	Requiere programar	La mejor con diferencia
Cientos de pedidos automáticos cada día	Inviable	La correcta	Posible, pero no es su terreno
Integrar el panel en tu propia web o tu CRM	No aplica	La correcta	No aplica
Revisar el estado de los pedidos de la semana	Válida	Requiere programar	Muy cómoda, con order_status
Recargar saldo	La única vía	No disponible	No disponible
Abrir un ticket de soporte	La única vía	No disponible	No disponible
Trabajar con permiso de solo lectura	No aplica	No aplica	Disponible, marcando la casilla

La combinación que mejor funciona en la práctica es usar las tres: el asistente para investigar y decidir, la API para lo repetitivo y el panel para todo lo que toca dinero de entrada o requiere una persona. El catálogo completo, por si prefieres mirarlo con tus propios ojos antes de preguntarle a nadie, está en la página de servicios, y la referencia de la API de revendedor en la página de la API.

Resolución de problemas: errores frecuentes y qué significan

Casi todos los problemas de una conexión MCP caen en una de estas ocho casillas. La tabla traduce el síntoma a su causa real.

Síntoma	Causa	Qué hacer
401 invalid_token	El token de acceso ha superado sus 8 horas	El cliente lo renueva solo con el token de refresco; si no lo hace, vuelve a conectar desde el panel
HTTP 405 en el navegador	Se ha intentado un GET esperando SSE	El protocolo solo acepta POST
HTTP 429	Se han superado las 600 peticiones por minuto	Espera lo que indique Retry-After
"La solicitud de conexión no es válida o ha caducado."	Han pasado los 10 minutos del código, o el cliente no está registrado	Reinicia el proceso desde el cliente
El endpoint de token responde 400	El cliente ha enviado PKCE en modo plain	Solo se acepta S256
La redirección se rechaza	El redirect_uri no coincide con el registrado	La única flexibilidad admitida es el puerto de loopback
El endpoint responde 503	En el servidor de administración no está definido MCP_SECRET	Solo afecta al propietario del panel
"No encuentra mi cuenta"	La cuenta se creó en un panel hijo y solo existe en ese dominio	Conecta desde el dominio correcto

Dos consejos de diagnóstico que ahorran tiempo. El primero: antes de sospechar del panel, prueba tools/list con curl. Si esa llamada devuelve la lista de dieciocho herramientas, el servidor está bien y el problema está en la configuración de tu cliente. El segundo: si ves doce herramientas en vez de dieciocho, no hay ningún fallo, tu conexión es de solo lectura. Desconéctala desde "Asistentes conectados" y vuelve a autorizar sin marcar la casilla.

Una rutina de trabajo con el asistente que evita sustos

Si tuvieras que quedarte con una sola parte práctica de esta guía, que sea esta lista. Es el orden que evita casi todos los problemas.

Al conectar:

1. Conecta primero en modo solo lectura y trabaja así unos días. Vas a descubrir que la mayoría de lo que le pides al asistente es investigación, no ejecución.
2. Comprueba en la pantalla de autorización que el correo mostrado es el de la cuenta correcta y que la dirección de retorno es la de tu cliente.
3. Después de conectar, entra en "Asistentes conectados" y verifica que la insignia dice lo que esperabas.

Al pedir:

4. Pide siempre el importe de la previsualización antes de confirmar, con estas palabras: "enséñame el charge del preview_order".
5. Comprueba que el enlace que el asistente va a usar es el que tú quieres, y que apunta a lo que compras (un perfil para seguidores, una publicación concreta para visualizaciones).
6. Pregunta explícitamente si el servicio elegido tiene reposición y cancelación. El asistente lo sabe porque lo lee de get_service, pero puede no decírtelo si no se lo pides.
7. Con lotes, pide el total sumado antes de lanzar nada. Cincuenta pedidos mal calculados son cincuenta errores.

Después:

8. Usa order_status en vez de preguntar de uno en uno. Es una llamada en lugar de veinte.
9. Si un pedido lleva demasiado tiempo en estado pendiente, abre un ticket desde el panel. El asistente no puede abrirlo por ti.
10. Revisa cada cierto tiempo la lista de asistentes conectados y corta los que ya no uses.

Y la regla de fondo, la que no está en ninguna herramienta: el asistente ejecuta compras, no estrategia. Lo que convierte números en resultado sigue siendo lo que publicas y cuándo lo publicas. Si estás empezando y quieres el otro lado de la ecuación, las preguntas frecuentes del sitio y la página de cómo funciona resumen la parte no técnica, y crear la cuenta desde la página de registro lleva menos de un minuto.

Preguntas Frecuentes

¿Qué es MCP, en una frase?

MCP (Model Context Protocol) es un protocolo abierto que define cómo un asistente de IA descubre y usa las herramientas de un servicio externo. En un panel SMM significa que tu asistente puede buscar servicios, calcular precios, crear pedidos y consultar su estado dentro de tu cuenta, llamando a funciones reales en vez de leer páginas web. El panel expone su servidor MCP en POST /api/mcp/user y la página para conectarlo es "Asistente IA" en el menú lateral.

¿Tengo que darle mi contraseña del panel al asistente?

No. La autorización ocurre en el panel, dentro de tu navegador y de tu sesión, y el cliente de IA nunca recibe credenciales de inicio de sesión. Lo que recibe es un token con permisos acotados que tú puedes revocar en cualquier momento desde "Asistentes conectados". La nota del propio panel lo dice así: la autorización se hace en el panel y tu contraseña nunca se comparte con el cliente.

¿Puede el asistente hacer un pedido sin mi permiso?

Las instrucciones del servidor le obligan a calcular el importe con preview_order y a pedirte confirmación explícita antes de llamar a create_order. Si quieres una barrera técnica en lugar de una instrucción, marca la casilla "Dar acceso solo de lectura (sin crear pedidos)" al autorizar: en ese caso las seis herramientas de escritura ni siquiera aparecen en la lista que ve el modelo, así que no puede llamarlas de ninguna manera. Y en cualquier caso, el gasto máximo posible está acotado por el saldo de tu cuenta, porque el asistente no puede recargarlo.

¿Qué clientes de IA son compatibles?

Cualquier cliente que hable MCP sobre Streamable HTTP. Los que soportan OAuth 2.1 se conectan sin copiar nada, y los que pueden enviar cabeceras HTTP pueden usar una clave API. El panel incluye ejemplos listos para Claude Code, para clientes que se configuran con un archivo JSON como Cursor o VS Code, y para curl. Lo que no funciona es un cliente que exija un flujo SSE, porque el servidor no lo ofrece.

¿Cómo desconecto un asistente y qué pasa después?

En /es/dashboard/mcp, dentro de "Asistentes conectados", cada fila tiene un botón "Desconectar" que pide confirmación con el texto "Este asistente perderá el acceso a tu cuenta. ¿Continuar?". Al confirmar, ese cliente pierde el acceso de inmediato y sus tokens dejan de valer. No afecta a los demás asistentes conectados, ni a tus pedidos, ni a tu clave API, y puedes volver a conectarlo cuando quieras repitiendo el proceso.

¿Cuánto dura el acceso? ¿Tengo que reconectar a menudo?

El token de acceso dura ocho horas, pero eso no significa que tengas que hacer nada cada ocho horas. El cliente lo renueva por su cuenta con un token de refresco que dura noventa días y que rota en cada uso. Solo tendrás que volver a autorizar si el cliente no guarda ese refresco, si pasan noventa días sin usarlo, si tú cortas la conexión o si el sistema detecta una reutilización sospechosa de un código.

¿Puede el asistente recargar mi saldo?

No, y es una limitación deliberada. No existe ninguna herramienta de pago en el servidor de usuario, ni siquiera con acceso completo, así que el asistente puede gastar saldo pero no puede reponerlo. Si te falta saldo, lo que hará es decírtelo y remitirte al panel, donde la recarga sigue siendo una operación manual con los métodos de pago activos.

¿Me conecto con OAuth o con clave API?

Si tu cliente puede abrir un navegador, usa OAuth: no tienes que copiar nada, la conexión aparece en la lista de asistentes conectados y puedes revocarla cliente a cliente. Usa clave API cuando el cliente sea un proceso sin interfaz, un servidor o una tarea programada, porque ahí no hay nadie que apruebe nada en pantalla. Ten en cuenta que una conexión hecha con clave siempre es de acceso completo: el permiso de solo lectura solo existe en OAuth.

¿Puedo ver en el panel los pedidos que ha hecho el asistente?

Sí, y sin ninguna diferencia con los demás. Los pedidos creados por MCP aparecen en "Mis pedidos" como cualquier otro, con su número, su estado y su importe. Además, cada llamada a una herramienta queda escrita en el registro de auditoría con el cliente que la hizo, así que después se puede saber si un pedido se creó desde el panel o desde un asistente.

¿Los clientes de un panel de marca blanca también pueden conectar su asistente?

Sí, y lo hacen contra el dominio de ese panel. Las direcciones del flujo OAuth se generan a partir del origen de la petición, así que el emisor, los endpoints y la pantalla de autorización son los del dominio del panel hijo, y la dirección del panel principal no aparece en ningún momento. La consecuencia importante es que una cuenta creada en un panel hijo solo existe en ese dominio: si se intenta conectar apuntando a otro, la cuenta no se encuentra.

¿Qué pasa si una herramienta devuelve un error?

No se rompe nada. Los errores de herramienta se devuelven como texto con la marca isError: true, no como errores de protocolo, precisamente para que el modelo pueda leerlos y corregirse. Los códigos son fijos, por ejemplo insufficient_balance o quantity_out_of_range, y el mensaje llega en tu idioma. Las instrucciones del servidor le piden al modelo que te transmita ese mensaje tal cual y que no se invente una solución.

¿Usar MCP tiene algún coste adicional?

No hay ningún cargo extra por conectar un asistente ni por usar las herramientas: lo único que se cobra es el precio del pedido que decidas crear, exactamente igual que si lo hicieras desde el panel. Las consultas de catálogo, las previsualizaciones de precio y las listas de pedidos no descuentan nada del saldo. Ten en cuenta, eso sí, que el cliente de IA que uses puede tener su propio coste, y eso ya depende de tu proveedor, no del panel.