SMS MCP para alertas de reseñas: pruebas en Maps y tiendas de apps

El 14 de noviembre de 2026, entre las 00:16 y las 03:30 hora de Singapur, consultamos más o menos cada hora cuatro fuentes de reseñas: Google Maps para Joe's Pizza y el DMV de Los Ángeles, y DoorDash en App Store y Google Play. Tenemos 3 consultas de Maps y de Google Play, y 4 de App Store.

La prueba completa sumó 21 llamadas cobradas por 0,029167 USD. De ellas, 13 fueron consultas periódicas. Las otras 8 fueron 3 búsquedas de lugares, 1 muestra que luego cambiamos y una llamada para cada una de estas pruebas: idempotencia, MCP, la comparación con MyChart y el script.

Solo Google Play trajo reseñas nuevas entre consultas. La reseña «más reciente» de App Store tenía entre 28,8 y 31,9 horas al momento de consultar. La comparamos con la fuente pública de reseñas de la propia Apple, y la primera entrada era la misma. Joe's Pizza devolvió en la primera consulta 20 reseñas repartidas en 35,7 horas, con un intervalo mediano de 0,61 horas, pero también con un hueco de 9,75 horas. En las dos consultas siguientes, dos horas en total, no apareció ninguna reseña nueva.

Por eso la frecuencia se decide por fuente. Un local concurrido en Maps se revisa cada hora, por unos 1,00 USD al mes por fuente. Un lugar tranquilo o una tienda de apps se revisa una vez al día, por unos 0,042 USD al mes.

La deduplicación se hace por ID de reseña: las 297 filas que se repitieron entre consultas conservaron exactamente el mismo ID. Las tareas programadas van por REST con una Idempotency-Key; si se reenvía la misma petición en la misma hora, la API devuelve la respuesta guardada y no cobra de nuevo. Las API de SMS no tienen clave de idempotencia, así que una cola local se encarga de que cada reseña genere un solo mensaje.

Del lado del SMS, TrueDialog lanzó el 10 de noviembre un servidor MCP que envía mensajes desde Claude y ChatGPT. El servidor MCP de la propia Twilio solo busca documentación. No enviamos SMS reales, así que cada paso de envío es un ejemplo de configuración.

El trabajo: un SMS cuando aparece una mala reseña

El volumen de reseñas de 1 y 2 estrellas cambia muchísimo de un caso a otro. Según nuestra estimación, DoorDash recibe unas 94 al día entre sus dos tiendas, y el DMV de Los Ángeles en Google Maps, menos de una.

Google Maps, App Store y Google Play avisan a los dueños, pero lo hacen por correo, por una bandeja dentro de una app o por una consola para desarrolladores. El SMS llega a casi cualquier teléfono y se ve en la pantalla bloqueada. A cambio, cuesta dinero, pide un número registrado y obliga a seguir las reglas de los operadores.

Esta guía resuelve una tarea concreta: revisar cada hora o cada día las reseñas más nuevas de ciertos locales y apps, detectar las reseñas nuevas de 1 o 2 estrellas y mandar un SMS a la persona de turno. Cada reseña genera como máximo un mensaje, y cada revisión cuesta como máximo una llamada de datos.

La tarea tiene tres partes. La primera lee reseñas con tres capacidades de EveryInfra, google_maps_reviews/reviews, app_store/reviews y google_play/reviews, y trae las 20 a 50 más recientes.

La segunda las compara con las vistas la vez anterior, se queda con las nuevas y filtra por estrellas. La tercera manda el SMS a través de un servidor SMS MCP o de la API de un proveedor de SMS. MCP es un protocolo abierto que permite a los asistentes de IA usar herramientas externas (modelcontextprotocol.io).

Las dos primeras partes las ejecutamos de verdad el 14 de noviembre de 2026. La tercera necesita una cuenta de SMS, un número registrado y el permiso de quien recibe el mensaje. No enviamos ningún SMS, así que esa parte es un ejemplo de configuración basado en las páginas y la documentación de cada proveedor.

Elegimos cuatro muestras de tamaño muy distinto. Joe's Pizza Broadway, cerca de Times Square en Nueva York, es un local con mucho movimiento y 27.620 reseñas en Google Maps. La oficina del DMV de California en Hope Street, Los Ángeles, es una ventanilla de servicio público con 2321 reseñas y 3,1 estrellas de media. DoorDash representa una app con muchísimas reseñas, y la consultamos en App Store y en Google Play.

La app de portal del paciente MyChart representa el sector salud. La consultamos una sola vez, como comparación con otro sector. Todos estos lugares y apps son públicos. Nunca publicamos nombres ni fotos de quienes escriben las reseñas.

Qué servidores SMS MCP existen y cuáles pueden enviar

En el autocompletado de Google, «sms mcp» muestra variantes como «sms mcp server», «claude sms mcp» y «sms api mcp» (autocompletado de Google, leído el 2026-11-14). Tres productos llevan el nombre MCP: uno puede enviar SMS, otro solo busca documentación y el tercero corre en tu propio equipo.

Tomamos un ejemplo de cada tipo a partir de las páginas de cada proveedor: un servidor MCP alojado por una plataforma de SMS, un servidor de búsqueda de documentación de una empresa de API de SMS y un servidor local del laboratorio de esa misma empresa.

El primero es TrueDialog, una plataforma de SMS para empresas con sede en Austin, Texas. Lanzó TrueDialog MCP el 10 de noviembre de 2026. El comunicado dice que personas y agentes de IA pueden enviar SMS y mensajes RCS y gestionar contactos desde ChatGPT, Copilot, Claude, Gemini, Perplexity y otros asistentes.

Ya figura en el directorio de apps de ChatGPT y en el catálogo de conectores de Microsoft Copilot. Los demás asistentes se conectan a través de tdmcp.com (comunicado en PR Newswire; página del producto en truedialog.com/features/mcp). El comunicado añade un dato útil para las cuentas: el acceso por MCP se cobra a la tarifa estándar de TrueDialog, sin cargo aparte por MCP.

El inicio de sesión usa OAuth 2.1. El cliente encuentra el servidor de autorización en auth.tdmcp.com, la persona inicia sesión en su cuenta de TrueDialog desde el navegador y el cliente solo recibe un token de corta duración. Nadie pega una clave (configuración en tdmcp.com). El punto de acceso es https://connect.tdmcp.com, y también funciona con /mcp al final.

El segundo es el servidor MCP de la propia Twilio. Salió en beta pública el 7 de mayo de 2026 en mcp.twilio.com/docs, y no pide cuenta ni inicio de sesión (blog de Twilio).

Tiene dos herramientas, twilio__search y twilio__retrieve, que buscan y devuelven la documentación de parámetros de más de 1800 endpoints. La documentación dice que el servidor es de solo lectura y que no llama a las API por ti (documentación de Twilio MCP). Puede ayudar a un asistente de programación a escribir el código que envía un SMS con Twilio, pero no puede enviarlo. La documentación pone las herramientas que llaman a las API con OAuth en su lista de «próximos pasos».

El tercero es el paquete @twilio-alpha/mcp de Twilio Labs. Se inicia en tu equipo con npx, pasándole el SID de la cuenta y una clave de API. Convierte las API públicas de Twilio en herramientas MCP, incluido el envío de SMS (repositorio twilio-labs/mcp en GitHub).

El último commit en GitHub es del 7 de julio de 2025, y la versión más reciente en npm, la 0.7.0, salió ese mismo día (página del paquete en npm). El README desaconseja ejecutar servidores MCP de la comunidad junto a los oficiales, para que un ataque de inyección no llegue a las herramientas de tu cuenta de Twilio.

La página del conector en Microsoft Learn enumera diez herramientas y siete limitaciones (Microsoft Learn: conector TrueDialog MCP). Seis herramientas solo leen y cuatro escriben. Solo send_sms llega a un teléfono.

send_sms usa execute=true por defecto. Con execute=false hace una prueba que no envía nada ni gasta créditos, aunque sí crea un registro de campaña. Una sola llamada admite muchos destinatarios, así que una frase puede disparar muchos mensajes.

La primera limitación conocida es «solo salida»: el servidor no puede leer respuestas ni conversaciones. Tampoco admite campañas programadas ni recurrentes, y cada envío es inmediato. Las obligaciones de baja, 10DLC y TCPA siguen siendo del titular de la cuenta. El parámetro force_opt_in permite escribir a contactos que se dieron de baja, y la página pide usarlo solo con base legal.

Microsoft Learn y tdmcp.com no dan el mismo número de herramientas. Microsoft Learn enumera diez, incluida report_issue, que manda un informe de problema al correo de soporte de TrueDialog. La sección de herramientas de tdmcp.com enumera nueve, seis de lectura y tres de escritura, sin report_issue.

Microsoft Learn menciona además un paquete opcional de herramientas inbox_* de bandeja de entrada para conversaciones por SMS; cuando está activo, send_sms corresponde a inbox_sms_send. tdmcp.com explica que esas herramientas dependen de cada despliegue y que connect.tdmcp.com publica solo las nueve. No tenemos cuenta de TrueDialog y no pudimos contar tools/list por nuestra cuenta. Damos las dos fuentes; vale la lista que veas al conectarte.

Una alerta de reseñas necesita tres cosas: enviar, probar sin enviar y fijar el número remitente. TrueDialog MCP tiene las tres. No lee respuestas, pero eso no afecta a una alerta de un solo sentido.

El servidor MCP de Twilio hoy solo ayuda a escribir código. Si ya usas Twilio, deja que el script programado llame a su API de Messages y que el asistente de IA escriba el resumen.

Qué avisan ya las plataformas por su cuenta

Antes de escribir un sondeo, conviene ver si los avisos de la propia plataforma resuelven el trabajo. Solo Google Business Profile envía reseñas nuevas en tiempo real, y solo al dueño verificado. La lista de notificaciones de Apple no tiene un aviso de «reseña nueva». La API de Google Play solo devuelve las reseñas de la última semana.

La ayuda de Google Business Profile explica que el dueño puede activar avisos de reseñas y fotos nuevas en «Actividad de clientes». Llegan por correo, en la Búsqueda y en la app de Maps (Ayuda de Google Business Profile: gestionar notificaciones).

Los desarrolladores también pueden enviar eventos de reseñas nuevas y actualizadas a un tema de Cloud Pub/Sub con la My Business Notifications API (configuración de notificaciones en tiempo real, página actualizada el 2026-08-28; referencia de NotificationSetting). Hace falta ser dueño del perfil y configurar Pub/Sub y OAuth en Google Cloud. Para el texto completo se llama después a accounts.locations.reviews.list (guía de datos de reseñas).

App Store Connect tiene siete tipos de notificación para usuarios. Solo «Developer Response» tiene que ver con reseñas: manda un correo cuando alguien edita una reseña que ya respondiste (Ayuda de App Store Connect: notificaciones). Las reseñas nuevas no están en la lista.

Para leer reseñas completas, un desarrollador puede llamar al endpoint Customer Reviews de la API de App Store Connect, filtrar por territorio y estrellas y ordenar por fecha (documentación de Apple: Customer Reviews). La app tiene que estar en tu cuenta de desarrollador.

El endpoint «Reply to Reviews» de la Google Play Developer API lista y responde reseñas. Cada página trae 10 por defecto y 100 como máximo. La documentación dice que solo devuelve reseñas creadas o editadas en la última semana, y solo las que tienen texto; las que solo tienen estrellas no aparecen.

La cuota de lectura es de 200 llamadas por hora (Google Play Developer API: Reply to Reviews). Las reseñas más antiguas se descargan en CSV desde Play Console.

Si los locales que vigilas no están en tu cuenta, el aviso oficial no sirve. Es el caso de una gerente regional que sigue tiendas franquiciadas o de una agencia que sigue los locales de sus clientes. En App Store, ni siquiera tu propia app recibe avisos de reseñas nuevas.

En Reddit, alguien preguntó en r/smallbusiness cómo vigilar reseñas de Google de negocios que no son suyos, y las respuestas coinciden en que Google solo permite vigilar los propios (hilo de Reddit r/smallbusiness). La Places API devuelve como máximo 5 reseñas por lugar (Places API Place Details), muy pocas para saber si una reseña es nueva.

Consultas reales: ¿cada cuánto aparecen reseñas nuevas?

Consultamos las cuatro muestras en tres momentos: de 00:16 a 00:20, de 01:19 a 01:20 y de 02:19 a 02:20, hora de Singapur. A las 03:20 volvimos a consultar App Store. Los parámetros fueron siempre los mismos.

Esa ventana equivale a las 11 de la mañana a las 2 de la tarde del 13 de noviembre en Nueva York, y de 8 a 11 de la mañana en Los Ángeles: los locales y las ventanillas estaban abiertos. Cada consulta usó sort=newest y trajo las 20 a 50 filas más recientes.

Guardamos el ID, las estrellas y posted_at de cada reseña. Después comparamos cada consulta con las anteriores y contamos las reseñas nuevas y las nuevas de 1 o 2 estrellas. Cada fila de la tabla es una llamada real con éxito, cobrada a 0,001389 USD.

Joe's Pizza devolvió en la primera consulta 20 reseñas del 12 al 13 de noviembre de 2026. Abarcan 35,7 horas y el intervalo mediano entre dos reseñas es de 0,61 horas, lo que da unas 12,8 reseñas al día. Entre esas 20 también hay dos huecos largos, uno de 7,7 horas y otro de 9,75 horas.

Las dos consultas siguientes devolvieron las mismas 20 reseñas, es decir, no hubo ninguna nueva en las dos horas que observamos. Para una alerta de reseñas, eso significa que una revisión cada hora casi siempre trae las mismas reseñas.

El DMV de Los Ángeles estaba más tranquilo. Sus 20 reseñas van del 2026-10-20 al 2026-11-12, es decir, 551 horas, o 0,8 reseñas al día. El intervalo mediano es de 14,6 horas y el hueco más largo, de 117,8 horas. Las tres consultas fueron idénticas. Para un lugar así basta una revisión diaria; revisar más seguido solo vuelve a pagar por las mismas filas.

En App Store, DoorDash devolvió las mismas 50 reseñas en las 4 consultas. La más reciente siempre fue la publicada el 2026-11-12T11:26:35Z (19:26 del 12 de noviembre, hora de Singapur). Al momento de consultar tenía 28,8 horas en la primera consulta y 31,9 horas en la cuarta.

Para saber si eso dependía de la plataforma o de un retraso nuestro, a las 01:21 hora de Singapur leímos la fuente pública de reseñas de la propia Apple: el feed RSS customerreviews de itunes.apple.com para DoorDash en EE. UU., ordenado por más recientes. Su primera entrada tiene updated 2026-11-12T04:26:35-07:00 y 1 estrella. En UTC es el mismo momento y la misma calificación que la reseña más reciente de nuestra respuesta.

O sea, la lista pública de «más recientes» de Apple también tenía más de un día en ese momento, y consultar más seguido no lo cambia. La reseña más reciente de MyChart en App Store era de las 19:35 del 12 de noviembre, hora de Singapur: solo 9 minutos después que la de DoorDash.

En Google Play, la segunda consulta de DoorDash (01:20 del 2026-11-14) trajo 7 reseñas nuevas entre 40, y 5 de ellas tenían 1 estrella. La tercera trajo 34 ID ya vistos y 6 ID nuevos; de las nuevas, tres tenían 1 estrella y una, 2 estrellas.

La lista viene ordenada por más recientes. En las dos consultas, las reseñas nuevas salieron primero, antes de todas las que ya habíamos visto, así que eran reseñas que acababan de entrar en la lista de «más recientes» en esa hora. De las cuatro fuentes, solo Google Play tuvo reseñas nuevas entre cada par de consultas.

Las consultas se repitieron en 297 filas en total (20+20+20+20+50+50+50+33+34). Cada reseña repetida mantuvo exactamente el mismo ID. Ninguna volvió con el mismo autor, la misma hora y el mismo texto bajo otro ID. En Google Play, el único par con el mismo texto y distinto ID era de dos usuarios diferentes que escribieron una sola palabra, «expensive». Así que el ID de reseña es una clave segura para deduplicar en las cuatro fuentes.

La marca de tiempo no sirve como clave por dos motivos. Primero, los autores editan sus reseñas: la documentación de Google Play devuelve juntas las reseñas «creadas o editadas». Segundo, hay reseñas que llegan tarde. Nuestro artículo BL-79 registró una reseña con posted_at anterior a la consulta previa, que sin embargo esa consulta no había devuelto. Una regla de «publicada después de la más reciente que vi» se la habría saltado.

En estas horas solo Google Play trajo reseñas nuevas; los dos lugares de Maps y App Store, ninguna. Por eso las cifras de «reseñas nuevas al día» de la sección siguiente salen de los intervalos entre valores de posted_at vecinos dentro de una sola respuesta. Son estimaciones.

La fila de DoorDash (Google Play) usa las 47 reseñas de las consultas 1 y 2. La columna del hueco más largo muestra que incluso una fuente con un intervalo mediano de menos de una hora puede pasar varias horas sin reseñas nuevas. Una hora sin reseñas nuevas es normal.

Dos claves de idempotencia: un cobro por hora, un SMS por reseña

El sondeo tiene dos accidentes típicos. Una misma revisión se reenvía varias veces y se cobra varias veces. O una misma reseña mala le manda varios SMS al dueño.

Los dos tienen la misma causa: el script reintenta tras un tiempo de espera, dos tareas programadas se solapan o el proceso se cae y vuelve a arrancar. En el momento de reenviar, el cliente no sabe si el primer intento funcionó. Y la solución también es la misma: darle a cada acción lógica un nombre estable, y que el servidor o una tabla local la ejecute una sola vez por nombre.

Del lado de los datos, POST /api/v1/social de EveryInfra acepta una cabecera Idempotency-Key de 1 a 255 caracteres ASCII visibles. Durante 24 horas, la misma petición con la misma clave devuelve la primera respuesta exitosa. No se vuelve a ejecutar ni se vuelve a cobrar.

El cuerpo lleva replayed: true y la cabecera, Idempotent-Replayed: true. La misma clave con otros parámetros devuelve 409 idempotency_conflict (llms-full.txt de EveryInfra, Retries and idempotency; la misma cabecera y el mismo código de error están en openapi.json).

Armamos la clave con el nombre de la fuente y la hora UTC, por ejemplo alert:gmaps:la-dmv-hope-st:2026111316. Por muchas veces que el script se vuelva a ejecutar dentro de esa hora, paga una sola vez. A la hora siguiente la clave cambia y el script lee las reseñas nuevas como siempre. Las tareas programadas y cualquier llamada que reintente por su cuenta van por esta ruta REST. Nuestras pruebas de claves de idempotencia (BL-115) cubren el resto de los casos de reintento.

A las 00:35:02 y 00:35:10 hora de Singapur mandamos dos veces la misma petición del DMV con la misma clave. La primera devolvió HTTP 200 con 10 reseñas y costó 0,001389 USD. La segunda devolvió HTTP 200 con la cabecera idempotent-replayed: true, el campo replayed: true en el cuerpo y las mismas 10 reseñas.

Luego revisamos el registro de peticiones de la cuenta con la herramienta MCP everyinfra_list_requests. La primera llamada tenía un cobro registrado; la segunda no añadió ningún cobro nuevo.

Del lado del SMS la situación cambia. En la documentación del recurso Message de Twilio (Twilio Message resource, leída el 14 de noviembre), los parámetros de creación no incluyen clave de idempotencia: dos POST del mismo texto son dos SMS y dos cobros. El send_sms de TrueDialog tampoco muestra un parámetro de idempotencia en la página del conector ni en tdmcp.com, solo el interruptor de prueba. Así que «un SMS por reseña» hay que garantizarlo de tu lado.

Usamos una cola local de envío con clave primaria «fuente + ID de reseña». Una reseña nueva entra con INSERT OR IGNORE; si la clave ya existe, la reseña ya estaba en la cola y el script la salta.

Antes de enviar, el script pone el estado en sending y confirma; después de enviar lo pasa a sent. Si el proceso se cae a mitad de un envío, esa fila se queda en sending, la siguiente ejecución no la reenvía y una persona puede revisarla.

Es mejor perder un SMS que alguien puede mandar a mano que mandarle al dueño tres mensajes iguales. Los duplicados le quitan confianza a la alerta y además cuestan más.

Una revisión fallida no significa que no haya reseñas nuevas. Esa consulta se marca como no revisada, la tabla seen no se toca y en la siguiente se vuelve a consultar con una clave nueva; cualquier reseña que faltara aparecerá entre las 20 más recientes. El script de abajo sigue esta regla.

# review_alert.py: run once an hour. DRY_RUN=1 prints the texts instead of sending them.
import hashlib, json, os, sqlite3, time, urllib.error, urllib.request
from datetime import datetime, timezone

API, KEY = "https://api.everyinfra.com/api/v1/social", os.environ["EVERYINFRA_API_KEY"]
DRY_RUN = os.environ.get("DRY_RUN") == "1"
LINK_BASE = os.environ.get("ALERT_LINK_BASE", "https://example.com")   # your own page that shows the review
DB = sqlite3.connect("review_alert.db")
DB.executescript("""
CREATE TABLE IF NOT EXISTS seen   (source TEXT, review_id TEXT, rating INT, posted_at TEXT, first_seen TEXT,
                                   PRIMARY KEY (source, review_id));
CREATE TABLE IF NOT EXISTS outbox (source TEXT, review_id TEXT, stars INT, status TEXT, created TEXT,
                                   PRIMARY KEY (source, review_id));""")
SOURCES = {"gmaps:la-dmv-hope-st": {"platform": "google_maps_reviews", "action": "reviews", "params": {
    "url": "https://www.google.com/maps/search/?api=1&query=Los%20Angeles%20DMV&query_place_id=ChIJAQOgfwrIwoARag3eO_IQ0oE",
    "sort": "newest", "limit": 20}}}
SHORT_NAME = {"gmaps:la-dmv-hope-st": "LA DMV Hope St"}             # ASCII only: keeps each text GSM-7

def call(source, body):
    key = f"alert:{source}:{datetime.now(timezone.utc):%Y%m%d%H}"      # same hour, same Idempotency-Key
    req = urllib.request.Request(API, json.dumps(body).encode(), method="POST", headers={
        "Authorization": f"Bearer {KEY}", "Content-Type": "application/json", "Idempotency-Key": key})
    for _ in range(3):
        try:
            with urllib.request.urlopen(req, timeout=100) as r:
                return json.load(r)
        except urllib.error.HTTPError as e:
            err = json.load(e).get("error", {})
            if e.code in (429, 502, 503, 504) or err.get("retryable"):
                time.sleep(int(err.get("retry_after") or 20)); continue   # same key on retry: charged once
            raise
    raise RuntimeError(f"{source}: no result after 3 tries")             # a failed check is not "no new reviews"

def review_key(r):   # review id first; fallback hash uses each platform's author field
    author = r.get("reviewer_name") or r.get("author_name") or r.get("author")
    return r.get("id") or hashlib.sha256(f"{author}|{r.get('posted_at')}|{r.get('text')}".encode()).hexdigest()

def link(source, rid=""):
    return f"{LINK_BASE}/r/{hashlib.sha256(f'{source}|{rid}'.encode()).hexdigest()[:6]}"

def run():
    now = datetime.now(timezone.utc).isoformat(timespec="seconds")
    for source, body in SOURCES.items():
        try:
            rows = call(source, body).get("results", [])
        except RuntimeError as e:                    # mark this hour "not checked"; seen stays as it was
            print(e); continue
        for r in rows:
            stars, rid = r.get("rating") or r.get("score"), review_key(r)
            if DB.execute("INSERT OR IGNORE INTO seen VALUES (?,?,?,?,?)",
                          (source, rid, stars, r.get("posted_at"), now)).rowcount == 0:
                continue                                                # seen before
            if stars is not None and stars <= 2:
                DB.execute("INSERT OR IGNORE INTO outbox VALUES (?,?,?,?,?)", (source, rid, stars, "pending", now))
        DB.commit()

def flush(send):     # one text per source per run; mark "sending" first so a crash never resends
    for (source,) in DB.execute("SELECT DISTINCT source FROM outbox WHERE status='pending'").fetchall():
        rows = DB.execute("SELECT review_id, stars FROM outbox WHERE source=? AND status='pending'", (source,)).fetchall()
        if len(rows) == 1:
            body = f"{rows[0][1]}-star review: {SHORT_NAME[source]} {link(source, rows[0][0])}"
        else:
            body = f"{len(rows)} new 1-2 star reviews: {SHORT_NAME[source]} {link(source)}"
        body.encode("ascii")                                            # raises if a non-GSM character slips in
        DB.execute("UPDATE outbox SET status='sending' WHERE source=? AND status='pending'", (source,)); DB.commit()
        send(body)
        DB.execute("UPDATE outbox SET status='sent' WHERE source=? AND status='sending'", (source,)); DB.commit()

def send_sms(body):
    raise NotImplementedError("connect your SMS provider here (Twilio Messages API or TrueDialog)")

if __name__ == "__main__":
    run(); flush(print if DRY_RUN else send_sms)

La parte de datos del script se ejecutó de verdad dos veces, a las 00:37:20 y a las 00:37:31 hora de Singapur. La primera leyó 20 reseñas del DMV, todas nuevas; 6 tenían 1 o 2 estrellas y entraron en la cola, y la ejecución costó 0,001389 USD.

La segunda fue en la misma hora UTC y con la misma clave: la API devolvió la respuesta guardada, el script encontró 0 reseñas nuevas, la cola no creció y el registro de la cuenta no mostró un segundo cobro.

La versión de arriba añade el interruptor DRY_RUN, una función flush() que junta cada fuente en un solo SMS por ejecución y una plantilla de mensaje solo con caracteres ASCII. Le pasamos la respuesta original del DMV de la primera consulta y la ejecutamos dos veces sin conexión, sin llamar a la API. La primera ejecución imprimió un mensaje, 6 new 1-2 star reviews: LA DMV Hope St https://example.com/r/2ff3c3, de 67 caracteres; la segunda no imprimió nada. send_sms() queda vacío para que conectes tu propio proveedor de SMS.

Cuántas reseñas tienen 1 o 2 estrellas y cuántos SMS saldrían al día

El volumen de SMS depende de dos cosas: qué tan rápido llegan las reseñas nuevas y cuántas tienen 1 o 2 estrellas. La tabla junta todas las consultas y deduplica por ID. «Reseñas nuevas al día» sale del periodo que cubren los posted_at de las filas más recientes de cada muestra, así que es una estimación. «De 1–2 estrellas al día» multiplica las dos columnas. Las dos muestras de MyChart se consultaron una sola vez.

¿Una sola consulta da un porcentaje sesgado? La tabla siguiente muestra el porcentaje de 1 o 2 estrellas en cada consulta. Los dos lugares de Maps y App Store devolvieron siempre las mismas reseñas, así que su porcentaje no se movió.

Google Play trajo reseñas nuevas en cada consulta y su porcentaje subió de 50,0 % a 60,0 %; en la tercera, 4 de las 6 reseñas nuevas tenían 1 o 2 estrellas. Con tres consultas, esa subida solo muestra que unas pocas reseñas malas en una hora mueven el porcentaje 7,5 puntos. No muestra que la reputación de DoorDash haya empeorado.

La distribución de estrellas de fig-02 añade un dato: las reseñas se concentran en los extremos. En las dos tiendas, DoorDash tenía más reseñas de 1 estrella que de 5 (20 frente a 18 en App Store, 24 frente a 19 en Google Play), y cada tienda tenía apenas 5 reseñas de 3 o 4 estrellas. En las dos tiendas de MyChart, las de 5 estrellas rondaban el 60 % (30/50 y 25/40) y las malas eran casi todas de 1 estrella. La mitad de las de Joe's Pizza eran de 5 estrellas, con una de 1 y una de 2.

Para la regla de aviso, esto significa que elegir entre «2 estrellas o menos» y «solo 1 estrella» cambia poco: en DoorDash la diferencia es de 12 reseñas (7 + 5) y en Joe's Pizza, de 1. Si el volumen es demasiado alto, endurecer el filtro de estrellas ayuda muy poco.

Joe's Pizza tenía solo 2 reseñas de 1 o 2 estrellas entre 20, unas 1,3 al día según la estimación, y ahí un SMS por reseña funciona. El DMV tenía un 30,0 %, pero recibe tan pocas reseñas que la estimación es de 0,2 al día. En las dos tiendas, cerca de la mitad de las reseñas más recientes de DoorDash tenían 1 o 2 estrellas, y la estimación es de unas 94 al día entre las dos (54,5 + 39,6).

Con ese volumen nadie puede leer un SMS por reseña. Conviene una de dos reglas. La primera es «como máximo un SMS por hora»: si en la hora hubo reseñas malas, se manda un mensaje como «12 new 1-2 star reviews in the last hour» con un enlace a la lista completa. La función flush() del script ya junta cada fuente en un solo mensaje por ejecución.

La segunda es «solo por encima de lo normal»: se ejecuta una semana con DRY_RUN=1, se calcula la mediana de reseñas malas por hora y solo se avisa cuando una hora supera el doble de esa mediana. Eso suele indicar una caída del servicio o una mala actualización. Ninguna de las dos reglas cambia el costo de datos; solo cambian cuántos SMS salen.

Casi la mitad de las reseñas de Google Maps tenían estrellas pero no texto: 9 de 20 tanto en Joe's Pizza como en el DMV. Todas las reseñas de las tiendas de apps de nuestras muestras tenían texto.

Las cuentas de la alerta por SMS: 24 consultas al día o una

El precio de los datos es sencillo. En el catálogo, google_maps_reviews/reviews, app_store/reviews, google_play/reviews y yelp/reviews cuestan 0,001389 USD por llamada. Cada llamada devuelve como máximo 100, 500, 200 y 10 reseñas, respectivamente. Se paga por llamada, no por reseña, y los resultados vacíos no se cobran (catálogo leído el 14 de noviembre de 2026; ver precios).

Nuestra prueba hizo 21 llamadas cobradas. El registro de la cuenta suma 0,029167 USD, que es 21 × 0,00138889 USD. La repetición con la misma clave y los dos resultados vacíos no se cobraron.

Si comparas «una vez al día» con «24 veces al día» en cada muestra, la diferencia está en lo que alcanzas a ver. En la tabla siguiente, «nuevas por revisión» es la velocidad estimada de la sección anterior multiplicada por las horas entre dos revisiones, con un tope igual a las filas que trae una llamada. Por encima del tope, entre dos revisiones llegan más reseñas de las que una llamada puede traer, y algunas se pierden.

En el DMV, los 0,96 USD de más por revisar 24 veces al día compran casi solo repeticiones. En las dos tiendas de DoorDash, una revisión diaria pierde más de la mitad de las reseñas nuevas: o se revisa cada hora, o se revisa una vez al día con limit de 200 o más (App Store devuelve hasta 500 y Google Play hasta 200). En los dos casos cada llamada cuesta 0,001389 USD.

La mayor parte del costo total está del lado del SMS: tres fuentes revisadas cada hora suman 3,00 USD de datos al mes. La página de precios de Twilio para EE. UU. dice que un SMS desde un número estándar de 10 dígitos cuesta 0,0083 USD por segmento, más una tarifa del operador, por ejemplo 0,0035 USD por segmento con AT&T y 0,0045 USD con T-Mobile.

Un mensaje que termina en estado «fallido» paga una tarifa de procesamiento de 0,001 USD (precios de SMS de Twilio en EE. UU.; la página indica «precios a noviembre de 2026»). Los números cuestan desde 1,15 USD al mes (precios de números de Twilio).

A eso se suman la tarifa única de marca 10DLC de 4,50 USD, 15 USD de revisión por campaña y una cuota mensual por campaña. Con estas tarifas, un SMS de un segmento cuesta entre 0,0118 y 0,0128 USD. La mayor parte del dinero se va en el número, el registro y las cuotas mensuales.

TrueDialog vende planes mensuales en cuatro niveles. Small Business cuesta 119 USD al mes con 5000 SMS y 0,024 USD por SMS adicional. Professional cuesta 425 USD con 25.000 SMS. Enterprise cuesta 900 USD con 60.000 SMS. Custom empieza en 1000 USD al mes. Todos son contratos anuales.

Las tarifas de los operadores van aparte. Un número largo cuesta 9,99 USD al mes y un código corto, 799 USD al mes (precios de TrueDialog, leídos el 14 de noviembre). El comunicado dice que MCP no tiene cargo extra, así que un SMS enviado desde Claude cuesta lo que marque el plan.

Según nuestra estimación, un local como Joe's Pizza manda unas 39 alertas al mes, menos del 1 % de los 5000 SMS de Small Business. Un negocio que ya usa TrueDialog para SMS de marketing puede sumar las alertas a su cuenta actual.

Los SMS se estiman multiplicando por 30 las reseñas diarias de 1 o 2 estrellas de la sección anterior, así que solo indican el orden de magnitud. Una app grande que avisa de cada reseña manda unos 2823 SMS al mes. Con un máximo de un SMS por hora de atención, manda como mucho 390, unos 4,99 USD al mismo precio por mensaje.

Cumplimiento: 10DLC, palabras de baja y la regla de la FCC del 25 de noviembre

En Estados Unidos, los SMS de aplicación a persona enviados desde un número común de 10 dígitos (10DLC) exigen registrar la marca y la campaña en The Campaign Registry. El centro de ayuda de Twilio enumera tres cargos.

Una marca Low Volume Standard cuesta 4,50 USD una sola vez. Cada campaña cuesta 15 USD de revisión y después una cuota mensual (centro de ayuda de Twilio: cargos de A2P 10DLC). La página de precios de TrueDialog dice que registra el 10DLC por ti y que su equipo ayuda con el registro de 10DLC y de códigos cortos (precios de TrueDialog).

Lo siguiente son las bajas. Los Messaging Principles and Best Practices de CTIA fijan STOP como palabra estándar para darse de baja y piden aceptar más de un método de baja (CTIA Messaging Principles and Best Practices, mayo de 2023). El comunicado de TrueDialog dice que la plataforma aplica las bajas automáticamente (comunicado en PR Newswire).

El tercer punto es la regla actualizada de la FCC sobre cómo se revoca el consentimiento.

La FCC aprobó los cambios el 30 de septiembre de 2026, según el resumen de Kelley Drye. El Federal Register publicó la regla el 26 de octubre de 2026 y entra en vigor el 25 de noviembre de 2026 (Federal Register 2026-21821). El resumen enumera tres puntos.

El remitente puede entender que una revocación se limita a la categoría de mensajes informativos a la que responde. El remitente puede fijar un único método exclusivo para revocar. La exención para avisos de fraude financiero se amplía.

La hoja informativa de la FCC del 9 de septiembre también está en línea (hoja informativa de la FCC en PDF). Estas reglas tratan de cómo se da de baja quien recibe los mensajes y qué mensajes deben parar después. Consulta con un abogado qué parte se aplica a tu caso. Aquí solo damos el texto de la fuente y las fechas.

Qué va en el mensaje: 160 caracteres, nunca la reseña completa

En Estados Unidos un SMS estándar se cobra por segmentos de 160 caracteres. Un mensaje más largo se parte en dos segmentos y cuesta dos, como explica la sección de preguntas frecuentes de precios de Twilio para EE. UU. (precios de SMS de Twilio en EE. UU.).

La página de Twilio sobre el límite de caracteres explica que basta un carácter fuera de GSM-7, como un emoji, un carácter chino o unas comillas tipográficas, para que todo el mensaje pase a UCS-2; entonces un segmento admite solo 70 caracteres (Twilio: How long can a message be?). Por eso la alerta lleva tres cosas: las estrellas, el lugar o la app y un enlace, escritos en inglés y con caracteres ASCII, como en la plantilla del script.

Entre las 20 reseñas del DMV, 2 de las 6 reseñas malas describen a un empleado de forma que se le puede identificar: una habla de una guardia de seguridad y otra del empleado de una ventanilla con número, y las dos con palabras duras. Reenviar ese texto a una docena de teléfonos equivale a difundir una acusación contra un compañero.

En salud hay precedentes propios. La Oficina de Derechos Civiles del Departamento de Salud de EE. UU. (HHS OCR) ha publicado acuerdos con consultorios que revelaron datos de pacientes al responder reseñas en línea. En un caso anunciado el 5 de junio de 2023, una consulta psiquiátrica de Nueva Jersey reveló datos de cuatro pacientes al contestar reseñas de Google y pagó 30.000 USD (HHS: acuerdo con Manasa Health Center; el monto figura en el informe 2023 del HHS al Congreso).

En un caso del 14 de diciembre de 2022, una clínica dental reveló datos de pacientes al responder en redes sociales (HHS: acuerdo con New Vision Dental; la lista completa está en la página de acuerdos del HHS). Los dos casos empezaron con datos de pacientes dentro de una respuesta a una reseña. Una alerta por SMS no es una respuesta a una reseña. Para decidir cómo tratar cada caso, sigue la política de privacidad y el criterio legal de tu organización.

La regla de la FTC sobre reseñas y testimonios de consumidores, §465.7, prohíbe usar amenazas legales sin fundamento, intimidación o acusaciones falsas para suprimir reseñas, y también prohíbe ocultar reseñas según su calificación (16 CFR Part 465, §465.7 Review suppression; preguntas y respuestas de la FTC en Consumer Reviews and Testimonials Rule Q&A).

Otro sector: clínicas comunitarias y ventanillas de servicio público

El mismo método sirve, casi sin cambios técnicos, para clínicas comunitarias, consultas externas, oficinas del DMV y ventanillas de servicios sociales. Lo que cambia es quién recibe el SMS, qué dice y cada cuánto alguien lo revisa. Esta sección trata solo de métodos de datos: no hace juicios médicos ni es asesoría legal ni médica. Nuestras dos muestras de comparación son la oficina del DMV en Hope Street, Los Ángeles, y MyChart, una app que muchos sistemas de salud de EE. UU. dan a sus pacientes.

La muestra del DMV tiene pocas reseñas, pero muchas malas. En la consulta de las 00:20 hora de Singapur del 14 de noviembre, las 20 reseñas más recientes incluían cinco de 1 estrella y una de 2, un 30 % en total. Sus posted_at van del 2026-10-20 al 2026-11-12, menos de una al día.

Diez son del 2026-11-01 o posteriores, y 5 de esas 10 solo tienen estrellas, sin texto. Revisar cada hora un lugar así no tiene sentido; una revisión diaria lo cubre por 0,001389 USD al día. El script tiene que soportar reseñas sin texto: la plantilla de arriba no incluye el texto de la reseña, así que un texto vacío no la rompe.

La muestra de MyChart muestra en qué se diferencian las reseñas de apps de las de lugares. En App Store, 50 reseñas incluían once de 1 estrella y cuatro de 2, un 30 %. En Google Play, 40 reseñas incluían diez de 1 estrella y tres de 2, un 32,5 %.

Todas las reseñas de las dos tiendas tenían texto. Las 13 reseñas malas de Google Play tienen 96 caracteres de media, y las reseñas malas de App Store suelen llevar título. Agrupamos por palabras clave las 15 reseñas malas de App Store, y una reseña puede caer en más de un grupo: 6 hablan de mensajes o citas, 2 de inicio de sesión o códigos y 2 de una actualización. Este tipo de agrupación va en un resumen diario para la persona responsable de la experiencia del paciente, no en un SMS por reseña para el personal de primera línea.

Los organismos públicos pueden compararlo con dos marcos ya existentes. La Agency for Healthcare Research and Quality (AHRQ) define las encuestas CAHPS como medidas de la experiencia de atención reportadas por los pacientes. Su página distingue «experiencia del paciente» de «satisfacción del paciente» y dice que los comentarios abiertos ayudan a detectar problemas de seguridad (AHRQ: What Is Patient Experience?; portada de CAHPS en ahrq.gov/cahps; página de CMS en CMS: CAHPS).

Para las ventanillas federales, la Circular A-11 de la OMB, sección 280, pide a los proveedores designados como High Impact Service Providers que hagan encuestas después de cada trámite, que informen los resultados a la OMB cada trimestre y que los usen para mejorar y para la «recuperación del servicio» (explicación de A-11 Section 280). Las reseñas en línea no son como esas encuestas: no tienen muestreo, no se verifican y no tienen preguntas estándar. Sirven como señal temprana, no como reemplazo de una encuesta formal.

En la práctica, una clínica o una ventanilla puede dividir las alertas en dos niveles. El primero es un SMS solo para la persona de turno, con las estrellas, el lugar y un enlace, sin el texto de la reseña ni ninguna palabra que permita identificar a un paciente o su condición. El segundo es un resumen diario para quien se encarga de calidad o de experiencia, agrupado por tema (espera, citas, trato, fallas del sistema). Una reseña mala que nombra a alguien del personal va primero a un supervisor para que la verifique.

Conectar las dos partes con MCP (ejemplo de configuración)

Un script programado puede hacer todo el flujo por sí solo. Un asistente de IA aporta cuando lee la reseña mala, escribe una línea para el dueño y decide si hay que escalar a una gerente regional.

Abajo, Claude se conecta a dos servidores MCP remotos. EveryInfra consulta capacidades, revisa los cobros y lee las reseñas nuevas que preparó el script. TrueDialog envía el SMS. Las llamadas tools/list y tools/call de EveryInfra las hicimos de verdad. No tenemos cuenta de TrueDialog, así que esa parte es un ejemplo de configuración basado en tdmcp.com y en el centro de ayuda de Claude.

En la app de escritorio de Claude o en claude.ai, abre «Conectores personalizados» como indica el centro de ayuda de Claude y añade un servidor MCP remoto con nombre y URL. La conexión sale de la nube de Anthropic, así que el servidor tiene que ser accesible desde internet (centro de ayuda de Claude: conectores personalizados).

Para TrueDialog, escribe https://connect.tdmcp.com/, pulsa conectar e inicia sesión en TrueDialog en el navegador. Para EveryInfra, escribe https://api.everyinfra.com/mcp y añade tu clave como indica la página de configuración de MCP. En Claude Code, un servidor HTTP remoto se añade con claude mcp add --transport http (documentación de MCP en Claude Code). Para ejecuciones programadas, usa el modo no interactivo claude -p (Claude Code sin interfaz).

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${EVERYINFRA_API_KEY}" }
    },
    "truedialog": {
      "type": "http",
      "url": "https://connect.tdmcp.com/"
    }
  }
}

A las 00:29 hora de Singapur llamamos de verdad a tools/list de EveryInfra. Devolvió 12 herramientas. La que lee reseñas es everyinfra_call_api, con las anotaciones readOnlyHint: false, destructiveHint: true y openWorldHint: true, porque cobra. everyinfra_list_capabilities, everyinfra_get_job y everyinfra_list_requests son de solo lectura. everyinfra_call_api recibe cuatro parámetros: platform, action, params y mode.

La tarea de cada hora queda en manos del script de arriba, que usa REST con Idempotency-Key. El asistente de IA lee las reseñas nuevas que preparó el script, escribe el resumen y decide si hay que escalar.

A las 00:35 y 00:36 llamamos dos veces a google_play/reviews por MCP. En la primera escribimos mal el paquete de MyChart, com.epic.mychart.android: devolvió 0 filas, sin cobro y con el motivo empty_result_refunded. Con el paquete correcto, epic.mychart.android, devolvió 40 filas y costó 0,001389 USD.

Ejecutar cada hora de 9:00 a 21:00:
1. Leer las filas con estado pending de la tabla outbox de review_alert.db (las escribe el script programado).
2. Por cada fuente, escribir un solo SMS en inglés de 60 caracteres o menos, sin nombres de autores, sin aspecto del personal ni números de ventanilla, solo con caracteres ASCII.
3. Llamar primero a send_sms de truedialog con execute=false y mostrarme lo que se enviaría. Usar execute=true solo después de que yo responda «enviar».
4. Mandar como máximo un SMS por fuente y por hora.

El paso 3, «primero una prueba, después el envío con el visto bueno de una persona», responde a la nota de la página del conector: send_sms envía por defecto. El comunicado de TrueDialog dice que los desarrolladores pueden darle al agente solo herramientas de lectura. Si quieres envíos automáticos cada hora sin nadie mirando, el agente llama directamente a send_sms; en ese caso, fija la lista de destinatarios en las instrucciones y no dejes que el modelo busque contactos.

En qué se diferencia de otros artículos del sitio

Nuestros otros artículos no tratan el canal SMS ni el costo por hora. BL-88 muestra tres locales pequeños que usan Claude Duet para un informe de reseñas cada mañana; encontró que esos locales tuvieron reseñas nuevas solo en 4 a 8 de los últimos 90 días, así que basta con mirar una vez al día.

BL-79 ejecuta Claude Managed Agents cada noche sobre Google, Yelp y Tripadvisor. Encontró una reseña con posted_at anterior a la consulta previa que esa consulta no había devuelto, así que una regla basada solo en la hora pierde reseñas. BL-70 compara las formas de obtener reseñas de Google Maps, incluido el límite de 5 reseñas de la Places API.

BL-115 prueba todos los casos de reintento con claves de idempotencia. Para la elección de herramientas, ver API de datos y enrutamiento de herramientas.

Novedades del sector

El 28 de octubre de 2026, TikTok lanzó Must Eat, una guía de restaurantes en Nueva York, Los Ángeles y el área de la bahía de San Francisco. Los usuarios pueden calificar y reseñar restaurantes dentro de la app (anuncio de TikTok; nota de The Verge). Los restaurantes tienen ahora una fuente de reseñas más, así que conviene dejar sitio para más entradas en la tabla SOURCES del script.

El 28 de julio de 2026, la especificación MCP publicó una versión nueva que elimina las sesiones y el saludo inicial. Los servidores remotos se comportan más como API comunes sin estado (registro de cambios de la especificación MCP; versiones en GitHub). tdmcp.com se describe como un intermediario sin estado que no guarda credenciales, lo que va en la misma dirección.

Límites y advertencias

La muestra es pequeña, así que los resultados tienen límites. Probamos 2 lugares y 2 apps (más una consulta de MyChart) durante unas 3 horas, en la mañana y el mediodía de la costa este de EE. UU. La velocidad de las reseñas nuevas y la proporción de malas cambian según el local, la hora, las promociones y las caídas del servicio. Toma las cifras de SMS al día solo como orden de magnitud. Para fijar la frecuencia de tu propio local, ejecuta una semana con DRY_RUN=1 y cuenta cuántas filas entran en la cola cada día.

Preguntas frecuentes

¿Claude puede enviar SMS? ¿Cómo conecto un servidor SMS MCP?

Claude no envía SMS por sí mismo; necesita un servidor MCP que pueda enviarlos. Según tdmcp.com, añade https://connect.tdmcp.com/ en «Conectores personalizados» de Claude e inicia sesión en tu cuenta de TrueDialog. El servidor MCP de la propia Twilio solo busca documentación y no puede enviar. Pregunta tomada del autocompletado de Google, «claude sms mcp» (leído el 2026-11-14).

Google Business Profile ya avisa de reseñas nuevas. ¿Igual necesito una alerta por SMS?

Para un local tuyo, empieza por los avisos de Google por correo y en la app de Maps, o arma tu propia alerta con el envío por Pub/Sub. El sondeo con SMS hace falta cuando quieres mensajes de texto, una vista conjunta de muchos locales o lugares que no están en tu cuenta. Pregunta tomada del autocompletado de Google, «google business review notifications» (leído el 2026-11-14).

Me llegó un SMS que dice «review alert». ¿Cómo sé si es una estafa?

Tu propia alerta debería llegar siempre desde un único número registrado, con solo las estrellas, el lugar y un enlace a tu propio sistema, y nunca pide contraseñas ni pagos. Trata como phishing un SMS de un número desconocido que diga «tienes una reseña mala nueva, inicia sesión aquí». Pregunta tomada del autocompletado de Google, «review alert sms scam» (leído el 2026-11-14).

¿App Store Connect avisa de reseñas nuevas?

No, según la lista de notificaciones de la ayuda de App Store Connect. El único aviso relacionado es «Developer Response», un correo cuando alguien edita una reseña que respondiste. Para reseñas nuevas hay que consultar la API Customer Reviews o los datos de reseñas. Pregunta tomada del autocompletado de Google, «app store connect review notifications» (leído el 2026-11-14).

Si el dueño responde al SMS, ¿esa respuesta puede contestar la reseña?

Con TrueDialog MCP no: la primera limitación conocida en la página del conector de Microsoft Learn es que solo envía y no puede leer respuestas ni conversaciones. Para eso hace falta el webhook de entrada de la plataforma de SMS, que lleve la respuesta a tu propio sistema; después una persona o un programa contesta la reseña en la plataforma. Pregunta tomada del autocompletado de Google, «review alert sms auto reply» (leído el 2026-11-14).

¿Puedo vigilar reseñas de Google de un negocio que no es mío?

Los avisos de Google y la Business Profile API solo cubren los negocios que administras, y las respuestas del hilo de r/smallbusiness dicen lo mismo. Las reseñas de lugares públicos se pueden leer con google_maps_reviews/reviews, deduplicar por ID y usar para tu propia alerta. Pregunta tomada de un hilo de Reddit r/smallbusiness.

Cómo empezar

Paso 1: crea una clave de API en la consola de EveryInfra y guárdala en la variable de entorno EVERYINFRA_API_KEY. El catálogo gratuito GET /api/v1/social/catalog enumera los parámetros, los valores permitidos y el price_usd de cada capacidad. Sigue la guía rápida para hacer tu primera petición.

Paso 2: usa google_maps_reviews/search para encontrar los lugares que quieres vigilar y copia de la respuesta la URL con query_place_id. Para apps, anota el ID numérico de App Store y el nombre del paquete de Google Play. Consulta la API de reseñas de Google Maps, la API de App Store y la API de Google Play. Para locales en Yelp, añade yelp/reviews.

Paso 3: pon el script de arriba en cron y ejecútalo una semana con DRY_RUN=1. Cuenta cuántas filas entran en la cola cada día.

Paso 4: conecta el SMS. Cambia send_sms() por la API de Messages de Twilio, o usa el servidor MCP o la API de TrueDialog. Haz primero una prueba y después envía de verdad. Los precios siguen la página de precios y el catálogo. Para comprobar que los fallos y los resultados vacíos no se cobraron, ver conciliación de reembolsos por fallos.

Referencias

1. Model Context Protocol, Specification 2026-07-28, leído 14-11-2026
2. TrueDialog MCP, tdmcp.com (setup, tools, security), leído 14-11-2026
3. PR Newswire, TrueDialog Launches MCP for ChatGPT, Copilot and Other AI Assistants, 2026-11-10, leído 14-11-2026
4. TrueDialog, MCP feature page, leído 14-11-2026
5. Twilio Blog, Introducing Twilio MCP and skills, 2026-05-07, leído 14-11-2026
6. Twilio Docs, Twilio MCP server, leído 14-11-2026
7. GitHub, twilio-labs/mcp, leído 14-11-2026
8. npm registry, @twilio-alpha/mcp, leído 14-11-2026
9. Microsoft Learn, TrueDialog MCP connector, leído 14-11-2026
10. Google Business Profile Help, manage notifications, leído 14-11-2026
11. Google for Developers, Business Profile real-time notifications setup, leído 14-11-2026
12. Google for Developers, My Business Notifications API: NotificationSetting, leído 14-11-2026
13. Google for Developers, Business Profile review data, leído 14-11-2026
14. Apple, App Store Connect Help: user notifications, leído 14-11-2026
15. Apple Developer Documentation, App Store Connect API: Customer Reviews, leído 14-11-2026
16. Google for Developers, Google Play Developer API: Reply to Reviews, leído 14-11-2026
17. Reddit r/smallbusiness, Google reviews monitoring thread, leído 14-11-2026
18. Google for Developers, Places API Place Details, leído 14-11-2026
19. EveryInfra, llms-full.txt (Retries and idempotency), leído 14-11-2026
20. EveryInfra, OpenAPI specification, leído 14-11-2026
21. Twilio Docs, Message resource, leído 14-11-2026
22. Twilio, SMS pricing for the United States, leído 14-11-2026
23. Twilio, phone number pricing, leído 14-11-2026
24. TrueDialog, pricing, leído 14-11-2026
25. Twilio Help Center, A2P 10DLC pricing and fees, leído 14-11-2026
26. CTIA, Messaging Principles and Best Practices, May 2023 (PDF), leído 14-11-2026
27. Kelley Drye, FCC revises TCPA consent revocation rules, leído 14-11-2026
28. Federal Register 2026-21821, consent revocation rule, published 2026-10-26, leído 14-11-2026
29. FCC, fact sheet DOC-424844A1, 2026-09-09 (PDF), leído 14-11-2026
30. Bandwidth Support, 10DLC fees (updated 2026-09-16), leído 14-11-2026
31. Twilio Docs, How long can a message be?, leído 14-11-2026
32. HHS OCR, Manasa Health Center settlement, 2023-06-05, leído 14-11-2026
33. HHS OCR, 2023 report to Congress on HIPAA compliance (PDF), leído 14-11-2026
34. HHS OCR, New Vision Dental settlement, 2022-12-14, leído 14-11-2026
35. HHS OCR, resolution agreements, leído 14-11-2026
36. eCFR, 16 CFR Part 465 (Consumer Reviews and Testimonials), leído 14-11-2026
37. FTC, Consumer Reviews and Testimonials Rule: Q&A, leído 14-11-2026
38. AHRQ, What Is Patient Experience?, leído 14-11-2026
39. AHRQ, CAHPS, leído 14-11-2026
40. CMS, Consumer Assessment of Healthcare Providers & Systems, leído 14-11-2026
41. Performance.gov, A-11 Section 280 explainer, leído 14-11-2026
42. Claude Help Center, custom connectors using remote MCP, leído 14-11-2026
43. Claude Code Docs, MCP, leído 14-11-2026
44. Claude Code Docs, run Claude Code programmatically, leído 14-11-2026
45. TikTok, Must Eat announcement, 2026-10-28, leído 14-11-2026
46. The Verge, TikTok Must Eat restaurant guide, leído 14-11-2026
47. Model Context Protocol, specification changelog, leído 14-11-2026
48. GitHub, modelcontextprotocol releases, leído 14-11-2026