TrendRadar MCP Server
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
中文 | 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:
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.
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)
Software Niche - Plataforma de recomendación de software de código abierto
Comunidad LinuxDo - Lugar de encuentro para entusiastas de la tecnología
Semanario de Ruan Yifeng - Semanario influyente en el círculo tecnoló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.pyy\_\_main\_\_.py; el pipeline de filtrado de IA pasa a ser el módulofilter\_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_domainpara 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_urlpara 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_analysisydisplay.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 aguid > 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
Wpara modo ginés,Dmodo 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.txtdescribe 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 enconfig/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_windowyanalysis_windowya no son compatibles. Consulta las referencias al nuevo config.yaml.
Un cubriendo schedule : se añade
timeline.yamlpara 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 enpresets:, solo es necesario que la clave no se repita y pones el nombre de tu plantilla en la configuración deconfig.yaml.Configuración flexible en franja horaria : soporta distinción entre laborables/festivos, franjas que cruzan normes degradados y
onceper period en el período.Editor visual de configuración :
Nueva pestaña
timeline.yaml, estéticamente junto conconfig.yaml/frequency\_words.txt.Selección de tarjeta en modos preestablecidos: gentle clic para alternar, y sincronización automática con
schedule.presetde 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-mcpSoporte 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
🌐 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_webserverDirecció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
Nueva sección ¿Cómo se muestran los contenidos enviados?: personaliza el estilo y el contenido de los envíos
Nueva sección ¿Cuándo se me envía?: configura el período de envío
Nueva sección ¿Con qué frecuencia se ejecuta?: configura la frecuencia de ejecución automática
Nueva sección Enviar a múltiples grupos/dispositivos: envía simultáneamente a varios destinatarios
Optimización de las secciones de configuración: se añade uniformemente la indicación "Ubicación de la configuración"
Simplificación de las instrucciones de configuración de inicio rápido: los tres archivos principales se ven de un vistazo
Optimización de la sección Implementación con Docker: nuevas instrucciones de imagen, se recomienda la implementación con
git clone, reorganización de los métodos de implementació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 IASoporte 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
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
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*
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
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.)
Múltiples métodos de implementación
GitHub Actions: configure el secreto
SLACK_WEBHOOK_URLDocker: variable de entorno
SLACK_WEBHOOK_URLEjecució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
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
Múltiples métodos de implementación
GitHub Actions: configure el secreto
BARK_URLDocker: variable de entorno
BARK_URLEjecució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_urlenconfig.yamlno 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
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
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úmeropara establecer límites para palabras clave específicasControla 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 ActionsNuevo 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.pySe 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) ytext(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ónEl modo
textelimina automáticamente la sintaxis de Markdown, proporcionando un efecto de envío de texto planoVer 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.yamlActualizació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 arquitecturasSe 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.yamlpara habilitar el control de la ventana de tiempo de envíoLa actualización requiere actualizar tanto
main.pycomoconfig.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.yamlSi 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:
El problema de ejecución anómala causado por los caracteres de nueva línea CRLF en el script de shell de Docker
El problema lógico de que cuando
frequency_words.txtestá vacío, el envío de noticias también resultaba vacío
Después de la corrección, cuando elijas que
frequency_words.txtesté 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 ajustesOpció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
currentoincrementalpara 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 divididomain.pypara 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~)
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í!
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
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.txta continuación)
2025/06/16 - v1.0.0
Se añade un aviso de actualización de la nueva versión del proyecto, activado por defecto. Para desactivarlo, puede cambiar el valor
Truede "FEISHU_SHOW_VERSION_UPDATE": True aFalseenmain.py
2025/06/13+14
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)
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 +
Sintaxis de la palabra obligatoria:
"唐僧" o "猪八戒" deben aparecer simultáneamente en el título para que se incluya en las noticias enviadas
+唐僧
+猪八戒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
La página web y el mensaje de Feishu admiten el salto directo a la noticia detallada desde el teléfono
Optimización del efecto de visualización + 1
2025/05/26
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.yamlEnví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.txtque 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 | Ver archivo de configuración |
Cambio de modo de visualización |
| 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.txtvací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.txtcon lenguaje cotidiano, sin necesidad de aprender sintaxis de palabras claveProcesamiento 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 relevanciaRespaldo 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.methodadmite dos modos:keyword(predeterminado) yai; Timeline puede sobrescribir por franja horariaPersonalizació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_keyuna 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: truey el idioma de destino enconfig.yamlSoporte 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.txtConfiguración de modelo compartida: Comparte la configuración del modelo de la sección
aicon 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_keyuna 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 instanteCopiado con un clic: Pasa el cursor sobre el número de la noticia para copiar el título y el enlace
Atajos de teclado:
Wpara pantalla panorámica,Dpara 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) |
| El API Token creado en el paso anterior |
| Tu Cloudflare Account ID |
| El nombre del proyecto de Cloudflare Pages (por ejemplo, |
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 |
|
|
|
🚀 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.batpara instalar las dependencias con un clicLos usuarios de Mac pueden usar
bash setup-mac.shAntes de ejecutar, edita
config/config.yamlpara 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á reconocerlosSe 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:
Abre la app de WeCom → entra en el grupo de chat interno de destino
Haz clic en el botón "…" en la esquina superior derecha → selecciona "Mensajes"
Haz clic en "Añadir" → escribe "TrendRadar" como nombre
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:
Completa la configuración del Webhook del robot de WeCom anterior
Añade el Secret
WEWORK_MSG_TYPEcon el valortextSigue las imágenes a continuación para vincular WeChat personal
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:
textes texto plano,markdownes 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:
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.

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

En la interfaz de Robots del grupo, haz clic en Añadir robot.
En el cuadro de diálogo Añadir robot, busca y haz clic en Robot personalizado.

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.

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.

Configura la dirección de Webhook copiada en
FEISHU_WEBHOOK_URLen 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:
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"
Configurar el robot:
Configura el nombre del robot
Configuración de seguridad:
Palabra clave personalizada: Configura "热点"
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_URLen 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:
Crear el bot:
Busca
@BotFatheren 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
/newbotpara crear un bot nuevoConfigura 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)
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>/getUpdatesEn el JSON devuelto, busca el número en
"chat":{"id":número}
Método 2: Usar una herramienta de terceros
Busca
@userinfoboty envía/startObtén tu ID de usuario como Chat ID
Configurar en GitHub:
TELEGRAM_BOT_TOKEN: Completa el Bot Token obtenido en el paso 1TELEGRAM_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.htmlenconfig/config.yamlesté configurado comotrue: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_SERVERyEMAIL_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:
Inicia sesión en la versión web de QQ Mail → Configuración → Cuenta
Activa el servicio POP3/SMTP
Genera un código de autorización (16 caracteres alfabéticos)
EMAIL_PASSWORDdebe rellenarse con el código de autorización, no con la contraseña de QQ
Gmail:
Activa la verificación en dos pasos
Genera una contraseña específica de la aplicación
EMAIL_PASSWORDdebe rellenarse con la contraseña específica de la aplicación
163/126 Mail:
Inicia sesión en la versión web → Configuración → POP3/SMTP/IMAP
Activa el servicio SMTP
Configura el código de autorización del cliente
EMAIL_PASSWORDdebe 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.comEMAIL_SMTP_PORT: por ejemplo, 587 (TLS) o 465 (SSL)
Si hay varios destinatarios (ten en cuenta que deben separarse con comas en inglés):
EMAIL_TO="user1@example.com,user2@example.com,user3@example.com"
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:
Descarga la aplicación ntfy:
Android: Google Play / F-Droid
iOS: App Store
Escritorio: visita ntfy.sh
Suscríbete a un tema (elige un nombre difícil de adivinar):
建议格式:trendradar-{你的名字缩写}-{随机数字} 不能使用中文 ✅ 好例子:trendradar-zs-8492 ❌ 坏例子:news、alerts(太容易被猜到)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
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.dbConfigura 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) 🆓
Descarga la aplicación Bark:
iOS: App Store
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_URLde 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-serverConfigura TrendRadar:
BARK_URL: http://your-server-ip:8080/your_device_keyNotas:
✅ 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
Visita la página de API de Slack:
Si no has iniciado sesión, primero inicia sesión en tu espacio de trabajo de Slack
Elige el método de creación:
Haz clic en "From scratch" (crear desde cero)
Rellena la información de la aplicación:
App Name: introduce el nombre de la aplicación (como
TrendRadaroMonitoreo 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
Navega a Incoming Webhooks:
En el menú lateral, busca y haz clic en "Incoming Webhooks"
Activa la función:
Busca el interruptor "Activate Incoming Webhooks"
Cambia el interruptor de
OFFaONLa página se actualizará automáticamente mostrando las nuevas opciones de configuración
Paso 3: Generar la URL del Webhook
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"
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
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
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
Copia la URL:
Haz clic en el botón "Copy" a la derecha de la URL
O selecciona la URL manualmente y cópiala
Configúrala en TrendRadar:
GitHub Actions: añade la URL a
SLACK_WEBHOOK_URLen los Secret de GitHubPrueba local: rellena el campo
slack_webhook_urlenconfig/config.yamlDespliegue con Docker: añade la URL a la variable
SLACK_WEBHOOK_URLen el archivodocker/.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
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
Configura la plantilla:
{"content": "{content}"}Configuración de Secret de GitHub:
GENERIC_WEBHOOK_URL: URL del Webhook de DiscordGENERIC_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:
Entra en la página de Actions de tu proyecto
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
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 |
| Archivo de configuración principal: modo de notificación, ventana de tiempo, lista de plataformas, pesos de noticias, etc. |
| Archivo de palabras clave: configura las palabras que te interesan para filtrar el contenido de las notificaciones |
| Plantilla de prompt de IA: personaliza el rol del analista de IA y las dimensiones de análisis |
| 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 workflowFilosofí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) |
| Nombre del bucket (como |
| ID de clave de acceso (Access Key ID) |
| Clave de acceso (Secret Access Key) |
| Endpoint de la API S3 (para R2: |
Configuración opcional:
Name (Nombre) | Descripción del Secret (Valor) |
| Región (por defecto |
💡 Más opciones de configuración de almacenamiento: consulta ¿Dónde se guardan los datos?
Pasos detallados (obtención de credenciales):
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.
Crea un bucket:
Haz clic en
Descripción generalHaz clic en
Crear bucket(Create bucket) en la esquina superior derecha.Introduce un nombre (por ejemplo,
trendradar-data) y haz clic enCrear bucket.
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 enManage(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íficosy elegir tu bucket (comotrendradar-data).
Haz clic en
Crear token de APIe inmediatamente copia elAccess Key IDy elSecret Access Keyque 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 (comodeepseek,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 |
| Mostrar como máximo 10 noticias (nuevo en v3.2.0) |
Filtro global |
| Excluir globalmente contenido específico | Ver ejemplo a continuación | Filtrar en cualquier caso (nuevo en v3.5.0) |
Expresión regular |
| Modo de coincidencia precisa |
| Usar coincidencia con expresiones regulares (nuevo en v4.7.0) |
Nombre mostrado |
| Texto mostrado personalizado |
| 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)
特斯拉
马斯克
@5Funció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 |
| Coincide con palabras independientes, como |
No letras antes/después |
| Límite más flexible, adecuado para escenarios mixtos chino-inglés |
Coincidencia al inicio |
| 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 |
|
|
|
|
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 |
| Nº de puntos calientes ↓ → Posición de configuración ↑ | Seguir la tendencia de popularidad |
| 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=10Ejemplo 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ía | 📋 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 actual | 📰 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 incremental | 📈 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) ocurrent(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:
No hay nuevos puntos calientes que coincidan con tus palabras clave en ese período.
La configuración de palabras clave es demasiado estricta o demasiado amplia.
El número de plataformas monitoreadas es reducido.
Soluciones:
Solución 1: 👉 Optimizar la configuración de palabras clave - Ajusta la precisión de las palabras clave, añade o modifica palabras de monitoreo.
Solución 2: Cambiar el modo de envío - Usa el modo
currentodailypara recibir envíos programados.Solución 3: 👉 Añadir plataformas de monitoreo - Añade más plataformas de noticias para ampliar las fuentes de información.
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.1Pú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.1Público objetivo: Inversores, investigadores, periodistas, usuarios que necesitan un análisis profundo de tendencias.
Método de ajuste
Los tres números deben sumar 1.0
Aumenta el que sea más importante: Si te importa el ranking, aumenta
rank; si te importa la persistencia, aumentafrequency.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
[百度热搜] 🆕 ChatGPT-5 se lanza oficialmente [1] - 09时15分 (1 vez)
[今日头条] Las acciones del concepto de chips de IA se disparan [3] - [08时30分 ~ 10时45分] (3 veces)
━━━━━━━━━━━━━━━━━━━
📈 [2/3] 比亚迪 特斯拉 : 2 noticias
[微博] 🆕 比亚迪 bate el récord de ventas mensuales [2] - 10时20分 (1 vez)
[抖音] 特斯拉 baja precios en promoción [4] - [07时45分 ~ 09时15分] (2 veces)
━━━━━━━━━━━━━━━━━━━
📌 [3/3] A股 股市 : 1 noticia
[华尔街见闻] 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):
ChatGPT-5 se lanza oficialmente [1]
微博 (1 noticia):
比亚迪 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 |
| Servicio de envío de noticias | Captura programada de noticias, envío de notificaciones (obligatorio) |
| 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)
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 编排文件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.yamlConfiguració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.txtConfiguració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.yamlConfiguració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.txtPrompt 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.txtPrompt de traducción de IA
Baja
Personaliza la plantilla del prompt de traducción de IA.
config/ai_interests.txtFiltrado 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/.envInformació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.txtoai_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, ejecutadocker compose up -dpara reiniciar el contenedor y aplicar los cambios.⚙️ Mecanismo de anulación por variables de entorno (v3.0.5+)
Las variables de entorno del archivo
.envanulan la configuración correspondiente enconfig.yaml:Variable de entorno
Configuración correspondiente
Ejemplo de valor
Descripción
WEBSERVER_PORT-
8080Puerto del servidor web.
FEISHU_WEBHOOK_URLnotification.channels.feishu.webhook_urlhttps://...Webhook de Feishu (para varias cuentas, separar con
;).AI_ANALYSIS_ENABLEDai_analysis.enabledtrue/falseSi se habilita el análisis de IA (nuevo en v5.0.0).
AI_API_KEYai.api_keysk-xxx...Clave de API de IA (compartida por
ai_analysisyai_translation).AI_PROVIDERai.providerdeepseek/openai/geminiProveedor 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
.envy 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.
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 -dOpción B: Iniciar solo el servicio de envío de noticias
# 只启动 trendradar(定时抓取和推送) docker compose pull trendradar docker compose up -d trendradarOpció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
trendradarpara usar la función de envío de noticias.Solo necesitas iniciar
trendradar-mcpsi 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.
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.ymlCompilar 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 -dImágenes disponibles:
Nombre de la imagen | Uso | Descripción |
| Servicio de envío de noticias | Rastreo programado de noticias, envío de notificaciones. |
| 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:8080desde 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_PORTen 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
outputy 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 |
| Acceso directo desde el host | Implementación con Docker (visible en el host mediante el montaje de volumen). |
| Acceso desde la raíz | GitHub Pages (raíz del repositorio, Pages lo detecta automáticamente). |
| 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 --> sharedInicio 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-mcpIniciar 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/youtput/, 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-mcpConfigurar 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:
streamableHttpURL:
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 |
|
| Determina el momento y el contenido del envío; consulta Explicación detallada de los modos de envío. |
Forma de agrupar |
|
|
|
Resaltar lo importante |
|
| Las 5 noticias con mejor ranking se muestran en negrita para ver de un vistazo las más populares. |
Regla de ordenación |
|
|
|
Límite de cantidad |
|
| ¿Cuántas noticias como máximo por palabra clave? |
Orden de visualización |
| 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 |
| Agrupar por palabra clave |
| Me interesa "IA", quiero ver las noticias sobre IA en todas las plataformas. |
| Agrupar por plataforma |
| 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
- standaloneNota: una sección solo se muestra si cumple dos condiciones:
Está en la lista
region_order.El interruptor correspondiente en
display.regionsestá entrue.
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 |
|
| Agregación de noticias de tendencia que coinciden con las palabras clave. |
Nuevos temas destacados |
|
| 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 |
|
| 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 |
|
| Visualización completa del contenido de plataformas/RSS específicos, sin filtrado por palabras clave. |
Análisis de IA |
|
| 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 |
| BYD (10 noticias) → Tesla (3 noticias) | "Quien sea más popular va primero". |
| 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.standalonesolo 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 activadoinclude_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 |
| 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. |
| Monitoreo 24/7 | Envía cuando haya novedades durante todo el día, sin dividir en franjas horarias. |
| 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. |
| Trasnochador | Resumen de la tarde + resumen completo de la noche (22:00-01:00, cruza la medianoche). |
| Totalmente personalizado | Edita la sección |
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_windowyai_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 |
| Configuración predeterminada, se ejecuta en el minuto 0. |
Cada 30 minutos |
| Se ejecuta cada 30 minutos. |
Todos los días a las 8 a. m. |
| ⚠️ Escribe |
Cada media hora en horario laboral |
| Corresponde a las 8:00 - 22:00 hora de Beijing. |
Tres comidas al día |
| Corresponde a las 8:00, 14:00, 20:00 hora de Beijing. |
⚠️ Dos avisos importantes
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.
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
En tu repositorio de GitHub, busca el archivo
.github/workflows/crawler.yml.Haz clic en el botón ✏️ (Editar) en la esquina superior derecha.
Busca la línea
cron: "..."y reemplaza el contenido entre comillas con el "código" anterior.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/aaaDirección del grupo 2:
https://.../webhook/bbb
Al configurar, escribe:
https://.../webhook/aaa;https://.../webhook/bbb
Plataformas que admiten varias cuentas
平台 | 配置方法 | 注意事项 |
飞书/钉钉/企微 | 用 | 最简单,直接串起来就行 |
Bark (iOS) | 用 | 推送到多台 iPhone |
Telegram | Token 和 ChatID 都要用 | ⚠️ 注意顺序要对应:Token1 对应 ChatID1Token2 对应 ChatID2 |
ntfy | Topic 和 Token 都要用 | 如果某个Topic不需要Token,留空即可: |
常用配置示例 (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 / 本地运行 | 本地硬盘 | 存在项目目录下的 |
GitHub Actions | 云端存储 | 因为 GitHub Actions 运行完就会销毁环境,所以必须配置云存储(例如 Cloudflare R2)。 |
怎么配置云存储?(GitHub Actions 用户必看)
如果你是用 GitHub Actions 运行,你需要一个"云端硬盘"来存数据。例如使用 Cloudflare R2(因为有免费额度)。
在 GitHub Secrets 里添加这 5 个变量:
变量名 | 填什么 |
|
|
| 你的存储桶名字 |
| 你的 Access Key |
| 你的 Secret Key |
| 你的 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 会像一个专业的分析师,在推送每一批新闻时:
自动阅读:阅读所有匹配到的热点新闻
深度思考:分析原本孤立的新闻之间的关联
撰写报告:在推送消息的末尾,附上一份简短深刻的"洞察报告"
包含内容:热点趋势总结、舆论风向判断、跨平台关联分析、潜在影响评估等。
怎么开启 AI 分析?
最简单的方法是通过环境变量配置(推荐 GitHub Secrets 或 .env)。
必需的配置项:
变量名 | 填什么 | 说明 |
|
| 开启开关 |
|
| 你的 API Key |
|
| 模型标识(格式: |
支持的 AI 提供商(基于 LiteLLM,支持 100+ 提供商):
提供商 | AI_MODEL 填什么 | 说明 |
DeepSeek (推荐) |
| 性价比极高,适合高频分析 |
OpenAI |
| GPT-4o 系列 |
Google Gemini |
| Gemini 系列 |
自定义 API | 任意格式 | 配合 |
💡 新特性:现已基于 LiteLLM 统一接口,支持 100+ AI 提供商,配置更简单、错误处理更完善。
可选配置项:
变量名 | 默认值 | 说明 |
| (自动) | 自定义 API 地址(如 OneAPI、本地模型) |
|
| 采样温度(0-2,越高越随机) |
|
| 最大生成 token 数 |
|
| 请求超时时间(秒) |
|
| 失败重试次数 |
进阶玩法: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 文件夹中)
使用说明:
项目自带测试数据:
output目录默认包含 2025-12-21~2025-12-27 一周的热榜新闻数据,可用于快速体验 AI 功能查询限制:
✅ 只能查询已有日期范围内的数据(12月21-27日,共7天)
❌ 无法查询实时新闻或未来日期
获取最新数据:
测试数据仅供快速体验,建议自行部署项目获取实时数据
按照 快速开始 部署运行项目
等待至少 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 模式
启动 HTTP 服务:
# Windows start-http.bat # Mac/Linux ./start-http.sh配置 Cursor:
项目级配置(推荐): 在项目根目录创建
.cursor/mcp.json:{ "mcpServers": { "trendradar": { "url": "http://localhost:3333/mcp", "description": "TrendRadar 新闻热点聚合分析" } } }全局配置: 在用户目录创建
~/.cursor/mcp.json(同样内容)使用步骤:
保存配置文件后重启 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 连接:
使用步骤
启动 TrendRadar HTTP 服务:
# Windows start-http.bat # Mac/Linux ./start-http.sh启动 MCP Inspector:
npx @modelcontextprotocol/inspector在浏览器中连接:
访问:
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 脚本)
常见问题
检查步骤:
确认端口 3333 未被占用:
# Windows netstat -ano | findstr :3333 # Mac/Linux lsof -i :3333检查项目依赖是否安装:
# 重新运行安装脚本 # Windows: setup-windows.bat 或者 setup-windows-en.bat # Mac/Linux: ./setup-mac.sh查看详细错误日志:
uv run python -m mcp_server.server --transport http --port 3333尝试自定义端口:
uv run python -m mcp_server.server --transport http --port 33333
解决方案:
STDIO 模式:
确认 UV 路径正确(运行
which uv或where uv)确认项目路径正确且无中文字符
查看客户端错误日志
HTTP 模式:
确认服务已启动(访问
http://localhost:3333/mcp)检查防火墙设置
尝试使用 127.0.0.1 替代 localhost
通用检查:
重启客户端应用
查看 MCP 服务日志
使用 MCP Inspector 测试连接
可能原因:
数据不存在:
确认已运行过爬虫(有 output 目录数据)
检查查询日期范围是否有数据
查看 output 目录的可用日期
参数错误:
检查日期格式:
YYYY-MM-DD确认平台 ID 正确:
zhihu,weibo等查看工具文档中的参数说明
配置问题:
确认
config/config.yaml存在确认
config/frequency_words.txt存在检查配置文件格式是否正确
📚 项目相关
4 篇文章:
AI 开发:
如果你有小众需求,完全可以基于我的项目自行开发,零编程基础的也可以试试
我所有的开源项目或多或少都使用了自己写的AI辅助软件来提升开发效率,这款工具已开源
核心功能:迅速筛选项目代码喂给AI,你只需要补充个人需求即可
其余项目
📍 毛主席足迹地图 - 交互式动态展示1893-1976年完整轨迹。欢迎诸位同志贡献数据
哔哩哔哩(bilibili)评论区数据可视化分析软件
📄 许可证
GPL-3.0 License
Available Tools
27 toolsaggregate_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)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No | ||
| similarity_threshold | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| topic | No | ||
| date_range | No | ||
| insight_type | No | platform_compare | |
| min_frequency | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"})
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No | ||
| sort_by_weight | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| date_range | No | ||
| granularity | No | day | |
| time_window | No | ||
| analysis_type | No | trend | |
| lookahead_hours | No | ||
| spike_threshold | No | ||
| confidence_threshold | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| proxy_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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="人工智能" )
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| topic | No | ||
| period1 | Yes | ||
| period2 | Yes | ||
| platforms | No | ||
| compare_type | No | overview |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式内容
| Name | Required | Description | Default |
|---|---|---|---|
| date_range | No | ||
| report_type | No | daily |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 策略
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的配置信息
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的新闻列表
数据展示建议
默认展示全部返回数据,除非用户明确要求总结
用户说"总结"或"挑重点"时才进行筛选
用户问"为什么只显示部分"说明需要完整数据
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| include_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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'])
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| feeds | No | ||
| limit | No | ||
| include_summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的新闻列表,包含标题、平台、排名等信息
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| platforms | No | ||
| date_range | No | ||
| include_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 源状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的存储状态信息,包含本地/远程存储状态和拉取配置
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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格式的系统状态信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
get_trending_topicsA
获取热点话题统计
Args: top_n: 返回TOP N话题,默认10 mode: 时间模式 - "daily": 当日累计数据统计 - "current": 最新一批数据统计(默认) extract_mode: 提取模式 - "keywords": 统计预设关注词(基于 config/frequency_words.txt,默认) - "auto_extract": 自动从新闻标题提取高频词(无需预设,自动发现热点)
Returns: JSON格式的话题频率统计列表
Examples: - 使用预设关注词: get_trending_topics(mode="current") - 自动提取热点: get_trending_topics(extract_mode="auto_extract", top_n=20)
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | current | |
| top_n | No | ||
| extract_mode | No | keywords |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 the two extraction modes, references the config/frequency_words.txt source, and states that the return is a JSON frequency list. It does not discuss side effects, but for a getter-style statistics tool the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. Every sentence adds value, the main purpose is front-loaded, and the examples are concise illustrations rather than repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no annotations, the description is complete: it defines all parameters, their defaults, mode semantics, extraction sources, return format, and usage examples. Nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions at all, yet the description documents every parameter: top_n with its default, mode with both allowed values and their meanings, and extract_mode with both options plus the config file dependency. Examples reinforce the parameter combinations, fully compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving hot-topic frequency statistics, and the examples make the purpose concrete. It does not explicitly distinguish itself from siblings such as analyze_topic_trend, so it misses the top score, but the verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining the mode options and showing concrete examples for preset keywords and auto extraction. It does not explicitly state when not to use this tool or name alternatives, so the guidance is strong but not fully exclusionary.
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")
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | both |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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,自动去除广告、导航栏等噪音内容。 适合用于:阅读新闻正文、获取文章详情、分析文章内容。
典型使用流程:
先用 search_news(include_url=True) 搜索新闻获取链接
再用 read_article(url=链接) 读取正文内容
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 秒(内置速率控制) - 部分付费墙/登录墙页面可能无法完整获取
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 秒以遵守速率限制。
典型使用流程:
先用 search_news(include_url=True) 搜索新闻获取多个链接
再用 read_articles_batch(urls=[...]) 批量读取正文
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 秒) - 单篇失败不影响其他篇的读取
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| timeout | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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 模型获得一致的日期范围。
推荐使用流程:
用户说"分析AI本周的情感倾向"
AI 调用 resolve_date_range("本周") → 获取精确日期范围
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"})| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"})
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| sort_by | No | relevance | |
| platforms | No | ||
| rss_limit | No | ||
| threshold | No | ||
| date_range | No | ||
| include_rss | No | ||
| include_url | No | ||
| search_mode | No | keyword |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| feeds | No | ||
| limit | No | ||
| keyword | Yes | ||
| include_summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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"])
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | TrendRadar 通知 | |
| message | Yes | ||
| channels | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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: 访问密钥
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| platforms | No | ||
| include_url | No | ||
| save_to_local | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
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.
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.
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.
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.
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.
27 tool updates
v6.10.0- First observed
aggregate_news - First observed
analyze_data_insights - First observed
analyze_sentiment - First observed
analyze_topic_trend - First observed
check_version - First observed
compare_periods - First observed
find_related_news - First observed
generate_summary_report - First observed
get_channel_format_guide - First observed
get_current_config - First observed
get_latest_news - First observed
get_latest_rss - First observed
get_news_by_date - First observed
get_notification_channels - First observed
get_rss_feeds_status - First observed
get_storage_status - First observed
get_system_status - First observed
get_trending_topics - First observed
list_available_dates - First observed
read_article - First observed
read_articles_batch - First observed
resolve_date_range - First observed
search_news - First observed
search_rss - First observed
send_notification - First observed
sync_from_remote - First observed
trigger_crawl
TDQS
Scored across 27 tools
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.
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.
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.
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
Related MCP Connectors
The only News based AI MCP your agents will ever need — custom categories, global regions, and time-scoped results in one tool. We use multi-vector & sparse-hybrid search to search through thousands of articles across the world to find the exact news you're looking for.
Narrative intelligence from thousands of curated media sources, delivered to AI through MCP.
MCP server: AI-agent access to Chinese social & trend signals — Douyin, Weibo, Xiaohongshu/RedNote,
Free read-only Chinese AI news MCP: verified events, reports, products. No API key.
611
Related MCP Servers
- AlicenseAqualityDmaintenanceA 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.14GPL 3.0
- AlicenseAqualityNot gradedmaintenanceAn 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.27GPL 3.0
- AlicenseAqualityDmaintenanceAn 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.17GPL 3.0
- AlicenseAqualityCmaintenanceMCP server for real-time trending news aggregation, AI-powered analysis and filtering, and multi-channel push notifications.27GPL 3.0


