Skip to main content
Glama
17191004

TrendRadar MCP Server

by 17191004

El asistente de tendencias más rápido de implementar en 30 segundos — di adiós al scroll inútil y mira solo las noticias que realmente te importan

🌐 Sitio web oficial · 📖 Documentación oficial

GitHub Stars GitHub Forks License Version MCP Docker Pulls Docker Pulls RSS AI翻译 MCP Support AI分析推送 AI智能筛选

企业微信通知 个人微信通知 Telegram通知 dingtalk通知 飞书通知 邮件通知 ntfy通知 Bark通知 Slack通知 通用Webhook

GitHub Actions GitHub Pages Docker 本地部署 Cloudflare Pages

中文 | English

Este proyecto tiene como objetivo ser ligero y fácil de implementar

📑 Navegación rápida

💡 Haz clic en los enlaces a continuación para saltar rápidamente a la sección correspondiente. Para la implementación, se recomienda comenzar con «Inicio rápido»; si necesitas personalización detallada, consulta «Configuración detallada»

  • Gracias a todos los que han dado una estrella al proyecto. Fork es lo que deseas, star es lo que deseo, tener ambos 😍 es el mejor apoyo al espíritu del código abierto

Agradecimientos a los primeros seguidores

💡 Nota especial:

  1. Sobre la lista: La tabla a continuación registra a los seguidores de la etapa inicial del proyecto (ronda ángel). Debido a que la recopilación manual temprana era tediosa, es inevitable que haya omisiones o registros incompletos. Si hay alguna omisión, no es intencional y esperamos tu comprensión.

  2. Plan futuro: Para dedicar la energía limitada al código y la iteración de funciones, a partir de hoy esta lista ya no se mantendrá manualmente.

Ya sea que tu nombre aparezca en la lista o no, cada muestra de apoyo es la base sobre la que TrendRadar ha llegado hasta hoy. 🙏

Apoyo de infraestructura

Gracias a GitHub por la infraestructura gratuita, que es la mayor premisa para que este proyecto pueda ejecutarse convenientemente con un solo fork.

Apoyo de datos

Este proyecto utiliza la API del proyecto newsnow para obtener datos de múltiples plataformas. Agradecemos especialmente al autor por el servicio proporcionado.

Tras contactar, el autor indicó que no hay que preocuparse por la presión del servidor, pero esto se basa en su buena voluntad y confianza. Por favor:

  • Ve al proyecto newsnow y dale una estrella de apoyo

  • Al implementar con Docker, controla razonablemente la frecuencia de envío, no agotes el recurso

Apoyo de promoción

Gracias a las siguientes plataformas y personas por sus recomendaciones (en orden cronológico)

Apoyo de la audiencia

Gracias a los amigos que han brindado apoyo económico. Su generosidad se ha convertido en snacks y bebidas junto al teclado, acompañando cada iteración del proyecto.

Sobre el regreso del «me gusta de un yuan»: Con el lanzamiento de la versión v5.0.0, el proyecto ha entrado en una nueva etapa. Para respaldar los crecientes costos de API y el consumo de cafeína, el canal de «me gusta de un yuan» se ha reabierto. Cada muestra de tu apoyo se convertirá en tokens y motivación en el mundo del código. 🚀 Ve a apoyar

Donante

Cantidad

Fecha

Nota

D*5

1.8 * 3

2025.11.24

*鬼

1

2025.11.17

*超

10

2025.11.17

R*w

10

2025.11.17

Este agente está increíble, hermano

J*o

1

2025.11.17

Gracias por el código abierto, te deseo éxito en tu carrera

*晨

8.88

2025.11.16

Buen proyecto, estudiándolo

*海

1

2025.11.15

*德

1.99

2025.11.15

*疏

8.8

2025.11.14

Gracias por el código abierto, el proyecto es genial, te apoyo

M*e

10

2025.11.14

El código abierto no es fácil, gran trabajo

**柯

1

2025.11.14

*云

88

2025.11.13

Buen proyecto, gracias por el código abierto

*W

6

2025.11.13

*凯

1

2025.11.13

对*.

1

2025.11.13

Thanks for your TrendRadar

s*y

1

2025.11.13

**翔

10

2025.11.13

Buen proyecto, lamento no haberlo conocido antes, ¡gracias por el código abierto!

*韦

9.9

2025.11.13

TrendRadar es increíble, invito un café al maestro~

h*p

5

2025.11.12

¡Apoyando la fuerza del código abierto chino, adelante!

c*r

6

2025.11.12

a*n

5

2025.11.12

。*c

1

2025.11.12

Gracias por compartir el código abierto

*记

1

2025.11.11

*主

1

2025.11.10

*了

10

2025.11.09

*杰

5

2025.11.08

*点

8.80

2025.11.07

El desarrollo no es fácil, te apoyo.

Q*Q

6.66

2025.11.07

¡Gracias por el código abierto!

C*e

1

2025.11.05

Peter Fan

20

2025.10.29

M*n

1

2025.10.27

Gracias por el código abierto

*许

8.88

2025.10.23

Maestro, soy un novato, llevo días intentándolo y aún no lo logro, pido ayuda

Eason

1

2025.10.22

Aún no lo entiendo del todo, pero estás haciendo algo bueno

P*n

1

2025.10.20

*杰

1

2025.10.19

*徐

1

2025.10.18

*志

1

2025.10.17

*😀

10

2025.10.16

Me gusta

**杰

10

2025.10.16

*啸

10

2025.10.16

*纪

5

2025.10.14

TrendRadar

J*d

1

2025.10.14

Gracias por tu herramienta, es muy divertida...

*H

1

2025.10.14

那*O

10

2025.10.13

*圆

1

2025.10.13

P*g

6

2025.10.13

Ocean

20

2025.10.12

...¡¡¡Es realmente increíble!!! Incluso un novato puede usarlo directamente...

**培

5.2

2025.10.2

github-yzyf1312: ¡Viva el código abierto

*椿

3

2025.9.23

Sigue así, muy bueno

*🍍

10

2025.9.21

E*f

1

2025.9.20

*记

1

2025.9.20

z*u

2

2025.9.19

**昊

5

2025.9.17

*号

1

2025.9.15

T*T

2

2025.9.15

Me gusta

*家

10

2025.9.10

*X

1.11

2025.9.3

*飙

20

2025.8.31

Gracias del viejo Tong

*下

1

2025.8.30

2*D

88

2025.8.13 下午

2*D

1

2025.8.13 上午

S*o

1

2025.8.05

Te apoyo

*侠

10

2025.8.04

x*x

2

2025.8.03

trendRadar, buen proyecto, me gusta

*远

1

2025.8.01

*邪

5

2025.8.01

*梦

0.1

2025.7.30

**龙

10

2025.7.29

Te apoyo

Related MCP server: TrendRadar

🪄 Patrocinador

Disfruta en un solo lugar del modelo Doubao de gran tamaño desarrollado por ByteDance y las versiones completas de los principales modelos SOTA de código abierto, que cubren capacidades multimodales como texto, comprensión visual (VLM) y generación de imágenes. Seed-2.1, Seedream 5.0, GLM-5.2, DeepSeek y otros modelos populares están disponibles en un solo lugar, no solo para programación eficiente, sino también para tareas complejas de agentes de largo alcance.

❤️ ¿Te parece útil? Apóyalo

Si TrendRadar te ha aportado valor, ¿por qué no darle impulso para que siga evolucionando?

La cantidad es libre, incluso 1 yuan es un estímulo para el código abierto. Bienvenido a dejar un mensaje al hacer tu donación (´▽`ʃ♡ƪ)

Donación por WeChat

Donación con Alipay

🤝 Desarrollo secundario y referencias

Si utilizas o aprovechas las ideas o el código central de este proyecto en el tuyo, será muy bienvenido que indiques la fuente y el enlace a este repositorio en el README o en la documentación.

Esto contribuye al mantenimiento continuo y al desarrollo de la comunidad. ¡Gracias por tu respeto y apoyo! ❤️

💬 Comunicación y comentarios

  • GitHub Issues:Adecuado para problemas técnicos concretos. Al preguntar, aporta información completa (capturas de pantalla, registros de error, etc.), lo que facilita identificar el problema rápidamente.

  • Contacto a través de la cuenta oficial:Se recomienda usar la sección de comentarios de los artículos relacionados. Si necesitas preguntar por privado, darle a "me gusta" / "recomendar" al artículo es la mejor "tarjeta de presentación". En el fondo puedo sentir ese gesto (´▽`ʃ♡ƪ).

  • Grupo de QQ:Sigue la cuenta oficial, responde «Grupo de intercambio» y podrás unirte. Ya seas novato en IA o desarrollador veterano, busques ayuda técnica o quieras compartir tus descubrimientos, aquí eres bienvenido. El grupo fomenta la ayuda mutua y el intercambio de ideas. Nada más entrar, lee el anuncio del grupo; al hacer preguntas, describe claramente el problema y añade capturas; cuando tengan tiempo, los compañeros del grupo contestarán. Su experiencia práctica suele ser más rápida y completa que la mía 🤝

Aviso amistoso: Este proyecto es de código abierto y compartido, no un producto comercial. Si al autor lo tratar como un amigo y no como soporte técnico, eso mucho más eficiente.

Seguir la cuenta oficial

📝 Registro de cambios

📌 Consulta las últimas actualizaciones:Registro de cambios del repositorio original :

  • Nota:Se recomienda consultar el 【historial de actualizaciones】 para conocer las 【funciones específicas】.

2026/06/19 - v6.10.0

  • Traducción de IA por lotes:When there is a large quantity de títulos por traducir, las solicitudes se envían automáticamente por lotes para evitar que una sola solicitud exceda el límite y falle.

  • Refactorización del módulo:Se dividen context.py y \_\_main\_\_.py; el pipeline de filtrado de IA pasa a ser el módulo filter\_pipeline, con responsabilidades más claras y mantenimiento más sencillo.

  • Corrección del etiquetado de fuente de Feishu:Se corrige el problema en las tarjetas de Feishu en el que la etiqueta de fuente y el resumen rápido de la fuente independiente de IA eran eliminados por CommonMark y no se mostraban.

2026/02/09 - mcp-v4.0.0

  • 🔥 Mensajes de IA directos a todos los canales:Contenido generado por IA se envía con un click a Feishu, DingTalk, Telegram, correo y 9 canales más; Markdown se adapta automáticamente al formato de cada plataforma, sin preocuparte por diferencias de formato.

  • Nueva guía de estrategias de formato:Se añade el tool get_channel_format_guide, que dice a la IA formato y limitaciones de cada canal, lograr un diseño más bonito.

  • Envío inteligente por lotes:Los mensajes demasiado largos se dividen automáticamente según el límite de bytes por canal (Feishu 30KB, DingTalk 20KB, etc.); la configuration usa config.yaml.

  • Corrección de detecciones de canales:ntfy ya no se reporta como "configurado" por su dirección por defecto.

  • Optimización de reutilización del código:Las funciones de procesamiento en lote reutilizan directamente los módulos core de trendradar, sin reinventar la rueda.

2026/06/02 - v6.9.0

  • Verificación de seguridad de dominios de tendencias:Nueva opción expected_domain para comprobar que el dominio de los enlaces devueltos sea el esperado. Si no es así, los datos se descartan automáticamente y se muestra una alerta, previniendo secuestro de enlaces o manipulación de datos.

  • API personalizada para rankings:Soporta autoalojamiento de newsnow y configura api_url para usar tu propio proveedor de datos.

2026/05/23 - v6.8.0

  • Informe HTML mejorado extenso : Se añade metadatos del informe (hora de generación, fuentes, versión), adaptación automática a modo oscuro, optimización de interacción de la pestaña, normalización de puntos de tendencia y una experiencia de lectura mucho mejor en navegadores.

  • Copias múltiples de CDN para verificación de versión : El endpoint de verificación ofrecesión de verificación soporta fallback automático entre GitHub → jsDelivr → Cloudflare y otros del original, incluidas environmentas de red de China.

  • Foris sensibles generadas : Los informes HTML y correos electrónicos ahora respetan correctamente los interruptores display.regions.ai_analysis y display.regions.standalone; si desactivados, no se renderizan.

  • Corrección del botón de exportación : se corrige el problema de que el icono del menú desplegable desaparecía al expulsar el botón de exportación.

  • Corrección de exportación Markdown : se corrige el error de escape de caracteres de nueva línea en la exportación Markdown del informe HTML.

2026/05/15 - v6.7.0

  • Exportación a Markdown : la barra o menú desplegable del informe agregan exportación Markdown; un click genera un texto de estructura con enlaces, listo para procesamiento posterior con LLM y para compartir en otras plataformas (#1121).

  • Deduplicación por guid RSS : El almacenamiento RSS agrega el campo guid; su prioridad de deduplicación cambia a guid > url, para solucionar la duplicación de un mesmo artículo debtsito de constraints en URL.

  • Protección ante títulos vacíos : A lo largo de toda la cadena (parser, capa de renderizado, traducción posterior) se llena la verificación para títulos vacíos, permitiendo que las noticias sin título se muestren correctamente.

  • Mejora de calidad en la traducción : La prompt de traducción exige conservar el orden de los indicadores y los resultados vacíos ya no dan lugar al título original.

2026/03/28 - v6.6.0

  • Mejora en navegador del informe HTML : Al abrir el informe en navegadores se cambia automáticamente a datos de pantalla completa, los grupos de palabras clave y la visualización independiente permiten flujo rápido por pestañas, y el cuadro de búsqueda filtra títulos al instante; el cliente de correo sigue mostrando el formato estrecho original, sin retrocesos.

  • Modo oscuro : Un solo clic cambia el tema claro, recuerda automáticamente tus preferencias y es ideal para la lectura nocturna.

  • Copiar noticias con un clic : al pasar el cursor por el número de la noticia, copiecemos título y enlace para compartir.

  • Optimización de exportación : combina capture de pantalla completa y capture por sección en un menú desplegable de exportación, ocando automáticamente un diseño limpio en la captura.

  • Sistema de atajos : soporta W para modo ginés, D modo oscuro, / para buscar y ? para ver información sobre atajos.

  • Barra de progreso de lectura : la parte superior de la página muestra un indicador de progreso en tiempo real.

2026/03/12 - v6.5.0

  • Sistema de filtrado inteligente por IA : ya no necesitas escribir palabras clave. En ai_interests.txt describe con lenguaje natural (p. ej., "quiero ver noticias de IA y nuevas energías"), the IA extra automáticamente etiquetas y analiza cada una; solo se te encuestan temas interesantes. Si la IA falla, se vuelve automáticamente a coincidencia de palabras clave, sin interrumpir envío.

  • Cada franja de tiempo puede tener un método de filtrado distinto : Cada segmento del Timeline es ahora configurable de forma independiente, tanto el filtro como los temas. Por ejemplo: por la mañana usar "palabras clave tecnología" para un filtrado rápido; por la noche "descripción de intereses financieros con IA" para un filtrado en profundidad. Uso mismo sistema con contenidos distintos por franja.

  • El alcance del análisis de IA es independiente de los contenidos a emprendimiento: p. ej. los datos analizados por IA pueden ser distintas del contenido del envío. El envío puede incluir únicamente mensajes nuevos (evitando repeticiones) mientras que la IA analiza todas las noticias del día (tendencias completas). Cada franja de horas puede definir también su modo de análisis.

  • La IA ahorra en el uso del filtrado : las noticias ya analizadas no consumen tokens; si cambias la descripción de intereses, la IA evalúa el cambio: cambios pequeños solo se actualizan las etiquetas afectadas; cambios grandes hay recategorización completa.

  • Configuración múltiple con etiquetas aisladas : archivos de palabras clave personalizadas en config/custom/keyword/ y archivos de intereses IA en config/custom/ai/; las etiquetas de archivos distintos son independientes y no interfieren entre sí.

  • Precisión en la traducción con IA : Puedes controlar por categoría si se traduce el ranking, RSS o el área independiente; las regiones no mostradas se omiten automáticamente para no colgar tokens.

  • Subida en lote a producción remota : varias operaciones de escritura se acumulan y se envían juntas a la nube; reduce el número de llamadas a la API.

  • Límite por palabra clave/grupo : la IA puede limitar por número de noticias mostradas a cada grupo mediante max_news_per_keyword, evitando que un solo tema ocupe el mensaje completo.

  • Detección inteligente de conflictos de horario : si dos franjas se superponen, el sistema detecta y evitas, evitando que el conflicto provoque comportamientos inesperados.

  • Se corrigen varios errores.

2026/02/09 - v6.0.0

Breaking Change: El config.yaml se actualiza a 2.0.0, y las viejas opciones push_window y analysis_window ya no son compatibles. Consulta las referencias al nuevo config.yaml.

  • Un cubriendo schedule : se añade timeline.yaml para controlar desde una sola configuración: "cuando capturar / enviar / analizar con IA".

  • 5 plantillas por defecto : always_on (24/7, por defecto), morning_evening (resumen al inicio y noche), office_hours (horario de oficina), night_owl (trasnochador), custom (personalizable); también puedes añadir tu propia plantilla en presets:, solo es necesario que la clave no se repita y pones el nombre de tu plantilla en la configuración de config.yaml.

  • Configuración flexible en franja horaria : soporta distinción entre laborables/festivos, franjas que cruzan normes degradados y once per period en el período.

  • Editor visual de configuración :

    • Nueva pestaña timeline.yaml, estéticamente junto con config.yaml / frequency\_words.txt.

    • Selección de tarjeta en modos preestablecidos: gentle clic para alternar, y sincronización automática con schedule.preset de config.yaml.

    • Vista de tiempo en semana: barra horizontal 7 días × 24 horas, con colores para distinguir el estado de envío/análisis/captación.

    • Controles interactivos: interruptores, boletines, selectos; los cambios se sincronizan en el YAML derecho simultáneamente.

    • Desplegable de asignación semanal: se genera dinámicamente según el plan diario, y con clic múltiple o se completa el configurción.

  • Optimización de estabilidad de prompt de IA (ai_analysis_prompt.txt v2.0.0) :

    • Normas de formato independientes: saltos / etiquetas / numeración / restricciones extraídos de los valores JSON como sección independiente.

    • Simplificación de plantilla JSON: las descripciones de campo se reducen a una frase + límite dimensionado, reduciendo el desorden de salida de la IA.

    • Eliminación del formato Markdown en el system prompt, al frente con la instrucción "no Markdown".

    • Se marcan todos los campos JSON como opcionales, no hay error si falta alguno, mejor tolerante a errores.

  • Nueva sección de resumen de IA de modo independiente (ai_analysis.include_standalone) :

    • Añade un interruptor independiente; activado, la IA generará una síntesis central para cada fuente standalone.

    • Desacoplamiento entre el análisis de IA y el contenido del envío: se puede analizar completamente todos listas de tendencia sin necesidad de visualizar el área independiente.

    • Soporta plataformas de ranking y RSS, incluida crítica de ranking/hora/trayección.

    • El análisis de tráfico enlaza el include_rank_timeline: si está desactivado, se hace análisis basado en la posición; si activado, se realiza análisis profundo de tendencias.

    • Añade el campo JSON standalone_summaries (síntesis rápida de fuentes independientes) y todos los canales de pago lo han adaptado.

2026/01/28 - v5.5.0

Igual que la función MCP no he creado, para estar no he creado repositorio en un repositorio; al ser puramente frontend, lo pongo igual en mismo.

  • Añade una visualización de la configurador para trendradar.

2026/02/02 - mcp-v3

  • Nuevo espejo de servicio MCP independiente wantcat/trendradar-mcp

  • Soporte para implementar la función de análisis de IA con Docker, que se sirve a través de una interfaz HTTP (puerto 3333)

  • Arquitectura de doble contenedor: el servicio de noticias y el servicio MCP se ejecutan de forma independiente, y cada uno puede escalarse y reiniciarse por separado

  • Ver Implementación con Docker - Servicio MCP

🌐 Soporte de servidor web

  • Nuevo servidor web integrado que permite acceder a los informes generados a través del navegador

  • Control de inicio/detención mediante el comando manage.py: docker exec -it trendradar python manage.py start_webserver

  • Dirección de acceso: http://localhost:8080 (el puerto es configurable)

  • Características de seguridad: servicio de archivos estáticos, restricción de directorios, acceso local

  • Soporta dos modos: inicio automático y control manual

📖 Optimización de la documentación

🔧 Notas de actualización:

  • Usuarios de GitHub Fork: actualice main.py, config/config.yaml (nuevo soporte para envío a múltiples cuentas, no es necesario modificar la configuración existente)

  • Envío a múltiples cuentas: nueva función, deshabilitada por defecto, la configuración de una sola cuenta existente no se ve afectada

2025/11/26 - mcp-v1.0.3

Actualización del módulo MCP:

  • Nueva herramienta de análisis de fechas resolve_date_range, que resuelve el problema de las fechas inconsistentes calculadas por los modelos de IA

  • Soporte para el análisis de expresiones de fecha en lenguaje natural (esta semana, últimos 7 días, mes pasado, etc.)

  • El número total de herramientas aumenta de 13 a 14

2025/11/28 - v3.4.1

🔧 Optimización de formato

  1. Mejora del envío de Bark

    • Bark ahora soporta la representación de Markdown

    • Se habilita el formato Markdown nativo: negrita, enlaces, listas, bloques de código, etc.

    • Se elimina la conversión a texto plano, aprovechando al máximo la capacidad de representación nativa de Bark

  2. Precisión del formato de Slack

    • Se utiliza el formato mrkdwn específico para procesar el contenido en lotes

    • Se mejora la precisión de la estimación del tamaño en bytes (para evitar exceder el límite de mensajes)

    • Se optimiza el formato de enlace: <url|text> y la sintaxis de negrita: *text*

  3. Mejora del rendimiento

    • La conversión de formato se realiza durante el proceso de división en lotes, evitando un segundo procesamiento

    • Estimación precisa del tamaño del mensaje, reduciendo la tasa de fallos de envío

🔧 Instrucciones de actualización:

  • Usuarios de GitHub Fork: actualice main.py, config.yaml

2025/11/25 - v3.4.0

🎉 Nuevo soporte de envío a Slack

  1. Canal de envío para colaboración en equipo

    • Soporte para Slack Incoming Webhooks (la herramienta de colaboración en equipo más popular del mundo)

    • Gestión centralizada de mensajes, ideal para compartir noticias de actualidad en equipo

    • Soporte para el formato mrkdwn (negrita, enlaces, etc.)

  2. Múltiples métodos de implementación

    • GitHub Actions: configure el secreto SLACK_WEBHOOK_URL

    • Docker: variable de entorno SLACK_WEBHOOK_URL

    • Ejecución local: archivo de configuración config/config.yaml

📖 Tutorial de configuración detallado: Inicio rápido - Envío a Slack

  • Se optimiza la experiencia de instalación de MCP con un solo clic en setup-windows.bat y setup-windows-en.bat

🔧 Instrucciones de actualización:

  • Usuarios de GitHub Fork: actualice main.py, config/config.yaml, .github/workflows/crawler.yml

2025/11/24 - v3.3.0

🎉 Nuevo soporte de envío a Bark

  1. Canal de envío exclusivo para iOS

    • Soporte para el envío de Bark (basado en APNs, plataforma iOS)

    • Gratuito y de código abierto, simple y eficiente, sin interferencias publicitarias

    • Soporta tanto el servidor oficial como la creación de un servidor propio

  2. Múltiples métodos de implementación

    • GitHub Actions: configure el secreto BARK_URL

    • Docker: variable de entorno BARK_URL

    • Ejecución local: archivo de configuración config/config.yaml

📖 Tutorial de configuración detallado: Inicio rápido - Envío a Bark

🐛 Corrección de errores

  • Se corrige el problema de que la configuración ntfy_server_url en config.yaml no surtía efecto (#345)

🔧 Instrucciones de actualización:

  • Usuarios de GitHub Fork: actualice main.py, config/config.yaml, .github/workflows/crawler.yml

2025/11/23 - v3.2.0

🎯 Nuevas funciones de personalización avanzada

  1. Configuración de prioridad de ordenación de palabras clave

    • Soporta dos estrategias de ordenación: prioridad por popularidad vs. prioridad por orden de configuración

    • Satisface diferentes escenarios de uso: seguimiento de tendencias o atención personalizada

  2. Control preciso de la cantidad mostrada

    • Configuración global: limita uniformemente la cantidad mostrada para todas las palabras clave

    • Configuración individual: use la sintaxis @número para establecer límites para palabras clave específicas

    • Controla eficazmente la longitud del envío y destaca el contenido importante

📖 Tutorial de configuración detallado: Configuración de palabras clave - Configuración avanzada

🔧 Instrucciones de actualización:

  • Usuarios de GitHub Fork: actualice main.py, config/config.yaml

2025/11/18 - mcp-v1.0.2

Actualización del módulo MCP:

  • Se optimiza el caso en el que al consultar las noticias de hoy se podían devolver por error fechas pasadas

2025/11/22 - v3.1.1

  • Se corrige el fallo causado por datos anómalos: se resuelve el error 'float' object has no attribute 'lower' que algunos usuarios encontraban en el entorno de GitHub Actions

  • Nuevo mecanismo de doble protección: se filtran los títulos no válidos (None, float, cadena vacía) en la fase de obtención de datos, y también se añade una comprobación de tipos en el punto de llamada de la función

  • Se mejora la estabilidad del sistema, asegurando que pueda funcionar correctamente incluso cuando la fuente de datos devuelve formatos anómalos

Instrucciones de actualización (usuarios de GitHub Fork):

  • Actualización obligatoria: main.py

  • Se recomienda el método de actualización de versión menor: copiar y reemplazar el archivo mencionado

2025/11/20 - v3.1.0

  • Nuevo soporte de envío a WeChat personal: la aplicación de WeChat Work puede enviar a WeChat personal, sin necesidad de instalar la aplicación de WeChat Work

  • Soporta dos formatos de mensaje: markdown (robot de grupo de WeChat Work) y text (aplicación de WeChat personal)

  • Nueva variable de entorno WEWORK_MSG_TYPE, compatible con GitHub Actions, Docker, docker compose y otros métodos de implementación

  • El modo text elimina automáticamente la sintaxis de Markdown, proporcionando un efecto de envío de texto plano

  • Ver la configuración de "Envío a WeChat personal" en la sección de Inicio rápido

Instrucciones de actualización (usuarios de GitHub Fork):

  • Actualización obligatoria: main.py, config/config.yaml

  • Actualización opcional: .github/workflows/crawler.yml (si se usa la implementación con GitHub Actions)

  • Se recomienda el método de actualización de versión menor: copiar y reemplazar los archivos mencionados

2025/11/12 - v3.0.5

  • Se corrige el error de lógica en la configuración del puerto SSL/TLS para el envío de correos electrónicos

  • Se optimiza el uso del puerto 465 (SSL) por defecto para los proveedores de correo (QQ/163/126)

  • Nuevo soporte de variables de entorno para Docker: los elementos de configuración principales (enable_crawler, report_mode, push_window, etc.) se pueden sobrescribir mediante variables de entorno, resolviendo el problema de que los usuarios de NAS no podían modificar el archivo de configuración (ver la sección 🐳 Implementación con Docker)

2025/10/26 - mcp-v1.0.1

Actualización del módulo MCP:

  • Se corrige el error de transmisión del parámetro de fecha en las consultas

  • Se unifica el formato de los parámetros de tiempo en todas las herramientas

2025/10/31 - v3.0.4

  • Se resuelve el error de Feishu causado por contenido de envío demasiado largo, implementando el envío por lotes

2025/10/23 - v3.0.3

  • Se amplía el rango de visualización de los mensajes de error de ntfy

2025/10/21 - v3.0.2

  • Se corrige el problema de codificación en el envío de ntfy

2025/10/20 - v3.0.0

Actualización importante - Función de análisis de IA disponible ✨

  • Funciones principales:

    • Nuevo servidor de análisis de IA basado en MCP (Model Context Protocol)

    • Soporte para 17 herramientas de análisis inteligente: consulta básica, búsqueda inteligente, análisis avanzado, consulta RSS, gestión del sistema

    • Interacción en lenguaje natural: consulta y análisis de datos de noticias mediante conversación

    • Soporte para múltiples clientes: Claude Desktop, Cherry Studio, Cursor, Cline, etc.

  • Capacidades de análisis:

    • Análisis de tendencias de temas (seguimiento de popularidad, ciclo de vida, detección de viralización, predicción de tendencias)

    • Información de datos (comparación de plataformas, estadísticas de actividad, co-ocurrencia de palabras clave)

    • Análisis de sentimiento, búsqueda de noticias similares, generación de resúmenes inteligentes

    • Búsqueda de noticias históricas relacionadas, búsqueda multimodal

  • Nota de actualización:

    • Esta es una función de análisis de IA independiente, no afecta a la función de envío existente

    • Se puede usar de forma opcional, no es necesario actualizar la implementación existente

2025/10/15 - v2.4.4

  • Contenido de la actualización:

    • Se corrige el problema de codificación en el envío de ntfy + 1

    • Se corrige el problema de la ventana de tiempo de envío

  • Nota de actualización:

    • Se recomienda [actualización de versión menor]

2025/10/10 - v2.4.3

Gracias a nidaye996 por descubrir el problema de experiencia

  • Contenido de la actualización:

    • Se renombra el "modo de envío silencioso" como "control de ventana de tiempo de envío" para mejorar la comprensión de la función

    • Se aclara que la ventana de tiempo de envío es una función adicional opcional, que se puede combinar con los tres modos de envío

    • Se mejoran los comentarios y las descripciones de la documentación para que la función esté más clara

  • Nota de actualización:

    • Esto es solo una refactorización, no es necesario actualizar

2025/10/8 - v2.4.2

  • Contenido de la actualización:

    • Se corrige el problema de codificación en el envío de ntfy

    • Se corrige el problema de la falta del archivo de configuración

    • Se optimiza el efecto de envío de ntfy

    • Se añade la función de exportación de imágenes por segmentos en la página de GitHub

  • Nota de actualización:

    • Se recomienda [actualización de versión principal]

2025/10/2 - v2.4.0

Nueva notificación de envío de ntfy

  • Funciones principales:

    • Soporte para el servicio público ntfy.sh y servidores autoalojados

  • Escenarios de uso:

    • Ideal para usuarios que buscan privacidad (soporta autoalojamiento)

    • Envío multiplataforma (iOS, Android, Escritorio, Web)

    • No requiere registro de cuenta (servidor público)

    • Open source y gratuito (licencia MIT)

  • Nota de actualización:

    • Se recomienda [actualización de versión principal]

2025/09/26 - v2.3.2

  • Se corrige el problema de que se omitía la verificación de la configuración de notificación por correo electrónico (#88)

Nota de corrección:

  • Se resuelve el problema de que, incluso con la notificación por correo configurada correctamente, el sistema seguía mostrando "No se ha configurado ningún webhook"

2025/09/22 - v2.3.1

  • Nueva función de envío por correo electrónico: soporta el envío de informes de noticias de actualidad a la bandeja de entrada

  • Detección inteligente de SMTP: detecta automáticamente la configuración de más de 10 proveedores de correo, como Gmail, QQ Mail, Outlook, NetEase Mail, etc.

  • Formato HTML elegante: el contenido del correo utiliza el mismo formato HTML que la versión web, con un diseño elegante y adaptado a dispositivos móviles

  • Soporte de envío por lotes: admite múltiples destinatarios, separados por comas para enviar a varias personas a la vez

  • SMTP personalizado: permite personalizar el servidor y el puerto SMTP

  • Se corrige el problema de conexión de red en la construcción de Docker

Instrucciones de uso:

  • Escenario de uso: adecuado para usuarios que necesitan archivar correos, compartir en equipo o informes programados

  • Correos compatibles: Gmail, QQ Mail, Outlook/Hotmail, 163/126 Mail, Sina Mail, Sohu Mail, etc.

Nota de actualización:

  • Esta actualización contiene bastantes cambios; si desea actualizar, se recomienda [actualización de versión principal]

2025/09/17 - v2.2.0

  • Nueva función para guardar las imágenes de las noticias con un solo clic, para que puedas compartir fácilmente las noticias de actualidad que te interesan

Instrucciones de uso:

  • Escenario de uso: cuando hayas activado la función de versión web (GitHub Pages) siguiendo el tutorial

  • Método de uso: abre el enlace de la página web con tu teléfono o computadora, y haz clic en el botón "Guardar como imagen" en la parte superior de la página

  • Resultado real: el sistema creará automáticamente una imagen elegante del informe de noticias actual y la guardará en el álbum de tu teléfono o en el escritorio de tu computadora

  • Facilidad para compartir: puedes enviar esta imagen directamente a tus amigos, publicarla en tu estado de WeChat, o compartirla en el grupo de trabajo, para que otros también puedan ver la información importante que has descubierto

2025/09/13 - v2.1.2

  • Se resuelve el problema de fallo en el envío de noticias de DingTalk debido al límite de capacidad de envío (se utiliza el envío por lotes)

2025/09/04 - v2.1.1

  • Se corrige el problema de que Docker no podía ejecutarse correctamente en algunas arquitecturas

  • Se publica oficialmente la imagen de Docker wantcat/trendradar, con soporte para múltiples arquitecturas

  • Se optimiza el proceso de implementación con Docker, permitiendo un uso rápido sin necesidad de construir localmente

2025/08/30 - v2.1.0

Mejoras principales:

  • Optimización de la lógica de envío: se cambia de "enviar en cada ejecución" a "envío controlable dentro de una ventana de tiempo"

  • Control de ventana de tiempo: se puede establecer un rango de tiempo de envío para evitar interrupciones fuera del horario laboral

  • Frecuencia de envío opcional: dentro del período de tiempo, se admite un envío único o múltiples envíos

Nota de actualización:

  • Esta función está deshabilitada por defecto, debe activarse manualmente en config.yaml para habilitar el control de la ventana de tiempo de envío

  • La actualización requiere actualizar tanto main.py como config.yaml

2025/08/27 - v2.0.4

  • Esta versión no es una corrección de errores, sino un recordatorio importante

  • Asegúrese de guardar bien los webhooks, no los haga públicos, no los haga públicos, no los haga públicos

  • Si ha implementado este proyecto en GitHub mediante un fork, rellene los webhooks en los Secretos de GitHub, no en config.yaml

  • Si ya ha expuesto los webhooks o los ha rellenado en config.yaml, se recomienda eliminarlos y generarlos de nuevo

2025/08/06 - v2.0.3

  • Se optimiza el efecto de la versión web de la página de GitHub para facilitar su uso en dispositivos móviles

2025/07/28 - v2.0.2

  • Se refactoriza el código

  • Se resuelve el problema de que el número de versión se omitía fácilmente en las modificaciones

2025/07/27 - v2.0.1

Problemas corregidos:

  1. El problema de ejecución anómala causado por los caracteres de nueva línea CRLF en el script de shell de Docker

  2. El problema lógico de que cuando frequency_words.txt está vacío, el envío de noticias también resultaba vacío

  • Después de la corrección, cuando elijas que frequency_words.txt esté vacío, se enviarán todas las noticias, pero debido al límite de tamaño de los mensajes de envío, se recomienda hacer los siguientes ajustes

    • Opción 1: Desactivar el envío al teléfono y elegir solo la implementación de GitHub Pages (esta es la opción que ofrece la información más completa, ya que reordenará las noticias de actualidad de todas las plataformas según tu algoritmo de búsqueda de tendencias personalizado)

    • Opción 2: Reducir las plataformas de envío, priorizando WeChat Work o Telegram, ya que en estas dos plataformas he implementado la función de envío por lotes (debido a que el envío por lotes afecta la experiencia de envío, y solo estas dos plataformas tienen un límite de capacidad de envío muy pequeño, por lo que no tuve más remedio que implementar la función de envío por lotes, pero al menos se garantiza que la información se reciba completa)

  • Opción 3: Se puede combinar con la opción 2, y elegir el modo current o incremental para reducir eficazmente el contenido enviado de una sola vez

2025/07/17 - v2.0.0

Refactorización importante:

  • Refactorización de la gestión de configuración: toda la configuración ahora se gestiona a través del archivo config/config.yaml (no he dividido main.py para que sea más fácil copiar y actualizar)

  • Mejora del modo de ejecución: soporta tres modos - daily (resumen diario), current (lista actual), incremental (monitoreo incremental)

  • Soporte de Docker: plan de implementación completo de Docker, compatible con la ejecución en contenedores

Descripción de los archivos de configuración:

  • config/config.yaml - archivo de configuración principal (configuración de la aplicación, configuración del rastreador, configuración de notificaciones, configuración de plataformas, etc.)

  • config/frequency_words.txt - configuración de palabras clave (configuración de palabras de monitoreo)

2025/07/09 - v1.4.1

Nueva función: se añade el envío incremental (configuración FOCUS_NEW_ONLY en el encabezado de main.py). Este interruptor solo se preocupa por los nuevos temas, no por la tendencia continua, y solo envía una notificación cuando hay contenido nuevo.

Problema corregido: en algunos casos, se producía una anomalía de formato ocasional debido a que las noticias contenían símbolos especiales.

2025/06/23 - v1.3.0

Los mensajes de envío de WeChat Work y Telegram tienen un límite de longitud. Para ello, he adoptado el método de dividir el mensaje en partes para el envío. La documentación de desarrollo se encuentra en WeChat Work y Telegram

2025/06/21 - v1.2.1

En las versiones anteriores a esta, no solo era necesario copiar y reemplazar main.py, sino que también era necesario copiar y reemplazar crawler.yml https://github.com/sansan0/TrendRadar/blob/master/.github/workflows/crawler.yml

2025/06/19 - v1.2.0

Gracias a la investigación de claude sobre las API de las plataformas, que me permitió completar rápidamente la adaptación de las plataformas (aunque el código quedó más redundante~)

  1. Soporte para los canales de envío de Telegram, WeChat Work y DingTalk, con soporte para configuración de múltiples canales y envío simultáneo

2025/06/18 - v1.1.0

¡200 estrellas⭐! Sigo animando a todos. Recientemente, gracias a mi "insistencia", muchas personas han compartido, dado "me gusta" y recomendado mi proyecto en mi cuenta pública, y he visto los datos de apoyo de cuentas específicas en el fondo. Muchos se han convertido en seguidores de la ronda ángel (llevo jugando con la cuenta pública solo un poco más de un mes, aunque la registré hace siete u ocho años, es decir, me subí al tren temprano pero salí tarde), pero como no me dejaron comentarios ni mensajes privados, no puedo responder a cada uno y agradecer su apoyo. ¡Gracias a todos aquí!

  1. Actualización importante: se añade un peso, ahora las noticias que ves son las más populares y con mayor atención, y aparecen en la parte superior

  2. Actualización de la documentación de uso, porque recientemente se han añadido muchas funciones, y la documentación de uso anterior la escribí de forma perezosa y simple (ver el tutorial completo de configuración de ⚙️ frequency_words.txt a continuación)

2025/06/16 - v1.0.0

  1. Se añade un aviso de actualización de la nueva versión del proyecto, activado por defecto. Para desactivarlo, puede cambiar el valor True de "FEISHU_SHOW_VERSION_UPDATE": True a False en main.py

2025/06/13+14

  1. Se elimina el código de compatibilidad. Los que hayan hecho un fork anteriormente, si copian el código directamente, verán un error en la visualización del mismo día (se normalizará al día siguiente)

  2. Se añade una visualización de noticias nuevas en la parte inferior de Feishu y HTML

2025/06/09

¡100 estrellas⭐!**! Escribo una pequeña función para animar a todos. El archivo frequency_words.txt añade una función de [palabra obligatoria], que se usa con el signo +

  1. Sintaxis de la palabra obligatoria:
    "唐僧" o "猪八戒" deben aparecer simultáneamente en el título para que se incluya en las noticias enviadas

+唐僧
+猪八戒
  1. La prioridad de la palabra de filtro es mayor:
    Si el título coincide con la palabra de filtro "唐僧念经", entonces, aunque la palabra obligatoria contenga "唐僧", no se mostrará

+唐僧
!唐僧念经

2025/06/02

  1. La página web y el mensaje de Feishu admiten el salto directo a la noticia detallada desde el teléfono

  2. Optimización del efecto de visualización + 1

2025/05/26

  1. Optimización del efecto de visualización de los mensajes de Feishu

✨ Funciones principales

Agregación de tendencias de toda la red

  • Zhihu

  • TikTok

  • Bilibili (tendencias de búsqueda)

  • Wall Street Journal

  • Tieba

  • Baidu (tendencias de búsqueda)

  • Cailian Press (tendencias)

  • Pengpai News

  • Phoenix News

  • Today's Headlines

  • Weibo

Por defecto, se monitorean 11 plataformas principales, pero también puede añadir plataformas adicionales usted mismo

💡 El tutorial de configuración detallado se encuentra en Configuración detallada - Configuración de plataformas

Soporte de fuentes de suscripción RSS (nuevo en v4.5.0)

Soporte para el rastreo de fuentes de suscripción RSS/Atom, con estadísticas agrupadas por palabras clave (con el mismo formato que las listas de tendencias):

  • Formato unificado: RSS y listas de tendencias utilizan la misma coincidencia de palabras clave y formato de visualización

  • Configuración simple: añada fuentes RSS directamente en config.yaml

  • Envío combinado: las listas de tendencias y RSS se combinan en un solo mensaje de envío

  • Filtro de novedad: filtra automáticamente los artículos antiguos que superen un número determinado de días, evitando envíos duplicados. Soporta un número de días predeterminado global y una configuración independiente por fuente

💡 RSS utiliza el mismo frequency_words.txt que las listas de tendencias para el filtrado de palabras clave

Editor de configuración visual

Proporciona una interfaz de configuración gráfica basada en web, sin necesidad de editar manualmente el archivo YAML. Todos los elementos de configuración se pueden modificar y exportar mediante formularios.

👉 Experiencia en línea: https://sansan0.github.io/TrendRadar/

Estrategia de envío inteligente

Tres modos de envío:

Modo

Escenario de uso

Características de envío

Resumen diario (daily)

Gerentes de empresa / usuarios generales

Envío puntual de todas las noticias coincidentes del día (incluye las enviadas anteriormente)

Lista actual (current)

Creadores de contenido / creadores de contenido

Envío puntual de las noticias coincidentes de la lista actual (las que permanecen en la lista aparecen cada vez)

Monitoreo incremental (incremental)

Inversores / operadores

Solo envía contenido nuevo, cero duplicados

💡 Guía de selección rápida:

  • No quiero ver noticias duplicadas → use incremental (monitoreo incremental)

  • Quiero ver la tendencia completa de la lista → use current (lista actual)

  • Necesito un informe de resumen diario → use daily (resumen diario)

La comparación detallada y el tutorial de configuración se encuentran en Configuración detallada - Explicación de los modos de envío

Funciones adicionales (opcionales):

Función

Descripción

Valor predeterminado

Sistema de programación

Programación diaria de lunes a domingo: asigna diferentes períodos de tiempo, modos de envío y estrategias de análisis de IA para cada día. Cada período puede configurar de forma independiente el método de filtrado (palabras clave/IA) y la dirección de interés, para ver diferentes tipos de noticias en diferentes momentos. Incluye 5 ajustes preestablecidos (always_on / morning_evening / office_hours / night_owl / custom), y también se puede personalizar. Soporta diferencias entre días laborables y fines de semana, períodos que cruzan la medianoche, deduplicación por período y detección de conflictos de períodos (v6.0.0 + v6.5.0)

morning_evening

Configuración del orden del contenido

Ajusta el orden de visualización de las diferentes áreas (lista de tendencias, nuevas tendencias, RSS, área de visualización independiente, análisis de IA) mediante display.region_order; controla si cada área se muestra mediante display.regions (v5.2.0)

Ver archivo de configuración

Cambio de modo de visualización

keyword=agrupar por palabra clave, platform=agrupar por plataforma (nuevo en v4.6.0)

keyword

💡 El tutorial de configuración detallado se encuentra en ¿Cómo se muestran los contenidos de los envíos? y ¿Cuándo se envía?

Filtrado preciso de contenido

Establece palabras clave personales (como: IA, BYD, política educativa) para enviar solo las noticias de actualidad relevantes y filtrar la información irrelevante

💡 Tutorial de configuración básica: Configuración de palabras clave - Sintaxis básica

💡 Tutorial de configuración avanzada: Configuración de palabras clave - Configuración avanzada

💡 También se puede no hacer ningún filtrado y enviar todas las noticias de actualidad (dejar frequency_words.txt vacío)

Filtrado inteligente de noticias con IA (nuevo en v6.5.0)

Describe tu interés en lenguaje natural, y la IA clasifica automáticamente las noticias, reemplazando la coincidencia tradicional de palabras clave

  • Descripción de intereses en lenguaje natural: Escribe tus áreas de interés en ai_interests.txt con lenguaje cotidiano, sin necesidad de aprender sintaxis de palabras clave

  • Procesamiento inteligente en dos fases: La IA primero extrae etiquetas estructuradas de la descripción de intereses y luego clasifica y puntúa las noticias por lotes según las etiquetas

  • Control de umbral de puntuación: Controla con precisión la calidad del envío mediante ai_filter.min_score, solo envía noticias de alta relevancia

  • Respaldo automático: Si el filtrado de IA falla, se revierte automáticamente a la coincidencia de palabras clave para garantizar que el envío no se interrumpa

  • Actualización inteligente de etiquetas: Cuando cambian los intereses, la IA evalúa automáticamente la magnitud del cambio y decide si realiza una reclasificación incremental o completa

  • Cambio flexible: filter.method admite dos modos: keyword (predeterminado) y ai; Timeline puede sobrescribir por franja horaria

  • Personalización por franjas horarias: Se pueden usar diferentes archivos de palabras clave o descripciones de intereses de IA según el período. Por ejemplo, usar el "léxico tecnológico" por la mañana para un filtrado rápido, y cambiar al "interés financiero" por la noche para un filtrado profundo con IA

# config.yaml 快速启用示例
filter:
  method: ai          # keyword(默认)| ai
ai_filter:
  min_score: 6         # 推送最低分数阈值(1-10)

💡 El filtrado de IA comparte la configuración del modelo con el análisis/traducción de IA; solo necesitas configurar ai.api_key una vez

Análisis de tendencias de temas candentes

Sigue en tiempo real los cambios de popularidad de las noticias, para que no solo sepas "qué está en tendencia", sino que también comprendas "cómo evolucionan los temas candentes"

  • Seguimiento de línea temporal: Registra el lapso de tiempo completo de cada noticia desde su primera aparición hasta su última aparición

  • Cambio de popularidad: Estadísticas de cambios de ranking y frecuencia de aparición de noticias en diferentes períodos

  • Detección de novedades: Identifica en tiempo real los nuevos temas candentes que aparecen, marcados con 🆕 para avisar de inmediato

  • Análisis de persistencia: Distingue entre temas candentes puntuales y noticias profundas que siguen desarrollándose

  • Comparación entre plataformas: El rendimiento de ranking de la misma noticia en diferentes plataformas, para ver las diferencias de atención de los medios

💡 La explicación del formato de envío se encuentra en Explicación del formato de mensajes

Algoritmo de temas candentes personalizado

Ya no te dejes llevar por los algoritmos de cada plataforma; TrendRadar reorganiza las búsquedas candentes de toda la red

💡 Las tres proporciones se pueden ajustar; consulta Detalles de configuración - Ajuste de pesos de temas candentes

Envío multicanal y multi-cuenta

Soporta WeCom (+ plan de envío a WeChat personal), Feishu, DingTalk, Telegram, Correo electrónico, ntfy, Bark, Slack, Webhook genérico (compatible con Discord, IFTTT y cualquier otra plataforma); los mensajes llegan directamente al teléfono móvil y al correo

💡 Tutorial de configuración detallado en Enviar a múltiples grupos/dispositivos

Traducción multilingüe con IA (nuevo en v5.2.0)

Traduce el contenido enviado a cualquier idioma, rompiendo las barreras del idioma; ya sea para leer temas candentes nacionales o para suscribirte a información internacional mediante RSS, podrás obtenerla fácilmente en tu idioma materno

  • Traducción con un clic: Configura ai_translation.enabled: true y el idioma de destino en config.yaml

  • Soporte multilingüe: Admite English, Korean, Japanese, French y cualquier otro idioma

  • Procesamiento por lotes inteligente: Traduce automáticamente por lotes, reduciendo las llamadas a la API y ahorrando costos

  • Estilo personalizado: Personaliza el estilo de traducción y la terminología mediante ai_translation_prompt.txt

  • Configuración de modelo compartida: Comparte la configuración del modelo de la sección ai con la función de análisis de IA

# config.yaml 快速启用示例
ai_translation:
  enabled: true
  language: "English"  # 翻译目标语言

💡 La función de traducción comparte la configuración del modelo con la función de análisis de IA; solo necesitas configurar ai.api_key una vez para usar ambas funciones

Referencia de fuentes RSS: A continuación se presentan algunas colecciones de fuentes de suscripción RSS que puedes usar según sea necesario

  • awesome-tech-rss - Blogs y medios de tecnología, emprendimiento y programación

  • awesome-rss-feeds - Colección de RSS de los principales medios de noticias mundiales

⚠️ Parte del contenido de medios extranjeros puede involucrar temas sensibles; los modelos de IA pueden negarse a traducir. Se recomienda seleccionar las fuentes de suscripción según tus necesidades reales

Mejoras del visor de informes HTML (nuevo en v6.6.0)

Al abrir el informe HTML enviado en el navegador, se desbloquea automáticamente una experiencia mejorada (los clientes de correo no se ven afectados):

  • Modo panorámico: En escritorio, cambia automáticamente a un diseño panorámico de 1200px para aprovechar al máximo el espacio de la pantalla

  • Cambio rápido con pestañas: La agrupación por palabras clave y las secciones de exhibición independientes admiten navegación con pestañas, olvídate de desplazarte por páginas largas

  • Modo oscuro: Cambia a un tema oscuro con un clic y recuerda automáticamente tu preferencia

  • Búsqueda en tiempo real: Pulsa / para abrir el cuadro de búsqueda y filtrar los títulos de noticias al instante

  • Copiado con un clic: Pasa el cursor sobre el número de la noticia para copiar el título y el enlace

  • Atajos de teclado: W para pantalla panorámica, D para modo oscuro, / para buscar, ? para ver todos los atajos

💡 Todas las funciones mejoradas se basan en mejora progresiva; los clientes de correo siguen mostrando el diseño original de 600px, sin regresiones

Arquitectura de almacenamiento flexible (actualización importante en v4.0.0)

Soporte de múltiples backends de almacenamiento:

  • Almacenamiento en la nube remoto: Predeterminado en el entorno de GitHub Actions; admite protocolo compatible con S3 (R2/OSS/COS, etc.); los datos se almacenan en la nube sin contaminar el repositorio

  • Base de datos SQLite local: Predeterminado en entornos Docker/locales; los datos son totalmente controlables

  • Selección automática de backend: Cambia inteligentemente el método de almacenamiento según el entorno de ejecución

💡 Explicación detallada en ¿Dónde se guardan los datos?

Despliegue en múltiples entornos

  • GitHub Actions: Rastreo automático programado + almacenamiento en la nube remoto (requiere renovación con check-in)

  • Despliegue con Docker: Compatible con ejecución en contenedores multiarquitectura, almacenamiento local de datos

  • Ejecución local: Ejecución directa en Windows/Mac/Linux

Envío con análisis de IA (nuevo en v5.0.0)

Utiliza modelos de IA grandes para realizar un análisis profundo del contenido enviado y generar automáticamente informes de perspectivas sobre temas candentes

  • Análisis inteligente: Analiza automáticamente tendencias de temas candentes, popularidad de palabras clave, correlaciones entre plataformas e impacto potencial

  • Múltiples proveedores: Basado en la interfaz unificada de LiteLLM, admite más de 100 proveedores de IA (DeepSeek, OpenAI, Gemini, Anthropic, Ollama local, etc.), además de cambio automático a modelos de respaldo

  • Modo de análisis independiente: El alcance del análisis de IA puede ser diferente del envío: el envío solo publica mensajes nuevos (para evitar molestias), pero la IA puede analizar todas las noticias del día (para ver la tendencia completa)

  • Envío flexible: Opcional solo contenido original, solo análisis de IA, o ambos

  • Prompt personalizado: Personaliza el ángulo de análisis mediante config/ai_analysis_prompt.txt

💡 Tutorial de configuración detallado en Deja que la IA analice los temas candentes por mí

Sección de exhibición independiente (nuevo en v5.0.0)

Proporciona una lista completa de temas candentes para plataformas designadas, sin verse afectada por el filtrado de palabras clave

  • Lista completa de temas candentes: Muestra completa de la lista de temas candentes de la plataforma designada, ideal para usuarios que quieren ver el ranking completo

  • Exhibición independiente de RSS: El contenido de fuentes RSS se puede mostrar completo, sin limitaciones de palabras clave

  • Análisis profundo con IA: Se puede activar de forma independiente el análisis de tendencias de IA sobre la lista completa de temas candentes, sin necesidad de mostrarlo en el envío

  • Configuración flexible: Admite configurar plataformas de exhibición, fuentes RSS y número máximo de elementos

💡 Tutorial de configuración detallado en ¿Cómo se muestra el contenido enviado? - Sección de exhibición independiente

Análisis inteligente con IA (nuevo en v3.0.0)

Sistema de análisis conversacional con IA basado en el protocolo MCP (Model Context Protocol), que te permite explorar en profundidad los datos de noticias con lenguaje natural

💡 Consejo de uso: La función de IA requiere datos de noticias locales

  • El proyecto incluye datos de prueba, puedes probar la función de inmediato

  • Se recomienda desplegar y ejecutar el proyecto para obtener datos más actualizados

Consulta Análisis inteligente con IA

Despliegue web

Después de ejecutar, se genera index.html en el directorio raíz, que es la página completa del informe de noticias.

Método de despliegue: Haz clic en Use this template para crear un repositorio; puedes desplegarlo en Cloudflare Pages, GitHub Pages u otras plataformas de alojamiento estático.

💡 Consejo: Activar GitHub Pages te proporciona una dirección de acceso en línea; entra en Configuración del repositorio → Pages para activarlo. Vista previa del resultado

⚠️ La función de almacenamiento automático de GitHub Actions se ha retirado (ese plan causaba una carga excesiva en los servidores de GitHub, afectando la estabilidad de la plataforma).

☁️ Despliegue automático en Cloudflare Pages (opcional · acceso más rápido en China)

GitHub Pages es lento en China; la velocidad de acceso de Cloudflare Pages es más amigable. Una vez configurado, cada ejecución de GitHub Actions enviará automáticamente el index.html más reciente a Cloudflare Pages, sin necesidad de ninguna operación manual.

Requisito previo: Ya has completado el despliegue con GitHub Actions y puedes generar el informe web correctamente.

① Crear un proyecto de Cloudflare Pages

Inicia sesión en Cloudflare Dashboard → Workers & Pages → Create → Pages → selecciona Upload assets (subida directa), escribe un nombre de proyecto (por ejemplo trendradar, recuérdalo), sube cualquier archivo para completar la creación inicial (luego será sobrescrito automáticamente por Actions).

② Obtener el API Token y el Account ID

  • API Token: Avatar en la esquina superior derecha → My Profile → API Tokens → Create Token → Create Custom Token, permiso: Account → Cloudflare Pages → Edit; después de crearlo, copia el Token (solo se muestra una vez).

  • Account ID: Lo encuentras en la barra lateral derecha de la página Workers & Pages (o en la esquina inferior derecha de la página Overview de cualquier dominio).

③ Añadir 3 Secrets en el repositorio de GitHub

Entra en Settings del repositorio → Secrets and variables → Actions → New repository secret, y añade en orden:

Name (nombre)

Secret (valor)

CLOUDFLARE_API_TOKEN

El API Token creado en el paso anterior

CLOUDFLARE_ACCOUNT_ID

Tu Cloudflare Account ID

CLOUDFLARE_PROJECT_NAME

El nombre del proyecto de Cloudflare Pages (por ejemplo, trendradar)

Una vez configurado, la próxima ejecución de GitHub Actions se desplegará automáticamente; la dirección de acceso será https://<nombre-del-proyecto>.pages.dev.

💡 Nota: Si falta cualquiera de los tres Secrets, el despliegue de Cloudflare se omitirá automáticamente sin afectar otras funciones como el envío de noticias; si deseas vincular un dominio personalizado, puedes configurarlo en Custom domains del proyecto Pages.

Reducir la dependencia de las apps

Pasar de "estar secuestrado por las recomendaciones algorítmicas" a "obtener proactivamente la información que deseas"

Público objetivo: Inversores, creadores de contenido, relaciones públicas de empresas, usuarios comunes interesados en la actualidad

Escenarios típicos: Monitoreo de inversiones bursátiles, seguimiento de reputación de marcas, atención a dinámicas del sector, obtención de información de la vida cotidiana

Efecto en la web (efecto de envío por correo)

Efecto de envío en Feishu

Efecto de envío con análisis de IA

Efecto en la web

Efecto de envío en Feishu

Efecto de envío con análisis de IA

🚀 Inicio rápido

Aviso: Se recomienda consultar la documentación oficial más reciente para asegurarte de que los pasos de configuración estén actualizados.

Elige el método de despliegue que mejor se adapte a ti

Ⓐ Opción 1: Despliegue con Docker (recomendado 🔥)

  • Características: Más estable que GitHub Actions, almacenamiento local de datos (sin necesidad de configurar almacenamiento en la nube)

  • Adecuado para: Tener tu propio servidor, NAS o un ordenador que funcione a largo plazo

  • Nota: Debes leer y comprender el flujo de configuración básico a continuación y luego saltar al tutorial de Docker para el despliegue.

Ⓑ Opción 2: Despliegue con GitHub Actions (contenido de este capítulo ⬇️)

  • Características: Sin servidor, los datos se almacenan en almacenamiento en la nube remoto (configuración recomendada)

  • Adecuado para: Usuarios sin servidor, que aprovechan los recursos gratuitos de GitHub

  • Nota: Se requiere configurar el almacenamiento en la nube para una experiencia completa, y se debe renovar periódicamente con check-in

Ⓒ Opción 3: Despliegue local (uv)

  • Características: Se ejecuta directamente en tu máquina, sin necesidad de Docker; adecuado para desarrollo, depuración o usuarios sin entorno Docker

  • Adecuado para: Usuarios de Windows / Mac / Linux (sin necesidad de instalar Python previamente; uv lo gestiona automáticamente)

  • Pasos:

    1. Instalar uv (si ya está instalado, puedes omitirlo; no es necesario instalar Python previamente)

    # macOS / Linux
    curl -LsSf https://astral.sh/uv/install.sh | sh
    
    # Windows (PowerShell)
    powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

    2. Clonar y ejecutar

    git clone https://github.com/sansan0/TrendRadar.git
    cd TrendRadar
    uv sync          # 自动安装 Python 和项目依赖
    uv run python -m trendradar

    💡 Consejo:

    • uv gestiona automáticamente la versión de Python, no es necesario instalar Python manualmente

    • Los usuarios de Windows también pueden hacer doble clic en setup-windows.bat para instalar las dependencias con un clic

    • Los usuarios de Mac pueden usar bash setup-mac.sh

    • Antes de ejecutar, edita config/config.yaml para completar la configuración de los canales de envío, etc.; consulta el flujo de configuración básico a continuación

1️⃣ Primer paso: Obtener el código del proyecto

Haz clic en el botón verde [Use this template] en la esquina superior derecha de la página de este repositorio → selecciona "Create a new repository".

⚠️ Aviso:

  • Todas las menciones de "Fork" en la documentación posterior pueden entenderse como "Use this template"

  • Usar Fork puede causar errores de ejecución; consulta Issue #606

2️⃣ Segundo paso: Configurar los GitHub Secrets

En tu repositorio fork, entra en Settings > Secrets and variables > Actions > New repository secret

📌 Nota importante (lee con atención):

  • Un Name corresponde a un Secret: Por cada elemento de configuración, haz clic una vez en el botón "New repository secret" y completa un par de "Name" y "Secret"

  • Es normal no ver el valor después de guardar: Por razones de seguridad, al volver a editar después de guardar, solo se puede ver el Name (nombre), no el contenido del Secret (valor)

  • Prohibido inventar nombres: El Name (nombre) del Secret debe usar estrictamente los nombres enumerados a continuación (como WEWORK_WEBHOOK_URL, FEISHU_WEBHOOK_URL, etc.); no puedes modificarlos ni crear nombres nuevos por tu cuenta, de lo contrario el sistema no podrá reconocerlos

  • Se pueden configurar varias plataformas a la vez: El sistema enviará notificaciones a todas las plataformas configuradas

Ejemplo de configuración:

Como se muestra en la imagen anterior, cada línea es un elemento de configuración:

  • Name (nombre): Debe usar los nombres fijos enumerados en el contenido desplegable a continuación (como WEWORK_WEBHOOK_URL)

  • Secret (valor): Completa el contenido real que obtuviste de la plataforma correspondiente (como la dirección del Webhook, Token, etc.)

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): WEWORK_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano para evitar errores)

  • Secret (valor): La dirección del Webhook de tu robot de WeCom

Pasos para configurar el robot:

Configuración en el móvil:

  1. Abre la app de WeCom → entra en el grupo de chat interno de destino

  2. Haz clic en el botón "…" en la esquina superior derecha → selecciona "Mensajes"

  3. Haz clic en "Añadir" → escribe "TrendRadar" como nombre

  4. Copia la dirección del Webhook, haz clic en guardar, y configura el contenido copiado en el GitHub Secret anterior

El proceso de configuración en PC es similar

Dado que este plan se basa en el mecanismo de complementos de WeCom, el estilo del envío es texto plano (sin formato markdown), pero se puede enviar directamente a WeChat personal sin necesidad de instalar la app de WeCom.

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): WEWORK_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La dirección del Webhook de tu aplicación de WeCom

  • Name (nombre): WEWORK_MSG_TYPE (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): text

Pasos de configuración:

  1. Completa la configuración del Webhook del robot de WeCom anterior

  2. Añade el Secret WEWORK_MSG_TYPE con el valor text

  3. Sigue las imágenes a continuación para vincular WeChat personal

  4. Una vez configurado, puedes eliminar la app de WeCom del móvil

Explicación:

  • Usa la misma dirección de Webhook que el robot de WeCom

  • La diferencia está en el formato del mensaje: text es texto plano, markdown es texto enriquecido (predeterminado)

  • El formato de texto plano elimina automáticamente toda la sintaxis markdown (negritas, enlaces, etc.)

Nota: El antiguo "Asistente de robots de Feishu (BotBuilder)" se retirará el 30 de junio de 2026; usa el método de robot personalizado de grupo a continuación. Las direcciones de webhook de BotBuilder existentes dejarán de funcionar y deberán reconfigurarse.

Si se activa el análisis de IA, el envío de Feishu puede sufrir ocasionalmente (aproximadamente 5% de probabilidad) un retraso de varios minutos (se presume que es por la revisión de cumplimiento de contenido generado por IA de la plataforma).

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): FEISHU_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La dirección del Webhook de tu robot personalizado de Feishu (formato: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxxx)

Pasos de configuración:

  1. Entra en el grupo de destino, haz clic en el botón Más en la esquina superior derecha del grupo y haz clic en Configuración.

Entrar en la configuración del grupo

  1. En la interfaz de Configuración de la derecha, haz clic en Robots del grupo.

Hacer clic en robots del grupo

  1. En la interfaz de Robots del grupo, haz clic en Añadir robot.

  2. En el cuadro de diálogo Añadir robot, busca y haz clic en Robot personalizado.

Seleccionar robot personalizado

  1. Configura el avatar, el nombre (por ejemplo, "TrendRadar Monitoreo de temas candentes") y la descripción del robot personalizado, y haz clic en Añadir.

Configurar la información del robot

  1. Obtén la dirección de webhook del robot personalizado y haz clic en Finalizar.

⚠️ Guarda esta dirección de webhook de forma segura; no la publiques en GitHub, blogs u otros sitios de acceso público, para evitar que se filtre y sea utilizada maliciosamente para enviar mensajes no deseados.

Copiar la dirección de webhook

  1. Configura la dirección de Webhook copiada en FEISHU_WEBHOOK_URL en los GitHub Secrets.

💡 Una vez configurado, puedes hacer clic en la imagen del robot a la derecha del nombre del grupo para entrar en la página de detalles del robot personalizado y gestionar la información de configuración.

📖 Documentación oficial: Guía de uso de robots personalizados

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): DINGTALK_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La dirección del Webhook de tu robot de DingTalk

Pasos para configurar el robot:

  1. Crear el robot (solo compatible con PC):

    • Abre el cliente de PC de DingTalk y entra en el chat grupal de destino

    • Haz clic en el icono de configuración del grupo (⚙️) → desplázate hacia abajo y busca "Robot" y haz clic

    • Selecciona "Añadir robot" → "Personalizado"

  2. Configurar el robot:

    • Configura el nombre del robot

    • Configuración de seguridad:

      • Palabra clave personalizada: Configura "热点"

  3. Completar la configuración:

    • Marca el acuerdo de términos de servicio → haz clic en "Finalizar"

    • Copia la URL del Webhook obtenida

    • Configura la URL en DINGTALK_WEBHOOK_URL en los GitHub Secrets

Nota: En el móvil solo se pueden recibir mensajes, no se pueden crear robots nuevos.

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): TELEGRAM_BOT_TOKEN (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): Tu Telegram Bot Token

  • Name (nombre): TELEGRAM_CHAT_ID (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): Tu Telegram Chat ID

Explicación: Telegram requiere configurar dos Secrets; haz clic dos veces en el botón "New repository secret" para añadirlos

Pasos para configurar el bot:

  1. Crear el bot:

    • Busca @BotFather en Telegram (presta atención a las mayúsculas y minúsculas; tiene una insignia azul con una marca de verificación y algo como 37849827 monthly users; ese es el oficial; hay cuentas que imitan a las oficiales, ten cuidado al distinguirlas)

    • Envía el comando /newbot para crear un bot nuevo

    • Configura el nombre del bot (debe terminar en "bot"; es fácil encontrar nombres duplicados, así que tendrás que esforzarte para pensar en nombres diferentes)

    • Obtén el Bot Token (formato como: 123456789:AAHfiqksKZ8WmR2zSjiQ7_v4TMAKdiHm9T0)

  2. Obtener el Chat ID:

    Método 1: Obtenerlo mediante la API oficial

    • Primero envía un mensaje a tu bot

    • Accede a: https://api.telegram.org/bot<Tu Bot Token>/getUpdates

    • En el JSON devuelto, busca el número en "chat":{"id":número}

    Método 2: Usar una herramienta de terceros

    • Busca @userinfobot y envía /start

    • Obtén tu ID de usuario como Chat ID

  3. Configurar en GitHub:

    • TELEGRAM_BOT_TOKEN: Completa el Bot Token obtenido en el paso 1

    • TELEGRAM_CHAT_ID: Completa el Chat ID obtenido en el paso 2

  • Nota: Para evitar el abuso de la función de envío masivo por correo, el envío masivo actual hace que todos los destinatarios puedan ver las direcciones de correo de los demás.

  • Si nunca has configurado el envío de correos con el siguiente tipo de configuración, no se recomienda intentarlo

⚠️ Dependencia de configuración importante: El envío por correo requiere el archivo de informe HTML. Asegúrate de que storage.formats.html en config/config.yaml esté configurado como true:

storage:
  formats:
    sqlite: true
    txt: false
    html: true   # 必须启用,否则邮件推送会失败

Si se configura como false, al enviar por correo se mostrará el error: 错误:HTML文件不存在或未提供: None

Configuración del GitHub Secret (⚠️ El Name debe coincidir estrictamente):

  • Name (nombre): EMAIL_FROM (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La dirección de correo del remitente

  • Name (nombre): EMAIL_PASSWORD (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La contraseña del correo o el código de autorización

  • Name (nombre): EMAIL_TO (copia y pega este nombre, no lo escribas a mano)

  • Secret (valor): La dirección de correo del destinatario (varios destinatarios separados por comas en inglés; también puede ser igual que EMAIL_FROM, enviándote a ti mismo)

  • Name (nombre): EMAIL_SMTP_SERVER (configuración opcional, copia y pega este nombre)

  • Secret (valor): La dirección del servidor SMTP (puede dejarse vacío; el sistema lo detectará automáticamente)

  • Name (nombre): EMAIL_SMTP_PORT (configuración opcional, copia y pega este nombre)

  • Secret (valor): El puerto SMTP (puede dejarse vacío; el sistema lo detectará automáticamente)

Explicación: El envío por correo requiere configurar al menos 3 Secrets obligatorios (EMAIL_FROM, EMAIL_PASSWORD, EMAIL_TO); los dos últimos son configuración opcional

Proveedores de correo compatibles (detección automática de configuración SMTP):

Proveedor de correo

Dominio

Servidor SMTP

Puerto

Cifrado

Gmail

gmail.com

smtp.gmail.com

587

TLS

QQ Mail

qq.com

smtp.qq.com

465

SSL

Outlook

outlook.com

smtp-mail.outlook.com

587

TLS

Hotmail

hotmail.com

smtp-mail.outlook.com

587

TLS

Live

live.com

smtp-mail.outlook.com

587

TLS

163 Mail

163.com

smtp.163.com

465

SSL

126 Mail

126.com

smtp.126.com

465

SSL

Sina Mail

sina.com

smtp.sina.com

465

SSL

Sohu Mail

sohu.com

smtp.sohu.com

465

SSL

189 Mail

189.cn

smtp.189.cn

465

SSL

Alibaba Cloud Mail

aliyun.com

smtp.aliyun.com

465

TLS

Yandex Mail

yandex.com

smtp.yandex.com

465

TLS

iCloud Mail

icloud.com

smtp.mail.me.com

587

SSL

Detección automática: Al usar los correos anteriores, no es necesario configurar manualmente EMAIL_SMTP_SERVER y EMAIL_SMTP_PORT, el sistema los detectará automáticamente.

Comentarios:

  • Si has probado con éxito otros proveedores de correo, no dudes en abrir un Issue para informarnos, y lo añadiré a la lista de soporte.

  • Si alguna de las configuraciones de correo anteriores es incorrecta o no funciona, también abre un Issue para informar y ayudar a mejorar el proyecto.

Agradecimientos especiales:

  • Gracias a @DYZYD por contribuir con la configuración de 189 Mail (189.cn) y completar la prueba de autoenvío y autorecepción (#291).

  • Gracias a @longzhenren por contribuir con la configuración de Alibaba Cloud Mail (aliyun.com) y completar las pruebas (#344).

  • Gracias a @ACANX por contribuir con la configuración de Yandex Mail (yandex.com) y completar las pruebas (#663).

  • Gracias a @Sleepy-Tianhao por contribuir con la configuración de iCloud Mail (icloud.com) y completar las pruebas (#728).

Configuración de correos comunes:

QQ Mail:

  1. Inicia sesión en la versión web de QQ Mail → Configuración → Cuenta

  2. Activa el servicio POP3/SMTP

  3. Genera un código de autorización (16 caracteres alfabéticos)

  4. EMAIL_PASSWORD debe rellenarse con el código de autorización, no con la contraseña de QQ

Gmail:

  1. Activa la verificación en dos pasos

  2. Genera una contraseña específica de la aplicación

  3. EMAIL_PASSWORD debe rellenarse con la contraseña específica de la aplicación

163/126 Mail:

  1. Inicia sesión en la versión web → Configuración → POP3/SMTP/IMAP

  2. Activa el servicio SMTP

  3. Configura el código de autorización del cliente

  4. EMAIL_PASSWORD debe rellenarse con el código de autorización

Configuración avanzada: Si la detección automática falla, puedes configurar SMTP manualmente:

  • EMAIL_SMTP_SERVER: por ejemplo, smtp.gmail.com

  • EMAIL_SMTP_PORT: por ejemplo, 587 (TLS) o 465 (SSL)

Si hay varios destinatarios (ten en cuenta que deben separarse con comas en inglés):

Dos formas de uso:

Opción 1: Uso gratuito (recomendado para principiantes) 🆓

Características:

  • ✅ Sin necesidad de registrarse, uso inmediato

  • ✅ 250 mensajes al día (suficiente para el 90% de los usuarios)

  • ✅ El nombre del Topic actúa como "contraseña" (elige un nombre difícil de adivinar)

  • ⚠️ Los mensajes no están cifrados, no son adecuados para información sensible, pero sí para la información no sensible de este proyecto

Inicio rápido:

  1. Descarga la aplicación ntfy:

  2. Suscríbete a un tema (elige un nombre difícil de adivinar):

    建议格式:trendradar-{你的名字缩写}-{随机数字}
    
    不能使用中文
    
    ✅ 好例子:trendradar-zs-8492
    ❌ 坏例子:news、alerts(太容易被猜到)
  3. Configura los Secret de GitHub (⚠️ El nombre debe coincidir estrictamente):

    • Name (Nombre): NTFY_TOPIC (copia y pega este nombre, no lo escribas a mano)

    • Secret (Valor): rellena con el nombre del tema al que te suscribiste

    • Name (Nombre): NTFY_SERVER_URL (configuración opcional, copia y pega este nombre)

    • Secret (Valor): déjalo vacío (por defecto usa ntfy.sh)

    • Name (Nombre): NTFY_TOKEN (configuración opcional, copia y pega este nombre)

    • Secret (Valor): déjalo vacío

    Nota: ntfy requiere al menos 1 Secret obligatorio (NTFY_TOPIC), los dos últimos son configuración opcional

  4. Prueba:

    curl -d "测试消息" ntfy.sh/你的主题名称

Opción 2: Autoalojamiento (control total de la privacidad) 🔒

Apto para: usuarios con servidor, que buscan privacidad total y tienen habilidades técnicas

Ventajas:

  • ✅ Totalmente de código abierto (Apache 2.0 + GPLv2)

  • ✅ Control total de los datos

  • ✅ Sin restricciones

  • ✅ Coste cero

Despliegue con Docker en un clic:

docker run -d \
  --name ntfy \
  -p 80:80 \
  -v /var/cache/ntfy:/var/cache/ntfy \
  binwiederhier/ntfy \
  serve --cache-file /var/cache/ntfy/cache.db

Configura TrendRadar:

NTFY_SERVER_URL: https://ntfy.yourdomain.com
NTFY_TOPIC: trendradar-alerts  # 自托管可用简单名称
NTFY_TOKEN: tk_your_token  # 可选:启用访问控制

Suscríbete en la aplicación:

  • Haz clic en "Use another server"

  • Introduce la dirección de tu servidor

  • Introduce el nombre del tema

  • (Opcional) Introduce las credenciales de acceso


Preguntas frecuentes:

250 mensajes al día son suficientes para la mayoría de los usuarios. Si se rastrea cada 30 minutos, son unas 48 notificaciones al día, más que suficiente.

Si eliges un nombre aleatorio y suficientemente largo (como trendradar-zs-8492-news), la fuerza bruta es prácticamente imposible:

  • ntfy tiene límites de velocidad estrictos (1 solicitud por segundo)

  • 64 caracteres posibles (A-Z, a-z, 0-9, _, -)

  • Una cadena aleatoria de 10 caracteres tiene 64^10 posibilidades (se necesitarían años para descifrarla)


Recomendación:

Tipo de usuario

Opción recomendada

Motivo

Usuario normal

Opción 1 (gratuita)

Simple y rápida, suficiente

Usuario técnico

Opción 2 (autoalojamiento)

Control total, sin límites

Usuario de alto uso

Opción 3 (de pago)

Ve a la web oficial para más información

Enlaces relacionados:

Configuración de Secret de GitHub (⚠️ El nombre debe coincidir estrictamente):

  • Name (Nombre): BARK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (Valor): tu URL de notificación de Bark

Introducción a Bark:

Bark es una herramienta de notificaciones gratuita y de código abierto para iOS, caracterizada por ser simple, rápida y sin anuncios.

Formas de uso:

Opción 1: Usar el servidor oficial (recomendado para principiantes) 🆓

  1. Descarga la aplicación Bark:

  2. Obtén la URL de notificación:

    • Abre la aplicación Bark

    • Copia la URL de notificación que se muestra en la página de inicio (formato: https://api.day.app/your_device_key)

    • Configura la URL en BARK_URL de los Secret de GitHub

Opción 2: Servidor propio (control total de la privacidad) 🔒

Apto para: usuarios con servidor, que buscan privacidad total y tienen habilidades técnicas

Despliegue con Docker en un clic:

docker run -d \
  --name bark-server \
  -p 8080:8080 \
  finab/bark-server

Configura TrendRadar:

BARK_URL: http://your-server-ip:8080/your_device_key

Notas:

  • ✅ Bark usa APNs para las notificaciones, máximo 4KB por mensaje

  • ✅ Admite envío automático por lotes, sin preocuparse por mensajes demasiado largos

  • ✅ El formato de notificación es texto plano (elimina automáticamente la sintaxis de Markdown)

  • ⚠️ Solo compatible con la plataforma iOS

Enlaces relacionados:

Configuración de Secret de GitHub (⚠️ El nombre debe coincidir estrictamente):

  • Name (Nombre): SLACK_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (Valor): tu URL de Incoming Webhook de Slack

Introducción a Slack:

Slack es una herramienta de colaboración en equipo; Incoming Webhooks permite enviar mensajes a canales de Slack.

Pasos de configuración:

Paso 1: Crear una aplicación de Slack

  1. Visita la página de API de Slack:

  2. Elige el método de creación:

    • Haz clic en "From scratch" (crear desde cero)

  3. Rellena la información de la aplicación:

    • App Name: introduce el nombre de la aplicación (como TrendRadar o Monitoreo de noticias)

    • Workspace: selecciona tu espacio de trabajo en el menú desplegable

    • Haz clic en el botón "Create App"

Paso 2: Activar Incoming Webhooks

  1. Navega a Incoming Webhooks:

    • En el menú lateral, busca y haz clic en "Incoming Webhooks"

  2. Activa la función:

    • Busca el interruptor "Activate Incoming Webhooks"

    • Cambia el interruptor de OFF a ON

    • La página se actualizará automáticamente mostrando las nuevas opciones de configuración

Paso 3: Generar la URL del Webhook

  1. Añade un nuevo Webhook:

    • Desplázate hasta el final de la página

    • Haz clic en el botón "Add New Webhook to Workspace"

  2. Selecciona el canal de destino:

    • El sistema mostrará una página de autorización

    • Selecciona el canal que recibirá los mensajes en el menú desplegable (como #noticias)

    • ⚠️ Si quieres seleccionar un canal privado, primero debes unirte a ese canal

  3. Autoriza la aplicación:

    • Haz clic en el botón "Allow" para completar la autorización

    • El sistema te redirigirá automáticamente a la página de configuración

Paso 4: Copia y guarda la URL del Webhook

  1. Consulta la URL generada:

    • En el área "Webhook URLs for Your Workspace"

    • Verás la URL del Webhook recién generada

    • Formato: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

  2. Copia la URL:

    • Haz clic en el botón "Copy" a la derecha de la URL

    • O selecciona la URL manualmente y cópiala

  3. Configúrala en TrendRadar:

    • GitHub Actions: añade la URL a SLACK_WEBHOOK_URL en los Secret de GitHub

    • Prueba local: rellena el campo slack_webhook_url en config/config.yaml

    • Despliegue con Docker: añade la URL a la variable SLACK_WEBHOOK_URL en el archivo docker/.env


Notas:

  • ✅ Compatible con formato Markdown (se convierte automáticamente a mrkdwn de Slack)

  • ✅ Admite envío automático por lotes (4KB por lote)

  • ✅ Adecuado para colaboración en equipo, gestión centralizada de mensajes

  • ⚠️ La URL del Webhook contiene una clave secreta, nunca la hagas pública

Vista previa del formato del mensaje:

*[第 1/2 批次]*

📊 *热点词汇统计*

🔥 *[1/3] AI ChatGPT* : 2 条

  1. [百度热搜] 🆕 ChatGPT-5正式发布 *[1]* - 09时15分 (1次)

  2. [今日头条] AI芯片概念股暴涨 *[3]* - [08时30分 ~ 10时45分] (3次)

Enlaces relacionados:

Configuración de Secret de GitHub (⚠️ El nombre debe coincidir estrictamente):

  • Name (Nombre): GENERIC_WEBHOOK_URL (copia y pega este nombre, no lo escribas a mano)

  • Secret (Valor): tu URL de Webhook

  • Name (Nombre): GENERIC_WEBHOOK_TEMPLATE (configuración opcional, copia y pega este nombre)

  • Secret (Valor): cadena de plantilla JSON, compatible con los marcadores de posición {title} y {content}

Introducción al Webhook genérico:

El Webhook genérico admite cualquier plataforma que acepte solicitudes HTTP POST, incluyendo, entre otras:

  • Discord: envía a canales mediante Webhook

  • Matrix: envía mediante puente de Webhook

  • IFTTT: activa flujos de automatización

  • Servicios propios: cualquier servicio personalizado que admita Webhooks

Ejemplos de configuración:

Configuración de Discord

  1. Obtén la URL del Webhook:

    • Entra en la configuración del servidor de Discord → Integraciones → Webhooks

    • Crea un nuevo Webhook y copia la URL

  2. Configura la plantilla:

    {"content": "{content}"}
  3. Configuración de Secret de GitHub:

    • GENERIC_WEBHOOK_URL: URL del Webhook de Discord

    • GENERIC_WEBHOOK_TEMPLATE: {"content": "{content}"}

Plantilla personalizada

La plantilla admite dos marcadores de posición:

  • {title} - título del mensaje

  • {content} - contenido del mensaje

Ejemplo de plantilla:

# 默认格式(留空时使用)
{"title": "{title}", "content": "{content}"}

# Discord 格式
{"content": "{content}"}

# 自定义格式
{"text": "{content}", "username": "TrendRadar"}

Notas:

  • ✅ Compatible con formato Markdown (igual que el formato de WeCom)

  • ✅ Admite envío automático por lotes

  • ✅ Admite configuración de múltiples cuentas (separadas por ;)

  • ⚠️ La plantilla debe ser un JSON válido

  • ⚠️ Diferentes plataformas tienen diferentes requisitos de formato de mensaje, consulta la documentación de la plataforma de destino

3️⃣ Tercer paso: Prueba manual de las notificaciones de noticias

⚠️ Aviso:

  • Después de completar los pasos 1-2, ¡prueba inmediatamente! Después de una prueba exitosa, ajusta la configuración según sea necesario (paso 4)

  • Entra en tu propio proyecto, ¡no en este proyecto!

Cómo encontrar tu página de Actions:

  • Método 1: abre la página principal de tu proyecto fork, haz clic en la pestaña Actions en la parte superior

  • Método 2: accede directamente a https://github.com/TU_NOMBRE_DE_USUARIO/TrendRadar/actions

Ejemplo de comparación:

  • ❌ Proyecto del autor: https://github.com/sansan0/TrendRadar/actions

  • ✅ Tu proyecto: https://github.com/TU_NOMBRE_DE_USUARIO/TrendRadar/actions

Pasos de prueba:

  1. Entra en la página de Actions de tu proyecto

  2. Busca "Get Hot News" (debe ser exactamente ese texto), haz clic y luego haz clic en el botón "Run workflow" a la derecha para ejecutarlo

    • Si no ves ese texto, consulta #109 para resolverlo

  3. En unos 3 minutos, el mensaje se enviará a la plataforma que configuraste

⚠️ Aviso:

  • No hagas pruebas manuales con demasiada frecuencia para evitar activar los límites de GitHub Actions

  • Después de hacer clic en Run workflow, necesitas actualizar la página del navegador para ver el nuevo registro de ejecución

4️⃣ Cuarto paso: Explicación de la configuración (opcional)

La configuración predeterminada ya funciona correctamente. Si necesitas ajustes personalizados, basta con conocer los siguientes archivos:

Archivo

Función

config/config.yaml

Archivo de configuración principal: modo de notificación, ventana de tiempo, lista de plataformas, pesos de noticias, etc.

config/frequency_words.txt

Archivo de palabras clave: configura las palabras que te interesan para filtrar el contenido de las notificaciones

config/ai_analysis_prompt.txt

Plantilla de prompt de IA: personaliza el rol del analista de IA y las dimensiones de análisis

.github/workflows/crawler.yml

Frecuencia de ejecución: controla cada cuánto se ejecuta (⚠️ modificar con precaución)

👉 Tutorial de configuración detallado: Explicación de la configuración

5️⃣ Quinto paso: Almacenamiento en la nube remoto y configuración de registro

Cambio importante en v4.0.0: se introduce el mecanismo de "detección de actividad"; GitHub Actions requiere un registro periódico para mantener su funcionamiento.

  • Ciclo de funcionamiento: la validez es de 7 días; cuando la cuenta atrás termina, el servicio se suspende automáticamente.

  • Cómo renovar: activa manualmente el workflow "Check In" en la página de Actions para restablecer la validez de 7 días.

  • Ruta de operación: Actions → Check In → Run workflow

  • Filosofía de diseño:

    • Si olvidas registrarte durante 7 días, quizás estas noticias no son una necesidad para ti. Una pausa oportuna puede ayudarte a desconectarte del flujo de información y dar un respiro a tu mente.

    • GitHub Actions es un valioso recurso informático público. El mecanismo de registro busca evitar el desperdicio inútil de cómputo y garantizar que los recursos se asignen a usuarios realmente activos y que los necesitan. Gracias por tu comprensión y apoyo.


Sobre la configuración del almacenamiento en la nube remoto (elige según el método de despliegue):

  • Usuarios de GitHub Actions:

    • Situación actual: cada ejecución de Actions es un entorno completamente nuevo, no se guardan archivos. Si no configuras almacenamiento en la nube, el proyecto funcionará en modo ligero (sin notificaciones incrementales, sin seguimiento histórico).

    • Recomendación: configura almacenamiento en la nube remoto para una experiencia completa.

  • Usuarios de Docker / local:

    • Situación actual: los datos se guardan por defecto en el disco local.

    • Recomendación: el almacenamiento en la nube es opcional, puede servir como copia de seguridad remota.

⚠️ Requisito previo (importante):

Según las reglas de la plataforma Cloudflare, para activar R2 es necesario vincular un método de pago.

  • Propósito: solo para verificación de identidad (Verify Only), no genera cargos.

  • Pago: admite tarjetas de crédito de doble moneda o PayPal de China.

  • Uso: la cuota gratuita de R2 (10GB de almacenamiento/mes) es suficiente para el funcionamiento diario de este proyecto, sin preocuparse por pagos.


Configuración de Secret de GitHub (se deben añadir 4 elementos):

Name (Nombre)

Descripción del Secret (Valor)

S3_BUCKET_NAME

Nombre del bucket (como trendradar-data)

S3_ACCESS_KEY_ID

ID de clave de acceso (Access Key ID)

S3_SECRET_ACCESS_KEY

Clave de acceso (Secret Access Key)

S3_ENDPOINT_URL

Endpoint de la API S3 (para R2: https://<account-id>.r2.cloudflarestorage.com)

Configuración opcional:

Name (Nombre)

Descripción del Secret (Valor)

S3_REGION

Región (por defecto auto, algunos proveedores pueden requerir especificarla)

💡 Más opciones de configuración de almacenamiento: consulta ¿Dónde se guardan los datos?

Pasos detallados (obtención de credenciales):

  1. Entra en la vista general de R2:

    • Inicia sesión en Cloudflare Dashboard.

    • En la barra lateral izquierda, busca y haz clic en Almacenamiento de objetos R2.

  2. Crea un bucket:

    • Haz clic en Descripción general

    • Haz clic en Crear bucket (Create bucket) en la esquina superior derecha.

    • Introduce un nombre (por ejemplo, trendradar-data) y haz clic en Crear bucket.

  3. Crea un token de API:

    • Vuelve a la página de Descripción general.

    • En la esquina inferior derecha, haz clic en Account Details, busca y haz clic en Manage (Manage R2 API Tokens).

    • También verás S3 API: https://<account-id>.r2.cloudflarestorage.com (este es el S3_ENDPOINT_URL)

    • Haz clic en Crear token de API de cuenta.

    • ⚠️ Configuración clave:

      • Nombre del token: rellena lo que quieras (como github-action-write).

      • Permisos: selecciona Lectura y escritura de administrador.

      • Bucket específico: por seguridad, se recomienda seleccionar Solo para buckets específicos y elegir tu bucket (como trendradar-data).

    • Haz clic en Crear token de API e inmediatamente copia el Access Key ID y el Secret Access Key que se muestran (¡solo se muestran una vez!).

6️⃣ Sexto paso: Activar las notificaciones de análisis de IA

Esta es la función principal de v5.0.0; deja que la IA resuma y analice las noticias por ti. Se recomienda probarla.

Método de configuración: Añade en los Secret de GitHub (o .env / config.yaml):

  • AI_API_KEY: tu clave de API (compatible con DeepSeek, OpenAI, etc.)

  • AI_PROVIDER: nombre del proveedor (como deepseek, openai)

Eso es todo, sin necesidad de un despliegue complejo. En la próxima notificación verás el informe de análisis inteligente.

7️⃣ Séptimo paso: 🎉 ¡Despliegue exitoso!

¡Enhorabuena! Ahora puedes empezar a disfrutar del eficiente flujo de información que te ofrece TrendRadar.

💬 Únete a la comunidad: Bienvenido a seguir la cuenta oficial «硅基茶水间» y comparte tus experiencias de uso y trucos avanzados.

8️⃣ Octavo paso: Avanzado: elige tu asistente de IA

TrendRadar ofrece dos formas de usar la IA para satisfacer diferentes necesidades:

Característica

✨ Análisis y envío de IA

🧠 Análisis inteligente de IA

Modo

Recepción pasiva (informe diario)

Conversación activa (investigación profunda)

Escenario

"¿Qué noticias importantes hay hoy?"

"Analiza los cambios en la industria de la IA de la última semana"

Despliegue

Mínimo (solo rellenar la Key)

Avanzado (requiere ejecución local/Docker)

Cliente

Móvil

Ordenador

👉 Conclusión: Usa primero Análisis y envío de IA para cubrir las necesidades diarias; si eres analista de datos o necesitas un análisis profundo, prueba entonces Análisis inteligente de IA.

⚙️ Configuración detallada

📖 Recordatorio: Este capítulo proporciona instrucciones de configuración detalladas. Se recomienda completar primero la configuración básica de Inicio rápido y volver a consultar las opciones detalladas según sea necesario.

1. ¿Qué plataformas quiero ver?

Ubicación de configuración: sección platforms de config/config.yaml

Los datos de noticias de este proyecto provienen de newsnow. Puedes hacer clic en el sitio web, hacer clic en [Más], y ver si hay alguna plataforma que desees.

Para añadir plataformas específicas, puedes visitar el código fuente del proyecto y, según los nombres de archivo que contenga, modificar la configuración platforms en el archivo config/config.yaml:

platforms:
  enabled: true                       # 是否启用热榜平台抓取
  sources:
    - id: "toutiao"
      name: "今日头条"
    - id: "baidu"
      name: "百度热搜"
    - id: "wallstreetcn-hot"
      name: "华尔街见闻"
    # 添加更多平台...

💡 Atajo: Si no sabes leer el código fuente, puedes copiar el resumen de configuración de plataformas recopilado por otros usuarios.

⚠️ Nota: No es mejor cuantas más plataformas. Se recomienda elegir 10-15 plataformas principales. Demasiadas plataformas pueden provocar una sobrecarga de información y empeorar la experiencia de uso.

2. ¿Qué contenido me interesa?

En el archivo frequency_words.txt, dile al robot qué quieres ver y él lo vigilará por ti. Admite palabras normales, palabras obligatorias, palabras de filtro y otros modos de uso.

Tipo de sintaxis

Símbolo

Función

Ejemplo

Lógica de coincidencia

Palabra normal

Ninguno

Coincidencia básica

华为

Basta con que contenga cualquiera de ellas

Palabra obligatoria

+

Limitar el alcance

+手机

Debe contenerla obligatoriamente

Palabra de filtro

!

Excluir ruido

!广告

Si la contiene, se excluye directamente

Límite de cantidad

@

Controlar el número mostrado

@10

Mostrar como máximo 10 noticias (nuevo en v3.2.0)

Filtro global

[GLOBAL_FILTER]

Excluir globalmente contenido específico

Ver ejemplo a continuación

Filtrar en cualquier caso (nuevo en v3.5.0)

Expresión regular

/pattern/

Modo de coincidencia precisa

/\bai\b/

Usar coincidencia con expresiones regulares (nuevo en v4.7.0)

Nombre mostrado

=> 备注

Texto mostrado personalizado

/\bai\b/ => AI相关

Mostrar el nombre de la nota en el envío y en HTML (nuevo en v4.7.0)

2.1 Sintaxis básica

Ubicación de configuración: config/frequency_words.txt

1. Palabras clave normales - Coincidencia básica
华为
OPPO
苹果

Función: Se capturará la noticia si el titular contiene cualquiera de estas palabras.

2. Palabras obligatorias +palabra - Limitar el alcance
华为
OPPO
+手机

Función: Debe contener simultáneamente la palabra normal y la palabra obligatoria para ser capturada.

3. Palabras de filtro !palabra - Excluir ruido
苹果
华为
!水果
!价格

Función: Las noticias que contengan la palabra de filtro serán excluidas directamente, incluso si contienen la palabra clave.

4. Límite de cantidad @número - Controlar el número mostrado (nuevo en v3.2.0)
特斯拉
马斯克
@5

Función: Limitar el número máximo de noticias mostradas para ese grupo de palabras clave.

Prioridad de configuración: @número > configuración global > sin límite

5. Filtro global [GLOBAL_FILTER] - Excluir globalmente contenido específico (nuevo en v3.5.0)
[GLOBAL_FILTER]
广告
推广
营销
震惊
标题党

[WORD_GROUPS]
科技
AI

华为
鸿蒙
!车

Función: Filtrar noticias que contengan las palabras especificadas en cualquier caso, con la prioridad más alta.

Casos de uso:

  • Filtrar contenido de baja calidad: impactante, clickbait, revelaciones, etc.

  • Filtrar contenido de marketing: anuncios, promociones, patrocinios, etc.

  • Filtrar temas específicos: entretenimiento, chismes (según necesidad)

Prioridad de filtrado: Filtro global > filtro dentro del grupo (!) > coincidencia de grupo

Descripción de secciones:

  • [GLOBAL_FILTER]: Zona de filtro global. Las palabras incluidas se filtran en cualquier caso.

  • [WORD_GROUPS]: Zona de grupos de palabras. Mantiene la sintaxis existente (!, +, @).

  • Si no se usan marcadores de sección, todo se trata como grupos de palabras por defecto (compatibilidad hacia atrás).

Ejemplos de coincidencia:

[GLOBAL_FILTER]
广告

[WORD_GROUPS]
科技
AI
  • ❌ "Anuncio: lanzamiento del último producto tecnológico" ← Contiene la palabra de filtro global "anuncio", se rechaza directamente.

  • ✅ "Una empresa tecnológica lanza un nuevo producto de IA" ← No contiene palabras de filtro global, coincide con el grupo "tecnología".

  • ✅ "El avance de la IA genera atención" ← No contiene palabras de filtro global, coincide con "IA" dentro del grupo "tecnología".

Notas:

  • Las palabras de filtro global deben usarse con precaución para evitar un filtrado excesivo que provoque la pérdida de contenido valioso.

  • Se recomienda mantener las palabras de filtro global entre 5 y 15.

  • Para el filtrado de grupos específicos, se recomienda usar palabras de filtro dentro del grupo (prefijo !).

6. Expresiones regulares /pattern/ - Modo de coincidencia precisa (nuevo en v4.7.0)

Las palabras clave normales usan coincidencia de subcadenas, lo cual es muy conveniente en entornos chinos, pero puede producir coincidencias erróneas en entornos ingleses. Por ejemplo, ai coincidirá con ai dentro de training.

Usando la sintaxis de expresión regular /pattern/ se puede lograr una coincidencia precisa:

/(?<![a-z])ai(?![a-z])/
人工智能

Función: Usar expresiones regulares para la coincidencia, admite toda la sintaxis de expresiones regulares de Python.

Patrones de expresiones regulares comunes:

Necesidad

Escritura de expresión regular

Explicación

Límite de palabra en inglés

/\bword\b/

Coincide con palabras independientes, como /\bai\b/ que coincide con "AI" pero no con "training"

No letras antes/después

/(?<![a-z])ai(?![a-z])/

Límite más flexible, adecuado para escenarios mixtos chino-inglés

Coincidencia al inicio

/^breaking/

Solo coincide con titulares que empiezan con "breaking"

Coincidencia al final

/发布$/

Solo coincide con titulares que terminan con "发布"

Múltiples opciones

/苹果|华为|小米/

Coincide con cualquiera de ellas (nota el escape |)

Ejemplos de coincidencia:

# 配置
/(?<![a-z])ai(?![a-z])/
人工智能
  • ✅ "AI is the future" ← Coincide con "AI" independiente

  • ✅ "你好ai这里" ← Chino antes y después, coincide con "ai"

  • ✅ "人工智能发展迅速" ← Coincide con "人工智能"

  • ❌ "Resistance training is important" ← "ai" en "training" no coincide

  • ❌ "The maid cleaned the room" ← "ai" en "maid" no coincide

Uso combinado:

# 正则 + 普通词 + 过滤词
/\bai\b/
人工智能
机器学习
!广告

Notas:

  • Las expresiones regulares activan automáticamente la coincidencia sin distinción de mayúsculas/minúsculas (re.IGNORECASE).

  • Admite escritura de estilo JavaScript como /pattern/i (las flags se ignoran, ya que la insensibilidad a mayúsculas está activada por defecto).

  • La sintaxis de expresión regular no válida se tratará como palabra normal.

  • Las expresiones regulares se pueden usar para palabras normales, palabras obligatorias (+) y palabras de filtro (!).

💡 ¿No sabes escribir expresiones regulares? ¡Deja que la IA las genere por ti!

Si no estás familiarizado con las expresiones regulares, puedes pedir directamente a ChatGPT / Gemini / DeepSeek que las genere. Solo tienes que decirle a la IA:

Necesito una expresión regular de Python para coincidir con la palabra inglesa "ai", pero no con "ai" dentro de "training". Por favor, dame directamente la expresión regular, con el formato /pattern/, sin explicaciones adicionales.

La IA te dará un resultado similar a este: /(?<![a-zA-Z])ai(?![a-zA-Z])/

7. Nombre mostrado => 备注 - Texto mostrado personalizado (nuevo en v4.7.0)

Las expresiones regulares pueden no ser muy amigables al mostrarse en los mensajes de envío y en las páginas HTML. Usando la sintaxis => 备注 se puede establecer un nombre mostrado:

/(?<![a-zA-Z])ai(?![a-zA-Z])/ => AI 相关
人工智能

Función: Mostrar "AI 相关" en los mensajes de envío y en las páginas HTML en lugar de la compleja expresión regular.

Formato de sintaxis:

# 正则 + 显示名称
/pattern/ => 显示名称
/pattern/i => 显示名称    # 支持 flags 写法(flags 被忽略)
/pattern/=>显示名称       # => 两边空格可选

# 普通词 + 显示名称
deepseek => DeepSeek 动态

Ejemplos de coincidencia:

# 配置
/(?<![a-zA-Z])ai(?![a-zA-Z])/ => AI 相关
人工智能

Configuración original

Visualización en envío/HTML

/(?<![a-z])ai(?![a-z])/ + 人工智能

(?<![a-z])ai(?![a-z]) 人工智能

/(?<![a-z])ai(?![a-z])/ => AI 相关 + 人工智能

AI 相关

Notas:

  • El nombre mostrado solo necesita escribirse en la primera palabra del grupo.

  • Si varias palabras del grupo tienen nombre mostrado, se usa el primero.

  • Si no se establece un nombre mostrado, se concatenan automáticamente todas las palabras del grupo.


🔗 Función de grupos de palabras - La importancia de separar con líneas en blanco

Regla principal: Usa líneas en blanco para separar diferentes grupos de palabras. Cada grupo se cuenta de forma independiente.

Ejemplo de configuración:
iPhone
华为
OPPO
+发布

A股
上证
深证
+涨跌
!预测

世界杯
欧洲杯
亚洲杯
+比赛
Explicación de los grupos y efectos de coincidencia:

Grupo 1 - Nuevas categorías de teléfonos:

  • Palabras clave: iPhone, 华为, OPPO

  • Palabra obligatoria: 发布

  • Efecto: Debe contener el nombre de la marca de teléfono y, al mismo tiempo, contener "发布".

Ejemplos de coincidencia:

  • ✅ "iPhone 15 se lanza oficialmente y se anuncia el precio" ← Tiene "iPhone"+"发布"

  • ✅ "Transmisión en vivo del evento de lanzamiento de la serie 华为Mate60" ← Tiene "华为"+"发布"

  • ✅ "Confirmada la fecha de lanzamiento del OPPO Find X7" ← Tiene "OPPO"+"发布"

  • ❌ "Las ventas de iPhone alcanzan un nuevo máximo" ← Tiene "iPhone" pero le falta "发布"

Grupo 2 - Tipo de mercado bursátil:

  • Palabras clave: A股, 上证, 深证

  • Palabra obligatoria: 涨跌

  • Palabra de filtro: 预测

  • Efecto: Seguir la situación real de subidas y bajadas del mercado de valores, excluyendo contenido de predicciones.

Ejemplos de coincidencia:

  • ✅ "Análisis de la gran subida y bajada del A股 hoy" ← Tiene "A股"+"涨跌"

  • ✅ "El índice 上证 alcanza un nuevo máximo de subida/bajada" ← Tiene "上证"+"涨跌"

  • ❌ "Expertos predicen la tendencia de subida y bajada del A股" ← Tiene "A股"+"涨跌" pero contiene "预测"

Grupo 3 - Tipo de eventos de fútbol:

  • Palabras clave: 世界杯, 欧洲杯, 亚洲杯

  • Palabra obligatoria: 比赛

  • Efecto: Solo seguir noticias relacionadas con partidos.


📝 Consejos de configuración

1. De amplio a estricto
# 第一步:先用宽泛关键词测试
人工智能
AI
ChatGPT

# 第二步:发现误匹配后,加入必须词限定
人工智能
AI
ChatGPT
+技术

# 第三步:发现干扰内容后,加入过滤词
人工智能
AI
ChatGPT
+技术
!广告
!培训
2. Evitar la complejidad excesiva

❌ No recomendado: Un grupo con demasiadas palabras

华为
OPPO
苹果
三星
vivo
一加
魅族
+手机
+发布
+销量
!假货
!维修
!二手

✅ Recomendado: Dividir en varios grupos precisos

华为
OPPO
+新品

苹果
三星
+发布

手机
销量
+市场

2.2 Configuración avanzada (nuevo en v3.2.0)

Prioridad de ordenación de palabras clave

Ubicación de configuración: config/config.yaml

report:
  sort_by_position_first: false  # 排序优先级配置

Valor de configuración

Regla de ordenación

Escenario de aplicación

false (por defecto)

Nº de puntos calientes ↓ → Posición de configuración ↑

Seguir la tendencia de popularidad

true

Posición de configuración ↑ → Nº de puntos calientes ↓

Seguir la prioridad personal

Ejemplo: Orden de configuración A, B, C. Nº de puntos calientes: A(3 noticias), B(10 noticias), C(5 noticias).

  • false: B(10 noticias) → C(5 noticias) → A(3 noticias)

  • true: A(3 noticias) → B(10 noticias) → C(5 noticias)

Límite global de cantidad mostrada
report:
  max_news_per_keyword: 10  # 每个关键词最多显示10条(0=不限制)

Variables de entorno de Docker:

SORT_BY_POSITION_FIRST=true
MAX_NEWS_PER_KEYWORD=10

Ejemplo completo:

# config.yaml
report:
  sort_by_position_first: true   # 按配置顺序优先
  max_news_per_keyword: 10       # 全局默认每个关键词最多10条
# frequency_words.txt
特斯拉
马斯克
@20              # 重点关注,显示20条(覆盖全局配置)

华为            # 使用全局配置,显示10条

比亚迪
@5               # 限制5条

Efecto final: Se muestra según el orden de configuración: 特斯拉(20 noticias) → 华为(10 noticias) → 比亚迪(5 noticias)

3. ¿Qué modo de envío elegir?

Ubicación de configuración: report.mode en config/config.yaml

report:
  mode: "daily"  # 可选: "daily" | "incremental" | "current"

Tabla de comparación detallada

Modo

Público objetivo

Momento del envío

Contenido mostrado

Caso de uso típico

Resumen del díadaily

📋 Directivos de empresa/Usuarios normales

Envío programado (por defecto, una vez por hora)

Todas las noticias coincidentes del día+ Zona de noticias nuevas

Caso: Ver todas las noticias importantes de hoy a las 6 de la tardeCaracterística: Ver la tendencia completa del día, sin perder ningún punto calienteRecordatorio: Incluirá noticias ya enviadas anteriormente

Ranking actualcurrent

📰 Autónomos de medios/Creadores de contenido

Envío programado (por defecto, una vez por hora)

Noticias coincidentes del ranking actual+ Zona de noticias nuevas

Caso: Seguimiento horario de "qué temas están más de moda ahora"Característica: Conocer en tiempo real los cambios en el ranking de popularidadRecordatorio: Las noticias que permanecen en el ranking aparecerán cada vez

Monitoreo incrementalincremental

📈 Inversores/Operadores

Envío solo cuando hay novedades

Noticias nuevas que coinciden con las palabras de frecuencia

Caso: Monitorear "特斯拉", solo notificar cuando haya nuevos mensajesCaracterística: Cero repeticiones, solo ver noticias que aparecen por primera vezAdecuado para: Monitoreo de alta frecuencia, evitar interrupciones de información

Ejemplo del efecto real del envío

Supongamos que monitoreas la palabra clave "苹果" y se ejecuta cada hora:

Hora

Envío modo daily

Envío modo current

Envío modo incremental

10:00

Noticia A, Noticia B

Noticia A, Noticia B

Noticia A, Noticia B

11:00

Noticia A, Noticia B, Noticia C

Noticia B, Noticia C, Noticia D

Solo Noticia C

12:00

Noticia A, Noticia B, Noticia C

Noticia C, Noticia D, Noticia E

Solo Noticia D, Noticia E

Explicación:

  • daily: Acumula y muestra todas las noticias del día (A, B, C se conservan).

  • current: Muestra las noticias del ranking actual (cambios de ranking, la noticia D entra en el ranking, la noticia A sale del ranking).

  • incremental: Solo envía las noticias nuevas que aparecen (evita interferencias repetidas).

Preguntas frecuentes

💡 ¿Tienes este problema? 👉 "Se ejecuta cada hora, y las noticias que se emitieron en la primera ejecución vuelven a aparecer en la siguiente ejecución horaria"

  • Causa: Probablemente elegiste el modo daily (resumen del día) o current (ranking actual).

  • Solución: Cambia al modo incremental (monitoreo incremental), que solo envía contenido nuevo.

⚠️ Aviso importante sobre el modo incremental

Atención a los usuarios que eligen el modo incremental (monitoreo incremental):

📌 El modo incremental solo envía cuando hay noticias nuevas que coinciden

Si no recibes envíos durante mucho tiempo, puede deberse a:

  1. No hay nuevos puntos calientes que coincidan con tus palabras clave en ese período.

  2. La configuración de palabras clave es demasiado estricta o demasiado amplia.

  3. El número de plataformas monitoreadas es reducido.

Soluciones:

4. Ajustar el algoritmo de puntos calientes

Ubicación de configuración: sección advanced.weight de config/config.yaml

advanced:
  weight:
    rank: 0.6           # 排名权重
    frequency: 0.3      # 频次权重
    hotness: 0.1        # 热度权重

La configuración predeterminada actual es una configuración equilibrada.

Dos escenarios principales

Tipo de seguimiento de puntos calientes en tiempo real:

advanced:
  weight:
    rank: 0.8           # 主要看排名
    frequency: 0.1      # 不太在乎持续性
    hotness: 0.1

Público objetivo: Blogueros de medios propios, personal de marketing, usuarios que quieren conocer rápidamente los temas más populares del momento.

Tipo de seguimiento de temas profundos:

advanced:
  weight:
    rank: 0.4           # 适度看排名
    frequency: 0.5      # 重视当天内的持续热度
    hotness: 0.1

Público objetivo: Inversores, investigadores, periodistas, usuarios que necesitan un análisis profundo de tendencias.

Método de ajuste

  1. Los tres números deben sumar 1.0

  2. Aumenta el que sea más importante: Si te importa el ranking, aumenta rank; si te importa la persistencia, aumenta frequency.

  3. Se recomienda ajustar solo 0.1-0.2 cada vez y observar el efecto.

Idea principal: Los usuarios que buscan velocidad y actualidad aumentan el peso del ranking; los que buscan profundidad y estabilidad aumentan el peso de la frecuencia.

5. ¿Cómo se ven los mensajes que recibo?

Ejemplo de envío

📊 Estadísticas de palabras clave de puntos calientes

🔥 [1/3] AI ChatGPT : 2 noticias

  1. [百度热搜] 🆕 ChatGPT-5 se lanza oficialmente [1] - 09时15分 (1 vez)

  2. [今日头条] Las acciones del concepto de chips de IA se disparan [3] - [08时30分 ~ 10时45分] (3 veces)

━━━━━━━━━━━━━━━━━━━

📈 [2/3] 比亚迪 特斯拉 : 2 noticias

  1. [微博] 🆕 比亚迪 bate el récord de ventas mensuales [2] - 10时20分 (1 vez)

  2. [抖音] 特斯拉 baja precios en promoción [4] - [07时45分 ~ 09时15分] (2 veces)

━━━━━━━━━━━━━━━━━━━

📌 [3/3] A股 股市 : 1 noticia

  1. [华尔街见闻] Análisis y comentario del mercado de mediodía del A股 [5] - [11时30分 ~ 12时00分] (2 veces)

🆕 Noticias de puntos calientes nuevas en esta ronda (2 en total)

百度热搜 (1 noticia):

  1. ChatGPT-5 se lanza oficialmente [1]

微博 (1 noticia):

  1. 比亚迪 bate el récord de ventas mensuales [2]

Hora de actualización: 2025-01-15 12:30:15

Explicación del formato de los mensajes

Elemento de formato

Ejemplo

Significado

Explicación

🔥📈📌

🔥 [1/3] AI ChatGPT

Nivel de popularidad

🔥 Alta popularidad (≥10 noticias) 📈 Popularidad media (5-9 noticias) 📌 Popularidad normal (<5 noticias)

[Nº de orden/Total]

[1/3]

Posición de ordenación

Posición del grupo de palabras actual entre todos los grupos coincidentes

Grupo de palabras de frecuencia

AI ChatGPT

Grupo de palabras clave

Grupo del archivo de configuración, el titular debe contener alguna de sus palabras

: N noticias

: 2 noticias

Número de coincidencias

Número total de noticias coincidentes para ese grupo

[Nombre de plataforma]

[百度热搜]

Plataforma de origen

Nombre de la plataforma a la que pertenece la noticia

🆕

🆕 ChatGPT-5 se lanza oficialmente

Marcador de novedad

Punto caliente que aparece por primera vez en esta ronda de captura

[Número]

[1]

Ranking alto

Puntos calientes con ranking ≤ umbral, mostrados en rojo y negrita

[Número]

[7]

Ranking normal

Puntos calientes con ranking > umbral, mostrados normalmente

- Hora

- 09时15分

Primera hora

Hora en que se descubrió la noticia por primera vez

[Hora~Hora]

[08时30分 ~ 10时45分]

Duración

Rango de tiempo desde la primera aparición hasta la última

(N veces)

(3 veces)

Frecuencia de aparición

Número total de veces que aparece durante el período de monitoreo

Zona de novedades

🆕 Noticias de puntos calientes nuevas en esta ronda

Resumen de nuevos temas

Muestra por separado los temas de puntos calientes nuevos en esta ronda

6. Despliegue con Docker

Explicación de las imágenes:

TrendRadar ofrece dos imágenes Docker independientes, puedes elegir el despliegue según tus necesidades:

Nombre de la imagen

Uso

Explicación

wantcat/trendradar

Servicio de envío de noticias

Captura programada de noticias, envío de notificaciones (obligatorio)

wantcat/trendradar-mcp

Servicio de análisis de IA

Soporte de protocolo MCP, análisis conversacional de IA (opcional)

💡 Sugerencia:

  • Solo necesitas la función de envío: despliega únicamente la imagen wantcat/trendradar.

  • Necesitas la función de análisis de IA: despliega ambas imágenes.

Método 1: Usar docker compose (recomendado)

  1. Crear el directorio del proyecto y la configuración:

    # 克隆项目到本地
    git clone https://github.com/sansan0/TrendRadar.git
    cd TrendRadar

    💡 Explicación: La estructura de directorios clave necesaria para el despliegue con Docker es la siguiente:

当前目录/
├── config/
│   ├── config.yaml                 # 核心功能配置(必需)
│   ├── frequency_words.txt         # 关键词配置(必需)
│   ├── timeline.yaml               # 时间线配置
│   ├── ai_analysis_prompt.txt      # AI 分析提示词(可选)
│   ├── ai_translation_prompt.txt   # AI 翻译提示词(可选)
│   ├── ai_interests.txt            # AI 兴趣过滤配置(可选)
│   ├── ai_filter/                  # AI 过滤相关提示词
│   │   ├── prompt.txt
│   │   ├── extract_prompt.txt
│   │   └── update_tags_prompt.txt
│   └── custom/                     # 用户自定义配置(可选)
│       ├── ai/                     # 自定义 AI 提示词
│       └── keyword/                # 自定义关键词文件
└── docker/
    ├── .env                        # 敏感信息 + Docker 特有配置
    └── docker-compose.yml          # Docker Compose 编排文件
  1. Descripción de los archivos de configuración:

    Principio de división de configuración (optimización v4.6.0):

    Archivo

    Uso

    Frecuencia de modificación

    Descripción

    config/config.yaml

    Configuración de funciones principales

    Baja

    Control del comportamiento global: modo de informe, configuración de envío, formato de almacenamiento, ventana de envío, interruptor de análisis de IA, activación de plataformas, etc.

    config/frequency_words.txt

    Configuración de palabras clave

    Alta

    Define los términos de interés que te importan; admite sintaxis avanzada como grupos, expresiones regulares y alias.

    config/timeline.yaml

    Configuración de la línea de tiempo

    Baja

    Controla la visualización y las reglas de filtrado de la línea de tiempo de noticias.

    config/ai_analysis_prompt.txt

    Prompt de análisis de IA

    Media

    Personaliza la definición del rol y el formato de salida del análisis de IA (v5.0.0+).

    config/ai_translation_prompt.txt

    Prompt de traducción de IA

    Baja

    Personaliza la plantilla del prompt de traducción de IA.

    config/ai_interests.txt

    Filtrado de intereses de IA

    Media

    Define las reglas para que la IA filtre automáticamente las noticias según tus intereses.

    config/ai_filter/

    Prompts de filtrado de IA

    Baja

    Prompts internos del módulo de filtrado de IA (normalmente no requieren modificación).

    config/custom/

    Extensiones personalizadas del usuario

    Según necesidad

    custom/ai/ para prompts de IA personalizados, custom/keyword/ para archivos de palabras clave personalizados.

    docker/.env

    Información sensible + configuración específica de Docker

    Baja

    URLs de webhook, claves de API, claves S3, tareas programadas, etc. No es rastreado por git.

    💡 Puntos clave de la división:

    • Comportamiento de funciones → modifica config.yaml (por ejemplo, activar/desactivar una plataforma, ajustar el modo de envío).

    • Contenido de interés → modifica frequency_words.txt (por ejemplo, añadir nuevas palabras clave de interés).

    • Estilo de salida de IA → modifica ai_analysis_prompt.txt o ai_translation_prompt.txt.

    • Claves y credenciales → modifica docker/.env (claves de API, URLs de Webhook y otra información sensible se centralizan aquí).

    • Extensiones personalizadas → usa el directorio config/custom/ para evitar que las actualizaciones sobrescriban la configuración predeterminada.

    💡 Aplicación de los cambios de configuración: después de modificar config.yaml, ejecuta docker compose up -d para reiniciar el contenedor y aplicar los cambios.

    ⚙️ Mecanismo de anulación por variables de entorno (v3.0.5+)

    Las variables de entorno del archivo .env anulan la configuración correspondiente en config.yaml:

    Variable de entorno

    Configuración correspondiente

    Ejemplo de valor

    Descripción

    WEBSERVER_PORT

    -

    8080

    Puerto del servidor web.

    FEISHU_WEBHOOK_URL

    notification.channels.feishu.webhook_url

    https://...

    Webhook de Feishu (para varias cuentas, separar con ;).

    AI_ANALYSIS_ENABLED

    ai_analysis.enabled

    true / false

    Si se habilita el análisis de IA (nuevo en v5.0.0).

    AI_API_KEY

    ai.api_key

    sk-xxx...

    Clave de API de IA (compartida por ai_analysis y ai_translation).

    AI_PROVIDER

    ai.provider

    deepseek / openai / gemini

    Proveedor de IA.

    S3_*

    storage.remote.*

    -

    Configuración de almacenamiento remoto (5 parámetros).

    Prioridad de configuración: variables de entorno > config.yaml

    Cómo usarlo:

    • Modifica el archivo .env y completa la configuración necesaria.

    • O añade las variables directamente en la sección "Variables de entorno" de la interfaz de administración de Docker en NAS/Synology.

    • Reinicia el contenedor para aplicar los cambios: docker compose up -d.

  2. Iniciar el servicio:

    Opción A: Iniciar todos los servicios (envío + análisis de IA)

    # 拉取最新镜像
    docker compose pull
    
    # 启动所有服务(trendradar + trendradar-mcp)
    docker compose up -d

    Opción B: Iniciar solo el servicio de envío de noticias

    # 只启动 trendradar(定时抓取和推送)
    docker compose pull trendradar
    docker compose up -d trendradar

    Opción C: Iniciar solo el servicio MCP de análisis de IA

    # 只启动 trendradar-mcp(提供 AI 分析接口)
    docker compose pull trendradar-mcp
    docker compose up -d trendradar-mcp

    💡 Nota:

    • La mayoría de los usuarios solo necesitan iniciar trendradar para usar la función de envío de noticias.

    • Solo necesitas iniciar trendradar-mcp si quieres usar ChatGPT/Gemini para el análisis conversacional de IA.

    • Los dos servicios son independientes entre sí y se pueden combinar según tus necesidades.

  3. Ver el estado de ejecución:

    # 查看新闻推送服务日志
    docker logs -f trendradar
    
    # 查看 MCP AI 分析服务日志
    docker logs -f trendradar-mcp
    
    # 查看所有容器状态
    docker ps | grep trendradar
    
    # 停止特定服务
    docker compose stop trendradar      # 停止推送服务
    docker compose stop trendradar-mcp  # 停止 MCP 服务

Método 2: Compilación local (opción para desarrolladores)

Si necesitas personalizar el código o compilar tu propia imagen:

# 克隆项目
git clone https://github.com/sansan0/TrendRadar.git
cd TrendRadar

# 修改配置文件
vim config/config.yaml
vim config/frequency_words.txt

# 使用构建版本的 docker compose
cd docker
cp docker-compose-build.yml docker-compose.yml

Compilar e iniciar el servicio:

# 选项 A:构建并启动所有服务
docker compose build
docker compose up -d

# 选项 B:仅构建并启动新闻推送服务
docker compose build trendradar
docker compose up -d trendradar

# 选项 C:仅构建并启动 MCP AI 分析服务
docker compose build trendradar-mcp
docker compose up -d trendradar-mcp

💡 Nota sobre los parámetros de arquitectura:

  • Por defecto se compila la imagen de arquitectura amd64 (adecuada para la mayoría de los servidores x86_64).

  • Para compilar la arquitectura arm64 (Apple Silicon, Raspberry Pi, etc.), configura la variable de entorno:

    export DOCKER_ARCH=arm64
    docker compose build

Actualización de imágenes

# 方式一:手动更新(爬虫 + MCP 镜像)
docker pull wantcat/trendradar:latest
docker pull wantcat/trendradar-mcp:latest
docker compose down
docker compose up -d

# 方式二:使用 docker compose 更新
docker compose pull
docker compose up -d

Imágenes disponibles:

Nombre de la imagen

Uso

Descripción

wantcat/trendradar

Servicio de envío de noticias

Rastreo programado de noticias, envío de notificaciones.

wantcat/trendradar-mcp

Servicio MCP

Función de análisis de IA (opcional).

Comandos de gestión del servicio

# 查看运行状态
docker exec -it trendradar python manage.py status

# 手动执行一次爬虫
docker exec -it trendradar python manage.py run

# 查看实时日志
docker exec -it trendradar python manage.py logs

# 显示当前配置
docker exec -it trendradar python manage.py config

# 显示输出文件
docker exec -it trendradar python manage.py files

# Web 服务器管理(用于浏览器访问生成的报告)
docker exec -it trendradar python manage.py start_webserver   # 启动 Web 服务器
docker exec -it trendradar python manage.py stop_webserver    # 停止 Web 服务器
docker exec -it trendradar python manage.py webserver_status  # 查看 Web 服务器状态

# 查看帮助信息
docker exec -it trendradar python manage.py help

# 重启容器
docker restart trendradar

# 停止容器
docker stop trendradar

# 删除容器(保留数据)
docker rm trendradar

💡 Nota sobre el servidor web:

  • Se inicia automáticamente en modo cron; accede a http://localhost:8080 desde el navegador para ver el último informe.

  • Navega por los informes históricos mediante el directorio (por ejemplo, http://localhost:8080/2025-xx-xx/).

  • El puerto se puede configurar con el parámetro WEBSERVER_PORT en el archivo .env.

  • Detención manual: docker exec -it trendradar python manage.py stop_webserver.

  • Inicio manual: docker exec -it trendradar python manage.py start_webserver.

  • Aviso de seguridad: solo proporciona acceso a archivos estáticos, restringido al directorio output y vinculado solo al acceso local.

Persistencia de datos

Los informes y datos generados se guardan por defecto en el directorio ./output. Los datos se conservan incluso si el contenedor se reinicia o se elimina.

📊 Rutas de acceso al informe web:

El informe HTML resumido del día generado por TrendRadar se guarda en dos ubicaciones:

Ubicación del archivo

Método de acceso

Escenario de uso

output/index.html

Acceso directo desde el host

Implementación con Docker (visible en el host mediante el montaje de volumen).

index.html

Acceso desde la raíz

GitHub Pages (raíz del repositorio, Pages lo detecta automáticamente).

output/html/YYYY-MM-DD/当日汇总.html

Acceso a informes históricos

Todos los entornos (archivado por fecha).

Ejemplo de acceso local:

# 方式 1:通过 Web 服务器访问(推荐,Docker 环境)
# 1. 启动 Web 服务器
docker exec -it trendradar python manage.py start_webserver
# 2. 在浏览器访问
http://localhost:8080                           # 访问最新报告(默认 index.html)
http://localhost:8080/html/2025-xx-xx/          # 访问指定日期的报告

# 方式 2:直接打开文件(本地环境)
open ./output/index.html             # macOS
start ./output/index.html            # Windows
xdg-open ./output/index.html         # Linux

# 方式 3:访问历史归档
open ./output/html/2025-xx-xx/当日汇总.html

¿Por qué hay dos archivos index.html?

  • output/index.html: se monta en el host mediante el volumen de Docker, se puede abrir directamente de forma local.

  • index.html: se envía al repositorio mediante GitHub Actions y GitHub Pages lo despliega automáticamente.

💡 Nota: el contenido de ambos archivos es idéntico; puedes acceder a cualquiera de ellos.

Solución de problemas

# 检查容器状态
docker inspect trendradar

# 查看容器日志
docker logs --tail 100 trendradar

# 进入容器调试
docker exec -it trendradar /bin/bash

# 验证配置文件
docker exec -it trendradar ls -la /app/config/

Despliegue del servicio MCP (función de análisis de IA)

Si necesitas usar la función de análisis de IA, puedes desplegar un contenedor de servicio MCP independiente.

Descripción de la arquitectura:

flowchart TB
    subgraph trendradar["trendradar"]
        A1[定时抓取新闻]
        A2[推送通知]
    end
    
    subgraph trendradar-mcp["trendradar-mcp"]
        B1[127.0.0.1:3333]
        B2[AI 分析接口]
    end
    
    subgraph shared["共享卷"]
        C1["config/ (ro)"]
        C2["output/ (ro)"]
    end
    
    trendradar --> shared
    trendradar-mcp --> shared

Inicio rápido:

Si ya has completado el despliegue siguiendo la Opción 1: usar docker compose, solo necesitas iniciar el servicio MCP:

cd TrendRadar/docker
docker compose up -d trendradar-mcp

# 查看运行状态
docker ps | grep trendradar-mcp

Iniciar el servicio MCP por separado (sin usar docker compose):

# Linux/Mac
docker run -d --name trendradar-mcp \
  -p 127.0.0.1:3333:3333 \
  -v $(pwd)/config:/app/config:ro \
  -v $(pwd)/output:/app/output:ro \
  -e TZ=Asia/Shanghai \
  wantcat/trendradar-mcp:latest

# Windows PowerShell
docker run -d --name trendradar-mcp `
  -p 127.0.0.1:3333:3333 `
  -v ${PWD}/config:/app/config:ro `
  -v ${PWD}/output:/app/output:ro `
  -e TZ=Asia/Shanghai `
  wantcat/trendradar-mcp:latest

⚠️ Aviso: al ejecutarlo por separado, asegúrate de que en el directorio actual existan las carpetas config/ y output/, y que contengan los archivos de configuración y los datos de noticias.

Verificar el servicio:

# 检查 MCP 服务健康状态
curl http://127.0.0.1:3333/mcp

# 查看 MCP 服务日志
docker logs -f trendradar-mcp

Configurar en el cliente de IA:

Una vez iniciado el servicio MCP, configúralo según el cliente que uses:

Cherry Studio (recomendado, configuración con GUI):

  • Ajustes → Servidores MCP → Añadir

  • Tipo: streamableHttp

  • URL: http://127.0.0.1:3333/mcp

Claude Desktop / Cline (configuración JSON):

{
  "mcpServers": {
    "trendradar": {
      "url": "http://127.0.0.1:3333/mcp",
      "type": "streamableHttp"
    }
  }
}

💡 Nota: el servicio MCP solo escucha en el puerto local (127.0.0.1) para garantizar la seguridad. Si necesitas acceso remoto, configura tú mismo un proxy inverso y la autenticación.

7. ¿Cómo se muestra el contenido enviado?

Ubicación de la configuración: sección report y display de config/config.yaml

report:
  mode: "daily"                    # 推送模式
  display_mode: "keyword"          # 显示模式(v4.6.0 新增)
  rank_threshold: 5                # 排名高亮阈值
  sort_by_position_first: false    # 排序优先级
  max_news_per_keyword: 0          # 每个关键词最大显示数量

display:
  region_order:                    # 区域显示顺序(v5.2.0 新增)
    - new_items                    # 新增热点区域
    - hotlist                      # 热榜区域
    - rss                          # RSS 订阅区域
    - standalone                   # 独立展示区
    - ai_analysis                  # AI 分析区域

Explicación de los parámetros de configuración más comunes

Qué quiero ajustar

Qué parámetro modificar

Valor por defecto

Descripción

Modo de envío

mode

daily

Determina el momento y el contenido del envío; consulta Explicación detallada de los modos de envío.

Forma de agrupar

display_mode

keyword

keyword=agrupar por palabra clave (p. ej., "IA"), platform=agrupar por plataforma (p. ej., "Weibo").

Resaltar lo importante

rank_threshold

5

Las 5 noticias con mejor ranking se muestran en negrita para ver de un vistazo las más populares.

Regla de ordenación

sort_by_position_first

false

false=las más populares primero, true=las palabras que configuraste primero.

Límite de cantidad

max_news_per_keyword

0

¿Cuántas noticias como máximo por palabra clave? 0 significa sin límite.

Orden de visualización

display.region_order

Ver configuración anterior

Ajusta el orden de la lista para controlar la posición de cada sección.

Comparación de modos de agrupación (display_mode)

¿Quieres ver "qué noticias hay sobre este tema" o "qué noticias hay en esta plataforma"?

Modo

Forma de agrupar

Prefijo del título

Escenario de uso

keyword (predeterminado)

Agrupar por palabra clave

[Nombre de la plataforma]

Me interesa "IA", quiero ver las noticias sobre IA en todas las plataformas.

platform

Agrupar por plataforma

[Palabra clave]

Me interesa "Weibo", quiero ver las noticias sobre mis palabras de interés en Weibo.

Orden de visualización de las secciones (region_order)

Ajustando el orden de la lista display.region_order, puedes controlar la posición de cada sección en el mensaje de envío.

Orden predeterminado: Nuevos temas destacados → Ranking de tendencias → RSS → Sección de visualización independiente → Análisis de IA

Ejemplo personalizado: ¿Quieres que el análisis de IA aparezca primero?

display:
  region_order:
    - ai_analysis                  # 移到第一行
    - new_items
    - hotlist
    - rss
    - standalone

Nota: una sección solo se muestra si cumple dos condiciones:

  1. Está en la lista region_order.

  2. El interruptor correspondiente en display.regions está en true.

Interruptores de sección (regions)

Controla qué secciones se muestran en el envío mediante display.regions:

display:
  regions:
    hotlist: true                    # 热榜区域(关键词匹配的热点新闻)
    new_items: false                 # 新增热点区域(含热榜新增 + RSS 新增)
    rss: true                       # RSS 订阅区域(关键词匹配的 RSS 内容)
    standalone: false                # 独立展示区(完整热榜/RSS,不受关键词过滤)
    ai_analysis: true                # AI 分析区域

Sección

Clave de configuración

Valor por defecto

Descripción

Alertas de tendencias

hotlist

true

Agregación de noticias de tendencia que coinciden con las palabras clave.

Nuevos temas destacados

new_items

false

Temas de tendencia nuevos en esta ronda (incluye nuevos en la sección de tendencias + nuevos en RSS). Nota: el marcador 🆕 en la sección de tendencias no se ve afectado por este interruptor.

RSS

rss

true

Contenido de suscripción RSS que coincide con las palabras clave. Si se desactiva, se omite el análisis RSS, pero el RSS de la sección de visualización independiente no se ve afectado.

Sección de visualización independiente

standalone

false

Visualización completa del contenido de plataformas/RSS específicos, sin filtrado por palabras clave.

Análisis de IA

ai_analysis

true

Resumen de análisis de temas de tendencia generado por IA.

Prioridad de ordenación (sort_by_position_first)

Supongamos que configuraste las palabras clave: 1. Tesla, 2. BYD. Popularidad real: BYD (10 noticias), Tesla (3 noticias).

Valor de configuración

Resultado de la ordenación

Tu idea

false (predeterminado)

BYD (10 noticias) → Tesla (3 noticias)

"Quien sea más popular va primero".

true

Tesla (3 noticias) → BYD (10 noticias)

"El orden que configuré es la prioridad, sin importar si es popular o no".

Sección de visualización independiente (standalone)

Escenario: hay algunas plataformas (como la lista de tendencias de Zhihu, HackerNews) que quiero ver completas, sin importar si coinciden con mis palabras clave.

display:
  regions:
    standalone: true                  # 推送中展示独立展示区(关闭不影响 AI 分析)

  standalone:
    platforms: ["zhihu", "weibo"]     # 这些平台的热榜给我完整显示
    rss_feeds: ["hacker-news"]        # 这些RSS源的内容给我完整显示
    max_items: 20                     # 最多显示多少条

💡 Control independiente del envío y del análisis de IA: regions.standalone solo controla si la sección de visualización independiente se muestra en el envío. Incluso si desactivas la visualización en el envío, mientras en la configuración de IA tengas activado include_standalone: true, la IA seguirá analizando los datos completos de estas plataformas. Es adecuado para usuarios que quieren que la IA haga un análisis profundo, pero no quieren que los mensajes de envío sean demasiado largos.

8. ¿Cuándo me envía las notificaciones?

Ubicación de la configuración: sección schedule de config/config.yaml + config/timeline.yaml

Inicio rápido

Solo tienes que elegir una plantilla predefinida en config.yaml, no necesitas editar timeline.yaml:

schedule:
  enabled: true
  preset: "morning_evening"     # 改这里就行

Plantillas predefinidas disponibles

Nombre de la plantilla

Descripción

Comportamiento de envío

morning_evening

Incremento durante todo el día + resumen nocturno (recomendado)

Envía cuando haya novedades durante todo el día + resumen diario de 19:00-21:00.

always_on

Monitoreo 24/7

Envía cuando haya novedades durante todo el día, sin dividir en franjas horarias.

office_hours

Horario laboral

Tres franjas en días laborables (resumen al llegar → temas de mediodía → resumen al salir), envío libre de incrementos los fines de semana.

night_owl

Trasnochador

Resumen de la tarde + resumen completo de la noche (22:00-01:00, cruza la medianoche).

custom

Totalmente personalizado

Edita la sección custom al final de timeline.yaml.

Personalización total

Si ninguna plantilla predefinida se ajusta a tus necesidades, puedes editar la sección custom al final de config/timeline.yaml para definir libremente franjas horarias, planes diarios y mapeo semanal. Consulta los comentarios dentro del archivo timeline.yaml.

Avisos importantes

⚠️ Aviso para usuarios que actualizan desde versiones antiguas:

  • v6.0.0 eliminó las configuraciones antiguas notification.push_window y ai_analysis.analysis_window.

  • Usa el nuevo sistema de programación schedule + timeline.yaml.

  • El antiguo "enviar una vez al día" se puede sustituir con la plantilla morning_evening.

  • El antiguo "enviar en horario laboral" se puede sustituir con la plantilla office_hours.

⚠️ Aviso para usuarios de GitHub Actions:

  • El tiempo de ejecución de GitHub Actions no es estable, puede tener una desviación de ±15 minutos.

  • Se recomienda dejar al menos 2 horas de margen en los rangos horarios.

  • Si quieres un envío programado preciso, se recomienda usar Docker en un servidor personal.

9. ¿Cada cuánto se ejecuta?

Ubicación de la configuración: sección schedule de .github/workflows/crawler.yml

on:
  schedule:
    - cron: "0 * * * *"  # 每小时运行一次

¿Cómo modificar la frecuencia de ejecución?

GitHub Actions usa un formato de tiempo llamado "Cron". No necesitas entenderlo en profundidad; simplemente copia el código siguiente y reemplázalo.

Ubicación de la configuración: sección schedule del archivo .github/workflows/crawler.yml

Quiero...

Copia esta línea de código

Descripción

Cada hora

- cron: "0 * * * *"

Configuración predeterminada, se ejecuta en el minuto 0.

Cada 30 minutos

- cron: "*/30 * * * *"

Se ejecuta cada 30 minutos.

Todos los días a las 8 a. m.

- cron: "0 0 * * *"

⚠️ Escribe 0 porque la hora UTC (0:00) = hora de Beijing (8:00).

Cada media hora en horario laboral

- cron: "*/30 0-14 * * *"

Corresponde a las 8:00 - 22:00 hora de Beijing.

Tres comidas al día

- cron: "0 0,6,12 * * *"

Corresponde a las 8:00, 14:00, 20:00 hora de Beijing.

⚠️ Dos avisos importantes

  1. Diferencia horaria: los servidores de GitHub están en el extranjero y usan la hora UTC.

    • Cálculo simple: la hora de Beijing que quieres configurar menos 8 horas = la hora que debes poner.

    • Ejemplo: si quieres que se ejecute a las 20:00 hora de Beijing, en la configuración debes poner 12:00.

  2. No demasiado frecuente: se recomienda que el intervalo no sea inferior a 30 minutos.

    • Los recursos gratuitos de GitHub son limitados; ejecutarlo demasiado a menudo puede hacer que la cuenta sea limitada oficialmente.

    • Además, el inicio de Actions tiene un retraso de varios minutos, por lo que un control demasiado preciso no tiene sentido.

Pasos para modificarlo paso a paso

  1. En tu repositorio de GitHub, busca el archivo .github/workflows/crawler.yml.

  2. Haz clic en el botón ✏️ (Editar) en la esquina superior derecha.

  3. Busca la línea cron: "..." y reemplaza el contenido entre comillas con el "código" anterior.

  4. Haz clic en el botón verde Commit changes de la esquina superior derecha para guardar.

10. Enviar a varios grupos/dispositivos

⚠️ La seguridad es lo primero

¡No escribas contraseñas/Tokens directamente en config.yaml! Si subes un archivo con contraseñas a GitHub, todo el mundo podrá verlo.

Forma correcta:

  • Usuarios de GitHub Actions: añádelos en Settings -> Secrets.

  • Usuarios de Docker: escríbelos en el archivo .env (este archivo no se sube).

¿Cómo enviar a varios lugares a la vez?

Muy sencillo: separa las direcciones con un punto y coma ;.

Por ejemplo: Supongamos que tienes dos grupos de Feishu y quieres recibir el envío en ambos:

  • Dirección del grupo 1: https://.../webhook/aaa

  • Dirección del grupo 2: https://.../webhook/bbb

Al configurar, escribe: https://.../webhook/aaa;https://.../webhook/bbb

Plataformas que admiten varias cuentas

平台

配置方法

注意事项

飞书/钉钉/企微

用 ; 分隔多个 Webhook URL

最简单,直接串起来就行

Bark (iOS)

用 ; 分隔多个 Key URL

推送到多台 iPhone

Telegram

Token 和 ChatID 都要用 ; 分隔

⚠️ 注意顺序要对应:Token1 对应 ChatID1Token2 对应 ChatID2

ntfy

Topic 和 Token 都要用 ; 分隔

如果某个Topic不需要Token,留空即可:token1;;token3 (中间那个是空的)

常用配置示例 (GitHub Secrets / .env)

# 飞书发给 3 个群
FEISHU_WEBHOOK_URL=https://hook1...;https://hook2...;https://hook3...

# 钉钉发给 2 个群
DINGTALK_WEBHOOK_URL=https://oapi...;https://oapi...

# Telegram 发给 2 个人 (注意一一对应)
TELEGRAM_BOT_TOKEN=tokenA;tokenB
TELEGRAM_CHAT_ID=userA;userB

提示:为了防止滥用,默认限制每个平台最多推送到 3 个账号。如果需要更多,可以修改 MAX_ACCOUNTS_PER_CHANNEL 配置。

11. 数据保存在哪里?

数据会存在哪里?

系统会自动帮你选择最合适的地方,你通常不需要操心:

你的运行环境

数据存在哪

说明

Docker / 本地运行

本地硬盘

存在项目目录下的 output/ 文件夹里,随时可以查看。

GitHub Actions

云端存储

因为 GitHub Actions 运行完就会销毁环境,所以必须配置云存储(例如 Cloudflare R2)。

怎么配置云存储?(GitHub Actions 用户必看)

如果你是用 GitHub Actions 运行,你需要一个"云端硬盘"来存数据。例如使用 Cloudflare R2(因为有免费额度)。

在 GitHub Secrets 里添加这 5 个变量:

变量名

填什么

STORAGE_BACKEND

remote

S3_BUCKET_NAME

你的存储桶名字

S3_ACCESS_KEY_ID

你的 Access Key

S3_SECRET_ACCESS_KEY

你的 Secret Key

S3_ENDPOINT_URL

你的 R2 接口地址

💡 详细教程:怎么申请 R2?请看 快速开始 - 远程存储配置

数据会保存多久?

默认情况下,我们不会自动删除你的数据。但如果你觉得数据太多占空间,可以设置"自动清理"。

配置位置:config/config.yaml

storage:
  local:
    retention_days: 30    # 本地数据只保留 30 天 (0 表示永久)
  remote:
    retention_days: 30    # 云端数据只保留 30 天

推送时间不对?(时区设置)

如果你身在海外,或者发现推送时间跟你的本地时间对不上,可以修改时区。

配置位置:config/config.yaml

app:
  timezone: "Asia/Shanghai"  # 默认是中国时间
  • 比如你在美国洛杉矶,改成:America/Los_Angeles

  • 比如你在英国伦敦,改成:Europe/London

12. 让 AI 帮我分析热点

AI 能帮我做什么?

开启这个功能后,AI 会像一个专业的分析师,在推送每一批新闻时:

  1. 自动阅读:阅读所有匹配到的热点新闻

  2. 深度思考:分析原本孤立的新闻之间的关联

  3. 撰写报告:在推送消息的末尾,附上一份简短深刻的"洞察报告"

包含内容:热点趋势总结、舆论风向判断、跨平台关联分析、潜在影响评估等。

怎么开启 AI 分析?

最简单的方法是通过环境变量配置(推荐 GitHub Secrets 或 .env)。

必需的配置项:

变量名

填什么

说明

AI_ANALYSIS_ENABLED

true

开启开关

AI_API_KEY

sk-xxxxxx

你的 API Key

AI_MODEL

deepseek/deepseek-chat

模型标识(格式:provider/model)

支持的 AI 提供商(基于 LiteLLM,支持 100+ 提供商):

提供商

AI_MODEL 填什么

说明

DeepSeek (推荐)

deepseek/deepseek-chat

性价比极高,适合高频分析

OpenAI

openai/gpt-4oopenai/gpt-4o-mini

GPT-4o 系列

Google Gemini

gemini/gemini-1.5-flashgemini/gemini-1.5-pro

Gemini 系列

自定义 API

任意格式

配合 AI_API_BASE 使用

💡 新特性:现已基于 LiteLLM 统一接口,支持 100+ AI 提供商,配置更简单、错误处理更完善。

可选配置项:

变量名

默认值

说明

AI_API_BASE

(自动)

自定义 API 地址(如 OneAPI、本地模型)

AI_TEMPERATURE

1.0

采样温度(0-2,越高越随机)

AI_MAX_TOKENS

5000

最大生成 token 数

AI_TIMEOUT

120

请求超时时间(秒)

AI_NUM_RETRIES

2

失败重试次数

进阶玩法:AI 翻译

如果你关注了国外的 RSS 源(比如 Hacker News),AI 可以帮你把内容翻译成中文推送。

配置位置:config/config.yaml

ai_translation:
  enabled: true          # 开启翻译
  language: "Chinese"    # 翻译成什么语言 (Chinese, English, Japanese...)

进阶玩法:自定义 AI "人设"

觉得 AI 说话太官方?你可以修改它的提示词,让它变成你喜欢的风格(比如"毒舌评论员"、"资深投资顾问")。

  • 修改文件:config/ai_analysis_prompt.txt

  • 修改方法:直接用记事本打开编辑,告诉 AI 你想要什么样的分析风格。

✨ AI 智能分析

TrendRadar v3.0.0 新增了基于 MCP (Model Context Protocol) 的 AI 分析功能,让你可以通过自然语言与新闻数据对话,进行深度分析。

⚠️ 使用前必读

重要提示:AI 功能需要本地新闻数据支持

AI 分析功能不是直接查询网络实时数据,而是分析你本地已积累的新闻数据(存储在 output 文件夹中)

使用说明:

  1. 项目自带测试数据:output 目录默认包含 2025-12-21~2025-12-27 一周的热榜新闻数据,可用于快速体验 AI 功能

  2. 查询限制:

    • ✅ 只能查询已有日期范围内的数据(12月21-27日,共7天)

    • ❌ 无法查询实时新闻或未来日期

  3. 获取最新数据:

    • 测试数据仅供快速体验,建议自行部署项目获取实时数据

    • 按照 快速开始 部署运行项目

    • 等待至少 1 天积累新闻数据后,即可查询最新热点

1. 快速部署

Cherry Studio 提供 GUI 配置界面,5 分钟快速部署,复杂的部分是一键安装的。

图文部署教程:现已更新到我的公众号,回复 "mcp" 即可

详细部署教程:README-Cherry-Studio.md

部署模式说明:

  • STDIO 模式(推荐):一次配置后续无需重复配置,图文部署教程中仅以此模式的配置为例。

  • HTTP 模式(备选):如果 STDIO 模式配置遇到问题,可使用 HTTP 模式。此模式的配置方式与 STDIO 基本一致,但复制粘贴的内容就一行,不易出错。唯一需要注意的是每次使用前都需要手动启动一下服务。详细请参考 README-Cherry-Studio.md 底部的 HTTP 模式说明。

2. 学习与 AI 对话的姿势

详细对话教程:README-MCP-FAQ.md

💡 提示:实际不建议一次性问多个问题。如果你选择的 AI 模型连下图的按顺序调用都无法做到,建议换一个。

🔌 MCP 客户端

TrendRadar MCP 服务支持标准的 Model Context Protocol (MCP) 协议,可以接入各种支持 MCP 的 AI 客户端进行智能分析。

支持的客户端

注意事项:

  • 将 /path/to/TrendRadar 替换为你的项目实际路径

  • Windows 路径使用双反斜杠:C:\\Users\\YourName\\TrendRadar

  • 保存后记得重启

方式一:HTTP 模式

  1. 启动 HTTP 服务:

    # Windows
    start-http.bat
    
    # Mac/Linux
    ./start-http.sh
  2. 配置 Cursor:

    项目级配置(推荐): 在项目根目录创建 .cursor/mcp.json:

    {
      "mcpServers": {
        "trendradar": {
          "url": "http://localhost:3333/mcp",
          "description": "TrendRadar 新闻热点聚合分析"
        }
      }
    }

    全局配置: 在用户目录创建 ~/.cursor/mcp.json(同样内容)

  3. 使用步骤:

    • 保存配置文件后重启 Cursor

    • 在聊天界面的 "Available Tools" 中查看已连接的工具

    • 开始使用:搜索今天的"AI"相关新闻

方式二:STDIO 模式(推荐)

创建 .cursor/mcp.json:

{
  "mcpServers": {
    "trendradar": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/TrendRadar",
        "run",
        "python",
        "-m",
        "mcp_server.server"
      ]
    }
  }
}

Cline 配置

在 Cline 的 MCP 设置中添加:

HTTP 模式:

{
  "trendradar": {
    "url": "http://localhost:3333/mcp",
    "type": "streamableHttp",
    "autoApprove": [],
    "disabled": false
  }
}

STDIO 模式(推荐):

{
  "trendradar": {
    "command": "uv",
    "args": [
      "--directory",
      "/path/to/TrendRadar",
      "run",
      "python",
      "-m",
      "mcp_server.server"
    ],
    "type": "stdio",
    "disabled": false
  }
}

Continue 配置

编辑 ~/.continue/config.json:

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "uv",
          "args": [
            "--directory",
            "/path/to/TrendRadar",
            "run",
            "python",
            "-m",
            "mcp_server.server"
          ]
        }
      }
    ]
  }
}

使用示例:

分析最近7天"特斯拉"的热度变化趋势
生成今天的热点摘要报告
搜索"比特币"相关新闻并分析情感倾向

MCP Inspector 是官方调试工具,用于测试 MCP 连接:

使用步骤

  1. 启动 TrendRadar HTTP 服务:

    # Windows
    start-http.bat
    
    # Mac/Linux
    ./start-http.sh
  2. 启动 MCP Inspector:

    npx @modelcontextprotocol/inspector
  3. 在浏览器中连接:

    • 访问:http://localhost:3333/mcp

    • 测试 "Ping Server" 功能验证连接

    • 检查 "List Tools" 是否返回 17 个工具:

      • 基础查询:get_latest_news, get_news_by_date, get_trending_topics

      • 智能检索:search_news, find_related_news

      • 高级分析:analyze_topic_trend, analyze_data_insights, analyze_sentiment, aggregate_news, compare_periods, generate_summary_report

      • RSS 查询:get_latest_rss, search_rss, get_rss_feeds_status

      • 系统管理:get_current_config, get_system_status, resolve_date_range

任何支持 Model Context Protocol 的客户端都可以连接 TrendRadar:

HTTP 模式

服务地址:http://localhost:3333/mcp

基本配置模板:

{
  "name": "trendradar",
  "url": "http://localhost:3333/mcp",
  "type": "http",
  "description": "新闻热点聚合分析"
}

STDIO 模式(推荐)

基本配置模板:

{
  "name": "trendradar",
  "command": "uv",
  "args": [
    "--directory",
    "/path/to/TrendRadar",
    "run",
    "python",
    "-m",
    "mcp_server.server"
  ],
  "type": "stdio"
}

注意事项:

  • 替换 /path/to/TrendRadar 为实际项目路径

  • Windows 路径使用反斜杠转义:C:\\Users\\...

  • 确保已完成项目依赖安装(运行过 setup 脚本)

常见问题

检查步骤:

  1. 确认端口 3333 未被占用:

    # Windows
    netstat -ano | findstr :3333
    
    # Mac/Linux
    lsof -i :3333
  2. 检查项目依赖是否安装:

    # 重新运行安装脚本
    # Windows: setup-windows.bat 或者 setup-windows-en.bat
    # Mac/Linux: ./setup-mac.sh
  3. 查看详细错误日志:

    uv run python -m mcp_server.server --transport http --port 3333
  4. 尝试自定义端口:

    uv run python -m mcp_server.server --transport http --port 33333

解决方案:

  1. STDIO 模式:

    • 确认 UV 路径正确(运行 which uv 或 where uv)

    • 确认项目路径正确且无中文字符

    • 查看客户端错误日志

  2. HTTP 模式:

    • 确认服务已启动(访问 http://localhost:3333/mcp)

    • 检查防火墙设置

    • 尝试使用 127.0.0.1 替代 localhost

  3. 通用检查:

    • 重启客户端应用

    • 查看 MCP 服务日志

    • 使用 MCP Inspector 测试连接

可能原因:

  1. 数据不存在:

    • 确认已运行过爬虫(有 output 目录数据)

    • 检查查询日期范围是否有数据

    • 查看 output 目录的可用日期

  2. 参数错误:

    • 检查日期格式:YYYY-MM-DD

    • 确认平台 ID 正确:zhihu, weibo 等

    • 查看工具文档中的参数说明

  3. 配置问题:

    • 确认 config/config.yaml 存在

    • 确认 config/frequency_words.txt 存在

    • 检查配置文件格式是否正确

📚 项目相关

4 篇文章:

AI 开发:

  • 如果你有小众需求,完全可以基于我的项目自行开发,零编程基础的也可以试试

  • 我所有的开源项目或多或少都使用了自己写的AI辅助软件来提升开发效率,这款工具已开源

  • 核心功能:迅速筛选项目代码喂给AI,你只需要补充个人需求即可

  • 项目地址:https://github.com/sansan0/ai-code-context-helper

其余项目

📍 毛主席足迹地图 - 交互式动态展示1893-1976年完整轨迹。欢迎诸位同志贡献数据

哔哩哔哩(bilibili)评论区数据可视化分析软件

Star History Chart

📄 许可证

GPL-3.0 License


🔝 回到顶部

Available Tools

27 tools
aggregate_newsA

跨平台新闻聚合 - 对相似新闻进行去重合并

将不同平台报道的同一事件合并为一条聚合新闻,显示跨平台覆盖情况和综合热度。

Args: date_range: 日期范围,不指定则查询今天 platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 similarity_threshold: 相似度阈值,0.3-1.0,默认0.7(越高越严格) limit: 返回聚合新闻数量,默认50 include_url: 是否包含URL链接,默认False

Returns: JSON格式的聚合结果,包含去重统计、聚合新闻列表和平台覆盖统计

Examples: - aggregate_news() - aggregate_news(similarity_threshold=0.8)

NameRequiredDescriptionDefault
limitNo
platformsNo
date_rangeNo
include_urlNo
similarity_thresholdNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

无任何注释,描述需承担行为披露责任。描述说明了去重合并行为、返回内容包含去重统计和平台覆盖统计,但未提及是否有副作用(如触发抓取)、是否需要提前抓取数据、是否有速率限制等。对于只读聚合工具,基本行为已透明,但缺少额外细节。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

描述以标题、Args、Returns、Examples分节,结构清晰,每个句子都有信息量,没有冗余。参数说明采用列表形式,并给出两个示例调用,简洁易读。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

所有参数均有解释,返回结构有概述,且有示例。存在输出schema,因此无需详述返回字段。唯一小缺失是date_range的具体格式(允许字符串或对象但未举例),但整体信息足够代理正确调用。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

输入schema的覆盖率为0%,但描述对所有5个参数都做了详细说明,包括类型、默认值、示例和含义(如similarity_threshold范围0.3-1.0,include_url控制是否包含链接)。描述完全补偿了schema的缺失,参数语义非常清晰。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

描述以明确的动词'聚合'和资源'新闻'开头,说明将相似新闻去重合并,并显示跨平台覆盖和综合热度。与兄弟工具如search_news、get_latest_news相比,功能边界清晰,可直接区分。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述通过功能说明隐含了使用场景(跨平台新闻去重聚合),但未明确说明何时应使用此工具而非其他工具(如search_news或find_related_news),也没有给出排除条件。缺乏显式的when/when-not指引。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_data_insightsA

统一数据洞察分析工具 - 整合多种数据分析模式

Args: insight_type: 洞察类型,可选值: - "platform_compare": 平台对比分析(对比不同平台对话题的关注度) - "platform_activity": 平台活跃度统计(统计各平台发布频率和活跃时间) - "keyword_cooccur": 关键词共现分析(分析关键词同时出现的模式) topic: 话题关键词(可选,platform_compare模式适用) date_range: 【对象类型】 日期范围(可选) - 格式: {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"} - 示例: {"start": "2025-01-01", "end": "2025-01-07"} - 重要: 必须是对象格式,不能传递整数 min_frequency: 最小共现频次(keyword_cooccur模式),默认3 top_n: 返回TOP N结果(keyword_cooccur模式),默认20

Returns: JSON格式的数据洞察分析结果

Examples: - analyze_data_insights(insight_type="platform_compare", topic="人工智能") - analyze_data_insights(insight_type="platform_activity", date_range={"start": "2025-01-01", "end": "2025-01-07"}) - analyze_data_insights(insight_type="keyword_cooccur", min_frequency=5, top_n=15)

NameRequiredDescriptionDefault
top_nNo
topicNo
date_rangeNo
insight_typeNoplatform_compare
min_frequencyNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that results are returned as JSON and describes analysis modes, but it never clarifies whether the tool is read-only, whether it triggers expensive computation, whether it depends on external data sources, or whether any state is changed. This leaves a meaningful transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized with an intro, Args, Returns, and Examples sections. Every line adds value: mode definitions, parameter constraints, and concrete usage examples are all present without redundant filler. It is long enough to be useful and compact enough to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three modes, conditional parameters, and subtle date_range typing, the description covers the essential invocation knowledge: which parameters apply to which mode, defaults, formats, and example calls. It does not explicitly explain what happens when irrelevant parameters are passed or describe error cases, but an output schema exists and the provided information is sufficient for basic correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description provides rich semantics for all five parameters: allowed insight_type values with mode meanings, optional topic, strict date_range object format with example and a warning against integers, plus defaults for min_frequency and top_n. This is exactly what an agent needs to construct valid calls and goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies an analysis tool for multiple data insight modes, enumerating three specific insight types with plain-language explanations. It does not explicitly differentiate itself from overlapping sibling tools like analyze_topic_trend or analyze_sentiment, so it misses a bit of sibling-targeted clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description shows when to use each mode through the insight_type options and concrete examples, but it never states when not to use the tool or which alternative sibling covers a similar case. Usage guidance is implied rather than explicit, especially given the large sibling set with analysis-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_sentimentA

分析新闻的情感倾向和热度趋势

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: topic: 话题关键词(可选) platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认今天 limit: 返回新闻数量,默认50,最大100(会对标题去重) sort_by_weight: 是否按热度权重排序,默认True include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的分析结果,包含情感分布、热度趋势和相关新闻

Examples: - analyze_sentiment(topic="AI", date_range={"start": "2025-01-01", "end": "2025-01-07"})

NameRequiredDescriptionDefault
limitNo
topicNo
platformsNo
date_rangeNo
include_urlNo
sort_by_weightNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by revealing meaningful behaviors: default date range is today, limit defaults to 50 and max 100, titles are deduplicated, platforms default to all, sorting defaults by heat weight, and include_url defaults to false to save tokens. It does not mention error cases or data-freshness limitations, but for a read-style analysis tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured and front-loaded: purpose, routing advice, parameter list, return summary, and example. It contains no filler or redundant explanation, and every section serves a practical purpose. The format makes it easy for an agent to scan and extract the needed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no annotations, and an output schema, the description is largely complete: all parameters are documented, return contents are summarized, an example is provided, and sibling routing is mentioned. The output schema exists, so detailed return fields do not need to be enumerated. The main missing element is clearer guidance on when to choose this tool over sibling analysis tools, and the available platform IDs are not listed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document the parameters, and it does. Every argument is explained with concrete details: date_range gets an explicit JSON format, platforms gets a realistic example, limit gets a maximum and deduplication note, and boolean flags get their default behavior. This fully compensates for the schema's lack of descriptive text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: analyze news sentiment and heat trends (分析新闻的情感倾向和热度趋势). It names a specific action and resource, and the parameter list clarifies that it works on a topic/platform/date range. However, it does not explicitly distinguish itself from similar sibling tools like analyze_topic_trend or analyze_data_insights, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit routing suggestion: if using natural-language dates, call resolve_date_range first. This is direct, actionable guidance for a specific alternative. It does not, however, discuss when this tool should be preferred over the other analysis-oriented siblings, so the usage guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_topic_trendA

统一话题趋势分析工具 - 整合多种趋势分析模式

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: topic: 话题关键词(必需) analysis_type: 分析类型 - "trend": 热度趋势分析(默认) - "lifecycle": 生命周期分析 - "viral": 异常热度检测 - "predict": 话题预测 date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认最近7天 granularity: 时间粒度,默认"day" spike_threshold: 热度突增倍数阈值(viral模式),默认3.0 time_window: 检测时间窗口小时数(viral模式),默认24 lookahead_hours: 预测未来小时数(predict模式),默认6 confidence_threshold: 置信度阈值(predict模式),默认0.7

Returns: JSON格式的趋势分析结果

Examples: - analyze_topic_trend(topic="AI", date_range={"start": "2025-01-01", "end": "2025-01-07"}) - analyze_topic_trend(topic="特斯拉", analysis_type="lifecycle")

NameRequiredDescriptionDefault
topicYes
date_rangeNo
granularityNoday
time_windowNo
analysis_typeNotrend
lookahead_hoursNo
spike_thresholdNo
confidence_thresholdNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses the JSON return format, the default date range, and mode-specific parameter behavior (viral thresholds, prediction lookahead, confidence). It does not mention rate limits, auth, or side effects, but for an analysis tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a title line, a usage tip, a compact Args block, Returns, and Examples. Every section adds value and the format is easy for an agent to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 0% schema description coverage, no annotations, and an output schema, the description is largely complete: it explains parameter semantics, defaults, mode-specific options, and gives examples. Minor gaps remain, such as valid granularity values and explicit sibling-tool selection guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description documents every parameter: topic as required, analysis_type with its four accepted values, date_range format, granularity, spike_threshold, time_window, lookahead_hours, and confidence_threshold. It fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies it as a topic-trend analysis tool ('统一话题趋势分析工具') and enumerates four analysis modes. It states a specific verb and resource, but it does not explicitly contrast it with sibling analysis tools like analyze_data_insights or analyze_sentiment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one practical workflow hint: call resolve_date_range for natural-language dates. However, it does not say when to prefer this tool over its analysis siblings or when not to use it, so the usage guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_versionA

检查版本更新(同时检查 TrendRadar 和 MCP Server)

比较本地版本与 GitHub 远程版本,判断是否需要更新。

Args: proxy_url: 可选的代理URL,用于访问 GitHub(如 http://127.0.0.1:7890)

Returns: JSON格式的版本检查结果,包含两个组件的版本对比和是否需要更新

Examples: - check_version() - check_version(proxy_url="http://127.0.0.1:7890")

NameRequiredDescriptionDefault
proxy_urlNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool compares local and GitHub remote versions, checks both TrendRadar and MCP Server, supports an optional proxy for GitHub access, and returns JSON with comparison and update-needed status. This is reasonably transparent, though it does not explicitly state side-effect-free behavior or network failure characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Purpose, Args, Returns, and Examples sections. It is compact, front-loaded with the main purpose, and every section contributes useful information without padding or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and an output schema available, the description is complete enough to invoke correctly. It explains the return format, the optional argument, and provides two concrete call examples. Nothing essential is missing for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. The Args section fully explains proxy_url as an optional proxy URL to access GitHub, provides a concrete example, and the schema supplies the default null. This adds clear meaning beyond the bare type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: it checks version updates by comparing local versions with GitHub remote versions, covering both TrendRadar and MCP Server. This makes it immediately distinguishable from sibling tools like sync_from_remote or get_system_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied by the purpose and examples, but the description does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of sibling tools or exclusion cases, so guidance is only inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_periodsA

时期对比分析 - 比较两个时间段的新闻数据

对比不同时期的热点话题、平台活跃度、新闻数量等维度。

使用场景:

  • 对比本周和上周的热点变化

  • 分析某个话题在两个时期的热度差异

  • 查看各平台活跃度的周期性变化

Args: period1: 第一个时间段(基准期) - {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"}: 日期范围 - "today", "yesterday", "this_week", "last_week", "this_month", "last_month": 预设值 period2: 第二个时间段(对比期,格式同 period1) topic: 可选的话题关键词(聚焦特定话题的对比) compare_type: 对比类型 - "overview": 总体概览(默认)- 新闻数量、关键词变化、TOP新闻 - "topic_shift": 话题变化分析 - 上升话题、下降话题、新出现话题 - "platform_activity": 平台活跃度对比 - 各平台新闻数量变化 platforms: 平台过滤列表,如 ['zhihu', 'weibo'] top_n: 返回 TOP N 结果,默认10

Returns: JSON格式的对比分析结果,包含: - periods: 两个时期的日期范围 - compare_type: 对比类型 - overview/topic_shift/platform_comparison: 具体对比结果(根据类型)

Examples: - compare_periods(period1="last_week", period2="this_week") # 周环比 - compare_periods(period1="last_month", period2="this_month", compare_type="topic_shift") - compare_periods( period1={"start": "2025-01-01", "end": "2025-01-07"}, period2={"start": "2025-01-08", "end": "2025-01-14"}, topic="人工智能" )

NameRequiredDescriptionDefault
top_nNo
topicNo
period1Yes
period2Yes
platformsNo
compare_typeNooverview

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry behavioral disclosure. It explains that compare_type selects different analyses (overview, topic_shift, platform_activity), that platforms filters sources, and that the result is JSON with period and type fields. It stops short of discussing failure modes, rate limits, or explicit read-only guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with clear sections (purpose, use cases, arguments, returns, examples) and front-loads the core purpose. Despite covering six parameters, every sentence contributes useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter analytical tool with no annotations but an output schema, the description is complete: all parameters are specified, supported values are listed, return shape is summarized, and three usage examples are provided. Nothing necessary to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully document parameters. It does: period1/period2 accept either object ranges or presets, topic is optional, compare_type enumerates all three values with meanings, platforms provides a concrete example, and top_n has its default. Examples reinforce the parameter formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with '时期对比分析 - 比较两个时间段的新闻数据', which names a specific verb (compare) and resource (news data across two periods). The use-case bullets further distinguish it from single-period or trend-only siblings by focusing on dual-period comparisons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

A dedicated '使用场景' section lists concrete scenarios such as comparing this week vs last week and analyzing topic heat differences across periods. It gives clear when-to-use context but does not explicitly name excluded alternatives or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_summary_reportA

每日/每周摘要生成器 - 自动生成热点摘要报告

Args: report_type: 报告类型(daily/weekly) date_range: 【对象类型】 自定义日期范围(可选) - 格式: {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"} - 示例: {"start": "2025-01-01", "end": "2025-01-07"} - 重要: 必须是对象格式,不能传递整数

Returns: JSON格式的摘要报告,包含Markdown格式内容

NameRequiredDescriptionDefault
date_rangeNo
report_typeNodaily

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It adds useful details: the output is JSON containing Markdown, and date_range must be an object rather than an integer. It does not disclose side effects, permissions, or any processing limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: a one-line purpose, then Args with clear formatting, then Returns. Every line adds value, and the object-format warning is high-signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two optional parameters and an output schema, it covers parameter formats and the return shape well. The main omissions are when-to-use guidance and side-effect/permission hints, which would make it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema is under-specified: report_type is a plain string and date_range is a loose anyOf. The description compensates strongly by defining report_type values as daily/weekly and giving the exact date_range object format, an example, and a warning against passing integers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it generates daily/weekly hotspot summary reports. The daily/weekly scope is concrete, though it does not explicitly distinguish itself from sibling analysis tools like analyze_topic_trend or aggregate_news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool instead of siblings such as analyze_data_insights or aggregate_news. It only lists parameter values, not use conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_channel_format_guideA

获取通知渠道的格式化策略指南

返回各渠道支持的 Markdown 特性、格式限制和最佳格式化提示词。 在调用 send_notification 之前使用此工具,可以了解目标渠道的格式要求, 从而生成最佳排版效果的消息内容。

各渠道格式差异概览:

  • 飞书:支持 粗体、彩色文本、链接、--- 分割线

  • 钉钉:支持 ### 标题、粗体、> 引用、--- 分割线,不支持颜色

  • 企业微信:仅支持 粗体、链接、> 引用,不支持标题和分割线

  • Telegram:自动转为 HTML,支持粗体/斜体/删除线/代码/链接/引用块

  • ntfy:支持标准 Markdown,不支持颜色

  • Bark:iOS 推送,仅支持粗体和链接,内容需精简

  • Slack:自动转为 mrkdwn,粗体、删除线、<url|链接>

  • 邮件:自动转为完整 HTML 网页,支持标题/样式/分割线

  • 通用 Webhook:标准 Markdown 或自定义模板

Args: channel: 指定渠道 ID(可选),不指定返回所有渠道策略 可选值: feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook

Returns: JSON格式的渠道格式化策略,包含支持特性、限制和格式化提示词

Examples: - get_channel_format_guide() # 获取所有渠道策略 - get_channel_format_guide(channel="feishu") # 获取飞书策略 - get_channel_format_guide(channel="telegram") # 获取 Telegram 策略

NameRequiredDescriptionDefault
channelNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly conveys a read-only, informational operation ('获取', '返回'), describes the JSON return format, and enumerates the detailed behavior across channels. It does not explicitly state 'read-only' or discuss side effects, but the non-mutating nature is strongly implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but highly structured and information-dense. It front-loads the purpose, then organizes channel differences, arguments, return type, and examples into clearly labeled sections. Every sentence contributes actionable information, and the per-channel breakdown is directly useful for the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, and the description still supplies essential context: optional behavior, valid channel IDs, return format, and usage examples. Given the tool's simple single-parameter interface, nothing an agent needs to select and invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must fully compensate. It defines the channel parameter, lists all valid values (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook), explains that omitting it returns all channel policies, and gives concrete usage examples. This exceeds what the minimal schema alone would provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: '获取通知渠道的格式化策略指南' (get notification channel formatting policy guide), and explicitly states it returns Markdown features, formatting restrictions, and best-practice prompt suggestions per channel. This clearly differentiates it from sibling tools like send_notification and get_notification_channels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool before calling send_notification to understand the target channel's format requirements. It provides clear context for when it is relevant, though it does not explicitly discuss when not to use it or name alternatives beyond its relationship to send_notification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_configA

获取当前系统配置

Args: section: 配置节,可选值: - "all": 所有配置(默认) - "crawler": 爬虫配置 - "push": 推送配置 - "keywords": 关键词配置 - "weights": 权重配置

Returns: JSON格式的配置信息

NameRequiredDescriptionDefault
sectionNoall

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only 'get' operation and mentions the JSON return format, but does not address potential authentication requirements, whether the config reflects live or cached state, or any other side effects. Sufficient for a simple getter, but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with a front-loaded purpose and clear Args/Returns sections. It contains no fluff, though it slightly repeats the default value already present in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and an output schema, the description is nearly complete. It documents all section choices and the return type. The only minor gap is not clarifying what 'current' means (e.g., live system state vs. persisted config), but this is not critical for a config getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only provides a default value and type for `section`, while the description adds all valid values: 'all', 'crawler', 'push', 'keywords', and 'weights'. Since schema description coverage is 0%, this description fully compensates by giving the agent the exact enumeration needed to call the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets the current system configuration, with a specific resource (config) and verb (获取/get). It lists distinct config sections, which helps differentiate it from siblings like get_system_status or get_storage_status, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the `section` parameter and its allowed values, but it does not provide guidance on when to use this tool versus the many sibling tools. No exclusions or alternative tool references are given, leaving usage context to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_newsA

获取最新一批爬取的新闻数据,快速了解当前热点

Args: platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 返回条数限制,默认50,最大1000 include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的新闻列表

数据展示建议

  • 默认展示全部返回数据,除非用户明确要求总结

  • 用户说"总结"或"挑重点"时才进行筛选

  • 用户问"为什么只显示部分"说明需要完整数据

NameRequiredDescriptionDefault
limitNo
platformsNo
include_urlNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses return format, default limit, platform handling, include_url token-saving behavior, and explicit display expectations for the agent. It does not cover error behavior or data freshness guarantees, but the read-only nature is clear from the get verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args, Returns, and display guidance sections. The main purpose is front-loaded, and each section earns its place, though the display-suggestion block is slightly beyond tool invocation semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with three optional parameters and an output schema, the description is largely complete: it covers parameter behavior, defaults, return format, and agent-facing display policy. It could still mention ordering of results or what news fields are returned, but the output schema likely covers those.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fully compensates by explaining all three parameters: platforms, limit with default and max, and include_url with its token-saving rationale. This is exactly the semantic content the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it fetches the latest batch of crawled news data to quickly understand current hotspots. It is distinguishable from siblings like get_latest_rss and get_news_by_date, though it does not explicitly name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives such as search_news, get_news_by_date, or get_trending_topics. The only usage-related context is the display suggestion block, which addresses how to present results rather than when to select this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_rssA

获取最新的 RSS 订阅数据(支持多日查询)

RSS 数据与热榜新闻分开存储,按时间流展示,适合获取特定来源的最新内容。

Args: feeds: RSS 源 ID 列表,如 ['hacker-news', '36kr'],不指定则返回所有源 days: 获取最近 N 天的数据,默认 1(仅今天),最大 30 天 limit: 返回条数限制,默认50,最大500 include_summary: 是否包含文章摘要,默认False(节省token)

Returns: JSON格式的 RSS 条目列表

Examples: - get_latest_rss() - get_latest_rss(days=7, feeds=['hacker-news'])

NameRequiredDescriptionDefault
daysNo
feedsNo
limitNo
include_summaryNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses storage separation, time-flow display, default/maximum values, and the token-saving effect of include_summary. As a read-only fetch tool, this is adequate, though it does not mention error or authentication behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with a clear purpose, structured Args, Returns, and Examples sections. Minor redundancy like 支持多日查询 repeating the days parameter details is acceptable but slightly unnecessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All four parameters are documented with defaults and limits, return format is specified as JSON, and examples demonstrate typical calls. The presence of an output schema means detailed return-field documentation is unnecessary, making this complete for a read-only RSS fetching tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: feeds with ID examples, days with range and default, limit with cap, and include_summary with its purpose. This goes far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 获取最新的 RSS 订阅数据, and further clarifies that RSS data is stored separately from hot-list news and displayed as a time stream. This makes it easy to distinguish from siblings like get_latest_news and search_rss.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case: retrieving recent content from specific RSS sources, and notes that RSS data is separate from hot-list news. However, it does not explicitly name alternatives such as search_rss or state when not to use this tool, so exclusions are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_news_by_dateA

获取指定日期的新闻数据,用于历史数据分析和对比

Args: date_range: 日期范围,支持多种格式: - 范围对象: {"start": "2025-01-01", "end": "2025-01-07"} - 自然语言: "今天", "昨天", "本周", "最近7天" - 单日字符串: "2025-01-15" - 默认值: "今天" platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 返回条数限制,默认50,最大1000 include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的新闻列表,包含标题、平台、排名等信息

NameRequiredDescriptionDefault
limitNo
platformsNo
date_rangeNo
include_urlNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains date_range formats, platform filtering behavior, limit maximums, and the include_url token-saving default. It does not mention error handling, rate limits, or authentication, but the read-only nature of 'fetch' is clear and the parameter behaviors are well documented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise purpose sentence followed by a clean Args/Returns breakdown. Every argument is explained with practical examples and defaults, with no filler or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four optional parameters and an output schema, and the description covers all parameters, defaults, and return fields. It lacks edge-case details such as empty-result behavior or timezone handling, but for a read-only historical query tool, the description provides enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate for parameter semantics. It does this excellently: date_range has multiple explicit format examples, platforms has an example list, limit has default and max values, and include_url states its default and rationale. This is more informative than the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool fetches news data for a specified date range for historical analysis and comparison. This is a specific verb+resource pair that distinguishes it from get_latest_news, though it does not explicitly name sibling alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage context: historical data analysis and comparison. It implies this tool is for date-bound queries rather than real-time or keyword searches, but it does not explicitly state when to prefer alternatives like get_latest_news or search_news.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_notification_channelsB

获取所有已配置的通知渠道及其状态

检测 config.yaml 和 .env 环境变量中的通知渠道配置。 支持 9 个渠道:飞书、钉钉、企业微信、Telegram、邮件、ntfy、Bark、Slack、通用 Webhook。

Returns: JSON格式的渠道状态,包含每个渠道是否已配置及配置来源

Examples: - get_notification_channels()

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool reads config.yaml and .env and returns a JSON status with configuration source, which is useful. However, it does not explicitly state that the operation is read-only, makes no external calls, or sends no notifications, which would be valuable given the sibling send_notification.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and key details are front-loaded, with the Returns and Examples sections adding clarity without excessive verbosity. Listing nine channels is necessary context, and the structure is easy to scan. Minor redundancy exists because the return format is already captured by the output schema, but it does not hurt usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool returns, which config files are inspected, the list of supported channels, and a usage example. Since the tool has no parameters and an output schema exists, this is nearly complete. The main missing element is explicit guidance about how this tool relates to sibling notification tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero properties and 100% schema coverage, so there is no parameter detail for the description to add. The description includes an example invocation `get_notification_channels()` that confirms no arguments are required, satisfying the baseline for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: “获取所有已配置的通知渠道及其状态” (get all configured notification channels and their status). It further clarifies scope by listing 9 supported channels and the config sources checked. It does not explicitly differentiate from sibling tools like get_channel_format_guide, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a usage context by mentioning config.yaml and .env detection, but it never states when to use this tool versus alternatives such as send_notification or get_channel_format_guide. There are no explicit exclusions or conditions that would help an agent decide between tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_rss_feeds_statusA

获取 RSS 源状态信息

查看当前配置的 RSS 源及其数据统计信息。

Returns: JSON格式的 RSS 源状态,包含: - available_dates: 有 RSS 数据的日期列表 - total_dates: 总日期数 - today_feeds: 今日各 RSS 源的数据统计 - {feed_id}: { name, item_count } - generated_at: 生成时间

Examples: - get_rss_feeds_status() # 查看所有 RSS 源状态

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description conveys that this is a read-only status view through '查看' and details of generated statistics. However, it does not explicitly state side-effect-free behavior, whether data is cached, or how it behaves when no feeds exist, so the burden is only partially met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured and front-loaded with purpose, followed by a compact Returns list and an example. The opening line '获取 RSS 源状态信息' is mildly redundant with the name and second sentence, but overall there is no wasted bulk.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-parameter status tool, the description is largely complete: it states scope, return structure, and an example invocation. It could be more complete by explicitly distinguishing when to use this over sibling tools like get_system_status or list_available_dates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, and the example get_rss_feeds_status() confirms no arguments are required. With schema coverage at 100% and no params, the description adds no parameter semantics but none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('获取/查看') and a specific resource (RSS feeds status and their data statistics), and the Returns section defines exactly what is included. It differentiates from siblings like get_system_status/get_storage_status by scoping to configured RSS sources and their stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context: use this to view currently configured RSS sources and their data statistics. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the context is specific enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_storage_statusA

获取存储配置和状态

查看当前存储后端配置、本地和远程存储的状态信息。

Returns: JSON格式的存储状态信息,包含本地/远程存储状态和拉取配置

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

无注释提供,描述承担了行为披露的负担。描述了返回内容和格式(JSON状态信息),但未明确说明操作是否只读、是否会触发副作用或需要权限。不过“查看”和“获取”暗示了非破坏性,基本行为是清晰的。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

描述简洁高效,第一句即点明核心功能,随后补充返回内容,每句话都有价值,没有冗余信息。

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

工具无参数、有输出模式,描述已涵盖返回格式和主要内容。对于这种简单查询工具,没有遗漏关键信息,描述足以让代理正确调用。

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

该工具没有参数,输入模式为空,因此描述无需补充参数语义。根据规则,0参数时基线得分为4。

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

描述明确使用了具体动词“获取/查看”,资源是“存储配置和状态”,并具体说明包含本地/远程存储状态和拉取配置。与兄弟工具如get_rss_feeds_status、get_system_status在名称和描述上都能清晰区分。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

描述隐含了用途(查看存储状态),但没有明确说明何时使用此工具而非其他工具,也没有提及替代方案或排除条件。虽然功能自明,但缺少显式的使用情境指导。

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_system_statusB

获取系统运行状态和健康检查信息

返回系统版本、数据统计、缓存状态等信息

Returns: JSON格式的系统状态信息

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of explaining behavior. It indicates a read-only operation through '获取' and '返回', and lists what data is returned. However, it does not explicitly state that the operation is non-destructive, or disclose any side effects, auth requirements, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but somewhat repetitive: '返回系统版本、数据统计、缓存状态等信息' and 'Returns: JSON格式的系统状态信息' overlap. Given that an output schema exists, the final 'Returns' line adds marginal value and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple parameterless status tool with an output schema, and the description covers what the status includes and the return format. However, it lacks guidance on how this tool relates to overlapping siblings and does not compensate for the absence of annotations with additional behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds no parameter semantics, but the baseline for a parameterless tool is 4, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: '获取系统运行状态和健康检查信息' (get system running status and health check info) and lists concrete contents (system version, data statistics, cache status). This is clear, though it does not explicitly differentiate itself from siblings like get_storage_status or check_version beyond the broad scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance about when to use this tool versus the many related siblings such as get_rss_feeds_status, get_storage_status, get_current_config, or check_version. The description implies general system status retrieval but provides no conditions, exclusions, or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_available_datesA

列出本地/远程可用的日期范围

查看本地和远程存储中有哪些日期的数据可用。

Args: source: 数据来源 - "local": 仅本地 - "remote": 仅远程 - "both": 同时列出并对比(默认)

Returns: JSON格式的日期列表,包含各来源的日期信息和对比结果

Examples: - list_available_dates() - list_available_dates(source="local")

NameRequiredDescriptionDefault
sourceNoboth

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the behavioral disclosure burden. It discloses that the tool reads local/remote storage, can compare both, and returns JSON date lists, which is adequate for a non-destructive listing tool. However, it does not mention date format, empty-result behavior, or network/error implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with summary, Args, Returns, and Examples sections, making it easy to scan. There is minor redundancy between '列出本地/远程可用的日期范围' and '查看本地和远程存储中有哪些日期的数据可用', but no wasteful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no required fields, the description covers purpose, source values, return shape, and examples; an output schema also exists. It could add exact date range format or behavior when no data is available, but nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says source is a string with default 'both' and has 0% description coverage. The description compensates by enumerating valid values local/remote/both, stating the default, and giving examples. There is no ambiguity about how to use the only parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first line names a specific operation (列出) and resource (local/remote available date ranges), and the description expands on distinct scopes. It stands apart from siblings like get_news_by_date or resolve_date_range because it focuses on availability of dates in storage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use the source parameter and what each value does, but it does not explicitly state when to use this tool instead of siblings such as resolve_date_range or get_news_by_date. Usage is implied through '查看本地和远程存储中有哪些日期的数据可用', but no exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_articleA

读取指定 URL 的文章内容,返回 LLM 友好的 Markdown 格式

通过 Jina AI Reader 将网页转换为干净的 Markdown,自动去除广告、导航栏等噪音内容。 适合用于:阅读新闻正文、获取文章详情、分析文章内容。

典型使用流程:

  1. 先用 search_news(include_url=True) 搜索新闻获取链接

  2. 再用 read_article(url=链接) 读取正文内容

  3. AI 对 Markdown 正文进行分析、摘要、翻译等

Args: url: 文章链接(必需),以 http:// 或 https:// 开头 timeout: 请求超时时间(秒),默认 30,最大 60

Returns: JSON格式的文章内容,包含完整 Markdown 正文

Examples: - read_article(url="https://example.com/news/123")

Note: - 使用 Jina AI Reader 免费服务(100 RPM 限制) - 每次请求间隔 5 秒(内置速率控制) - 部分付费墙/登录墙页面可能无法完整获取

NameRequiredDescriptionDefault
urlYes
timeoutNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does so well. It discloses the underlying Jina AI Reader service, automatic noise removal, the free-tier 100 RPM limit, built-in 5-second rate control, and the fact that paywalled/login-walled pages may not be fully retrievable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized with sections for purpose, use cases, workflow, arguments, return format, and limitations. Every section adds practical information for an agent, and the primary purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core return value (JSON containing Markdown), the expected usage flow, rate limits, and failure caveats. For a small two-parameter tool, this is sufficient for an agent to select and call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates fully. It specifies that url is required and must start with http:// or https://, gives timeout semantics with default 30 and max 60, and includes a concrete example call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: reading the content of a given URL and converting it to LLM-friendly Markdown. It clearly differentiates from search-oriented siblings by focusing on fetching and cleaning page content rather than discovering or aggregating news.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context: use after search_news(include_url=True), and for reading news正文, getting article details, or analyzing content. It does not explicitly contrast with read_articles_batch, so it lacks a direct exclusion for multi-URL cases, but the intended workflow is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_articles_batchA

批量读取多篇文章内容(最多 5 篇,间隔 5 秒)

逐篇请求文章内容,每篇之间自动间隔 5 秒以遵守速率限制。

典型使用流程:

  1. 先用 search_news(include_url=True) 搜索新闻获取多个链接

  2. 再用 read_articles_batch(urls=[...]) 批量读取正文

  3. AI 对多篇文章进行对比分析、综合报告

Args: urls: 文章链接列表(必需),最多处理 5 篇 timeout: 每篇的请求超时时间(秒),默认 30

Returns: JSON格式的批量读取结果,包含每篇的完整内容和状态

Examples: - read_articles_batch(urls=["https://a.com/1", "https://b.com/2"])

Note: - 单次最多读取 5 篇,超出部分会被跳过 - 5 篇约需 25-30 秒(每篇间隔 5 秒) - 单篇失败不影响其他篇的读取

NameRequiredDescriptionDefault
urlsYes
timeoutNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description bears the full burden of behavior disclosure and succeeds: it reveals automatic 5-second spacing for rate-limit compliance, a hard cap of 5 articles with excess skipped, per-article failure isolation, expected duration, and the nature of the JSON return. This is substantial valuable context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections for Args, Returns, Examples, and Notes, making it scannable. It loses a point for redundancy: the 5-article limit and 5-second interval are repeated in the opening sentence, the following paragraph, and the Notes section, but the overall size remains reasonable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity, two parameters, no annotations, and the presence of an output schema, the description covers every practical need: selection workflow, limits, timing, timeout, partial failure behavior, and return shape. An agent can correctly invoke this tool without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates: urls is explained as a required list of article links with a maximum of 5, and timeout is defined as per-request timeout in seconds with default 30. This adds semantic meaning the bare input schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '批量读取多篇文章内容(最多 5 篇,间隔 5 秒)'. It clearly differentiates from the sibling read_article by emphasizing batch processing, and even provides a workflow where it follows search_news, making its role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete '典型使用流程' with an explicit before-step: first search_news(include_url=True) to get URLs, then read_articles_batch(urls=[...]). It does not explicitly contrast with read_article or list exclusions, but the workflow and batch scope make the primary use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_date_rangeA

【推荐优先调用】将自然语言日期表达式解析为标准日期范围

为什么需要这个工具? 用户经常使用"本周"、"最近7天"等自然语言表达日期,但 AI 模型自己计算日期 可能导致不一致的结果。此工具在服务器端使用精确的当前时间计算,确保所有 AI 模型获得一致的日期范围。

推荐使用流程:

  1. 用户说"分析AI本周的情感倾向"

  2. AI 调用 resolve_date_range("本周") → 获取精确日期范围

  3. AI 调用 analyze_sentiment(topic="ai", date_range=上一步返回的date_range)

Args: expression: 自然语言日期表达式,支持: - 单日: "今天", "昨天", "today", "yesterday" - 周: "本周", "上周", "this week", "last week" - 月: "本月", "上月", "this month", "last month" - 最近N天: "最近7天", "最近30天", "last 7 days", "last 30 days" - 动态: "最近5天", "last 10 days"(任意天数)

Returns: JSON格式的日期范围,可直接用于其他工具的 date_range 参数: { "success": true, "expression": "本周", "date_range": { "start": "2025-11-18", "end": "2025-11-26" }, "current_date": "2025-11-26", "description": "本周(周一到周日,11-18 至 11-26)" }

Examples: 用户:"分析AI本周的情感倾向" AI调用步骤: 1. resolve_date_range("本周") → {"date_range": {"start": "2025-11-18", "end": "2025-11-26"}, ...} 2. analyze_sentiment(topic="ai", date_range={"start": "2025-11-18", "end": "2025-11-26"})

用户:"看看最近7天的特斯拉新闻"
AI调用步骤:
1. resolve_date_range("最近7天")
   → {"date_range": {"start": "2025-11-20", "end": "2025-11-26"}, ...}
2. search_news(query="特斯拉", date_range={"start": "2025-11-20", "end": "2025-11-26"})
NameRequiredDescriptionDefault
expressionYes

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses server-side computation using precise current time, consistency across AI models, supported expression categories, and the exact return JSON shape. It does not discuss failure behavior or timezone assumptions, but it provides substantial behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than minimal, but it is well-structured with headers, bullet lists, and examples, and each section adds value. The workflow and duplicate examples are somewhat repetitive, but the structure is scannable and front-loaded with the recommended-priority guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter helper tool with no annotations but an output schema, the description is complete: it covers why the tool exists, when to call it, how to call it, supported inputs, return format, and worked examples chaining into other tools. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain the parameter, and it does. It documents the single 'expression' parameter with categorized supported formats, examples, and dynamic 'last N days' support, adding clear meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves natural language date expressions into a standard date range using a specific verb and resource. It distinguishes itself by explaining this is the recommended first call before date-consuming tools like analyze_sentiment, and the scope is precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends prioritizing this tool when users express dates naturally and provides a step-by-step workflow with concrete examples. It does not explicitly state when not to use it or name alternative date-related tools, but the usage context is strong and unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_newsA

统一搜索接口,支持多种搜索模式,可同时搜索热榜和RSS

建议:使用自然语言日期时,先调用 resolve_date_range 获取精确日期范围。

Args: query: 搜索关键词或内容片段 search_mode: 搜索模式 - "keyword": 精确关键词匹配(默认) - "fuzzy": 模糊内容匹配 - "entity": 实体名称搜索(人物/地点/机构) date_range: 日期范围,格式 {"start": "YYYY-MM-DD", "end": "YYYY-MM-DD"},默认今天 platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 limit: 热榜返回条数限制,默认50 sort_by: 排序方式 - "relevance"(相关度)/ "weight"(权重)/ "date"(日期) threshold: 相似度阈值(仅fuzzy模式),0-1,默认0.6 include_url: 是否包含URL链接,默认False include_rss: 是否同时搜索RSS数据,默认False rss_limit: RSS返回条数限制,默认20

Returns: JSON格式的搜索结果,包含热榜新闻列表和可选的RSS结果

Examples: - search_news(query="AI") - search_news(query="AI", include_rss=True) - search_news(query="特斯拉", date_range={"start": "2025-01-01", "end": "2025-01-07"})

NameRequiredDescriptionDefault
limitNo
queryYes
sort_byNorelevance
platformsNo
rss_limitNo
thresholdNo
date_rangeNo
include_rssNo
include_urlNo
search_modeNokeyword

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral disclosure burden. It explains that the tool returns JSON with hot searches and optional RSS results, and describes search modes and filtering. It does not disclose potential side effects, rate limits, or result ordering behavior beyond the sort_by parameter, so coverage is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized: a purpose statement, a cross-tool suggestion, a parameter reference, return description, and examples. Every section adds value, and the structure makes the long parameter list scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 10 parameters, but the description covers parameters, defaults, modes, and examples, while an output schema exists for return values. The only meaningful gap is the lack of explicit guidance on when to choose this tool versus closely related sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description fully compensates with a detailed Args block explaining every parameter, including search_mode variants, threshold semantics, date_range format, and default values. This goes well beyond the schema and gives agents actionable parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies this as a unified search interface that searches both hot lists and RSS, with multiple search modes. It is distinguishable from siblings like search_rss and get_latest_news, though it does not explicitly name them or contrast itself against them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a concrete usage suggestion to call resolve_date_range for natural language dates, which gives useful cross-tool guidance. However, it does not explicitly state when to prefer this over sibling tools such as search_rss or get_trending_topics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_rssA

搜索 RSS 数据

在 RSS 订阅数据中搜索包含指定关键词的文章。

Args: keyword: 搜索关键词(必需) feeds: RSS 源 ID 列表,如 ['hacker-news', '36kr'] - 不指定时:搜索所有 RSS 源 days: 搜索最近 N 天的数据,默认 7 天,最大 30 天 limit: 返回条数限制,默认50 include_summary: 是否包含文章摘要,默认False

Returns: JSON格式的匹配 RSS 条目列表

Examples: - search_rss(keyword="AI") - search_rss(keyword="machine learning", feeds=['hacker-news'], days=14)

NameRequiredDescriptionDefault
daysNo
feedsNo
limitNo
keywordYes
include_summaryNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers feed scoping behavior, default and maximum days, limit default, include_summary default, and the JSON return format. It does not mention sorting, matching semantics, or error behavior, but these are relatively minor for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-line summary, an Args block, Returns, and Examples. Every section earns its place, there is no filler, and the most important scoping information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter search tool with no annotations, the description covers parameter semantics, defaults, return type, and provides two concrete invocation examples. It omits details like valid feed identifiers and sort order, but these are largely discoverable from sibling tools and do not prevent correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description fully compensates by explaining every parameter: keyword is required, feeds has an example and default behavior, days has default/max, limit has default, and include_summary has default. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: searching RSS subscription data for articles containing a keyword. It is unambiguous about the resource (RSS 订阅数据) but does not explicitly distinguish itself from sibling tools like search_news or get_latest_rss, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful behavioral context such as 'search all RSS feeds when feeds is not specified' and includes examples, which imply typical usage. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving some routing decisions to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_notificationA

向已配置的通知渠道发送消息

接受 markdown 格式内容,内部自动适配各渠道的格式要求和限制:

  • 飞书:Markdown 卡片消息(支持 粗体、彩色文本、链接、---)

  • 钉钉:Markdown(自动降级标题为 ###、剥离 标签和删除线)

  • 企业微信:Markdown(自动剥离 # 标题、---、 标签、删除线)

  • Telegram:HTML(自动转换 **→、*→、~~→、>→)

  • Email:HTML 邮件(完整网页样式,支持 # 标题、---、粗体斜体)

  • ntfy:Markdown(自动剥离 标签)

  • Bark:Markdown(自动简化为粗体+链接,适配 iOS 推送)

  • Slack:mrkdwn(自动转换 **→*、~~→~、text→<url|text>)

  • 通用 Webhook:Markdown(支持自定义模板)

提示:发送前可调用 get_channel_format_guide 获取目标渠道的详细格式化策略, 以生成最佳排版效果的消息内容。

Args: message: markdown 格式的消息内容(必需) title: 消息标题,默认 "TrendRadar 通知" channels: 指定发送的渠道列表,不指定则发送到所有已配置渠道 可选值: feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook

Returns: JSON格式的发送结果,包含每个渠道的发送状态

Examples: - send_notification(message="测试消息\n这是一条测试通知") - send_notification(message="紧急通知", title="系统告警", channels=["feishu", "dingtalk"])

NameRequiredDescriptionDefault
titleNoTrendRadar 通知
messageYes
channelsNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by detailing how markdown is adapted per channel (e.g., Telegram converts ** to <b>, Slack converts ** to *), stating that channels default to all configured channels, and noting that the return is JSON with per-channel status. It could be more transparent about failure behavior and rate limits, but the given detail is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with sections: purpose, per-channel formatting details, a helpful tip, args, return value, and examples. Every section earns its place, and the most important information is front-loaded. The per-channel list is dense but directly useful for predicting tool behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of multi-channel formatting and zero schema coverage, the description is remarkably complete. It explains what the tool does, how it transforms content for each channel, what parameters are accepted, what the return value looks like, and gives examples. The mention of get_channel_format_guide also connects it to related tooling. No critical information needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all parameter meaning. It does so thoroughly: message is marked as required markdown content, title has a default of 'TrendRadar 通知', and channels lists all valid values. Examples further clarify usage. This fully bridges the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '向已配置的通知渠道发送消息' (send messages to configured notification channels). It clearly distinguishes itself from sibling tools like get_channel_format_guide and get_notification_channels by focusing on the sending action rather than retrieval or guidance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it sends markdown-formatted messages to channels, optionally specifying channels, and explicitly recommends calling get_channel_format_guide before sending for optimal formatting. It does not explicitly state when not to use this tool, but the purpose is distinct enough among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_from_remoteA

从远程存储拉取数据到本地

用于 MCP Server 等场景:爬虫存到远程云存储(如 Cloudflare R2), MCP Server 拉取到本地进行分析查询。

Args: days: 拉取最近 N 天的数据,默认 7 天 - 0: 不拉取 - 7: 拉取最近一周的数据 - 30: 拉取最近一个月的数据

Returns: JSON格式的同步结果,包含: - success: 是否成功 - synced_files: 成功同步的文件数量 - synced_dates: 成功同步的日期列表 - skipped_dates: 跳过的日期(本地已存在) - failed_dates: 失败的日期及错误信息 - message: 操作结果描述

Examples: - sync_from_remote() # 拉取最近7天 - sync_from_remote(days=30) # 拉取最近30天

Note: 需要在 config/config.yaml 中配置远程存储(storage.remote)或设置环境变量: - S3_ENDPOINT_URL: 服务端点 - S3_BUCKET_NAME: 存储桶名称 - S3_ACCESS_KEY_ID: 访问密钥 ID - S3_SECRET_ACCESS_KEY: 访问密钥

NameRequiredDescriptionDefault
daysNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the behavioral disclosure burden, and it largely does. It explains that dates already present locally are skipped (skipped_dates), failed dates are reported with errors, and the operation requires specific S3 configuration. It does not explicitly warn about network load or whether it modifies existing files beyond skipping, but the skip behavior implies non-destructive sync.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: overview, Args, Returns, Examples, and Note. Every section contributes necessary information — parameter semantics, return schema, usage examples, and configuration requirements — with no redundant filler. The purpose sentence is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool, the description covers everything needed to invoke it correctly: parameter meaning and default, return format with all fields, configuration requirements, and usage examples. The output schema exists, but the description already details the return structure sufficiently, and the sibling context shows this is a standalone sync operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only defines 'days' as an integer with default 7 and 0% description coverage. The tool description fully compensates by explaining the meaning ('pull data from the last N days'), enumerating common values (0, 7, 30) with concrete interpretations, and providing examples for both default and explicit usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: '从远程存储拉取数据到本地' (pull data from remote storage to local), making the tool's core action unmistakable. It also situates the tool in the MCP Server workflow (crawlers store to remote cloud storage, server pulls for local analysis), which clearly distinguishes it from siblings like trigger_crawl, get_storage_status, or list_available_dates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context: pulling crawler data from remote cloud storage (e.g., Cloudflare R2) into local for analysis. It does not explicitly name alternative tools or state when-not-to-use conditions, but the scenario and prerequisites (config file or S3 environment variables) are clear enough for an agent to select it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

trigger_crawlA

手动触发一次爬取任务(可选持久化)

Args: platforms: 平台ID列表,如 ['zhihu', 'weibo'],不指定则使用所有平台 save_to_local: 是否保存到本地 output 目录,默认 False include_url: 是否包含URL链接,默认False(节省token)

Returns: JSON格式的任务状态信息,包含成功/失败平台列表和新闻数据

Examples: - trigger_crawl(platforms=['zhihu']) - trigger_crawl(save_to_local=True)

NameRequiredDescriptionDefault
platformsNo
include_urlNo
save_to_localNo

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does a good job: it reveals that this is a manual/mutating crawl action, that persistence is optional via save_to_local, that include_url=False saves tokens, and that the return is JSON task status with success/failure platform lists. It does not cover rate limits, duration, or whether the crawl may overwrite existing data, but it provides materially more than a bare mutation label.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-line summary, labeled Args with defaults/meaning, a Returns note, and two concrete examples. No redundant filler appears, and the key scoping behavior (default all platforms) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter tool with an output schema and clear examples, the description covers invocation, defaults, and return shape sufficiently. It could be even more complete by noting whether the crawl runs synchronously/asynchronously and how invalid platform IDs are handled, but nothing an agent strictly needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must document parameters, and it does: platforms is explained with domain examples and a default ('use all platforms'), save_to_local is tied to the output directory, and include_url is explained with a token-saving rationale. This adds real semantic meaning beyond the raw JSON schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource: '手动触发一次爬取任务' (manually trigger a crawl task), with optional persistence. This clearly identifies it as the direct crawl-trigger action and distinguishes it from the read/analysis tools among its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining default behavior (all platforms when platforms is unspecified) and providing two examples, but it never explicitly says when to choose this tool over alternatives. No exclusions or 'use X instead' guidance is given, though the manual-trigger wording makes the basic intent reasonably inferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 27 tool updatesv6.10.0
    • First observedaggregate_news
    • First observedanalyze_data_insights
    • First observedanalyze_sentiment
    • First observedanalyze_topic_trend
    • First observedcheck_version
    • First observedcompare_periods
    • First observedfind_related_news
    • First observedgenerate_summary_report
    • First observedget_channel_format_guide
    • First observedget_current_config
    • First observedget_latest_news
    • First observedget_latest_rss
    • First observedget_news_by_date
    • First observedget_notification_channels
    • First observedget_rss_feeds_status
    • First observedget_storage_status
    • First observedget_system_status
    • First observedget_trending_topics
    • First observedlist_available_dates
    • First observedread_article
    • First observedread_articles_batch
    • First observedresolve_date_range
    • First observedsearch_news
    • First observedsearch_rss
    • First observedsend_notification
    • First observedsync_from_remote
    • First observedtrigger_crawl

TDQS

A3.7/5.0

Scored across 27 tools

Disambiguation3/5

The tools have reasonably distinct purposes, but there is some overlap between search_news, search_rss, and get_news_by_date, as well as between get_latest_news and get_news_by_date. Also, analyze_topic_trend and analyze_data_insights both serve as umbrella analyzers, which could cause misselection despite distinct sub-modes.

Naming Consistency4/5

Most tool names follow a clear verb_noun pattern (get_, search_, analyze_, send_, etc.), with only minor deviations like resolve_date_range (verb_object) or check_version (verb_noun). The naming is generally consistent and intuitive.

Tool Count3/5

With 27 tools, the server covers a wide range of functionality (news retrieval, analysis, configuration, notifications, storage), which is somewhat heavy but justifiable given the broad scope. It is on the upper edge of the acceptable range, but not excessive.

Completeness4/5

The tool surface is quite comprehensive for a news monitoring and analysis server, covering retrieval, search, trend analysis, sentiment, aggregation, comparison, reporting, and notifications. Minor gaps include lack of direct article management or explicit data deletion, but these are not critical for the domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    A real-time hotspot monitoring and news aggregation assistant that provides AI-powered analysis of trending topics across multiple platforms via the Model Context Protocol. It enables users to track news and receive automated notifications through various services like Telegram, WeChat, and Slack.
    14
    GPL 3.0
  • A
    license
    A
    quality
    Not graded
    maintenance
    An AI-powered news and trend aggregator that tracks real-time hot topics and RSS feeds with personalized filtering and summaries. It enables users to monitor global trends and receive automated reports across multiple platforms including WeChat, Telegram, and Slack.
    27
    GPL 3.0
  • A
    license
    A
    quality
    D
    maintenance
    An aggregator for real-time hot topics and news from major social and financial platforms like Zhihu, Bilibili, and Wall Street News. It features an MCP server that allows AI models to fetch and analyze trending information for automated insights.
    17
    GPL 3.0