PM Copilot

Triangula tickets de soporte al cliente y solicitudes de funciones para generar planes de producto priorizados con puntuación de convergencia y limpieza de PII.

Documentación

PM Copilot

Un servidor MCP que triangula tickets de soporte al cliente, solicitudes de funciones y conversaciones de agentes de soporte con IA para ayudar a los PMs a decidir qué construir a continuación.

TypeScript License: MIT MCP SDK Node.js


Resultados reales: Analizó 3,353 señales en una ventana de 30 días: 1,678 tickets de soporte, 276 solicitudes de funciones y 1,399 conversaciones de agentes de soporte con IA en 4 productos. Prioridad principal: Reservas y Programación — 285 tickets + 74 solicitudes de funciones + 347 chats apuntando al mismo problema, con el agente de IA respondiendo con baja confianza en el 48% de esos chats.

Los 1,399 chats son el punto clave. Ninguno de ellos era visible para el análisis antes de v1.4.0, y representan el 83% del volumen del canal de tickets.

Lea la historia completa: Construí un servidor MCP que cambió cómo priorizo productos — por qué lo construí, cómo funcionan las señales convergentes en la práctica y lo que aprendí construyendo con Claude Code.


Qué Hace Esto Diferente

  • Triangulación de señales. Compara tickets de soporte con solicitudes de funciones para encontrar temas convergentes, y luego los puntúa con una fórmula ponderada que da a las señales convergentes un impulso de prioridad 2x.
  • El punto ciego de la desviación. Un agente de soporte con IA responde preguntas que nunca se convierten en tickets, por lo que la priorización basada en tickets subestima cada tema que el bot maneja — y la brecha se amplía a medida que el bot mejora. Las conversaciones de Chatbase se integran como una tercera clase de señal, con un self_serve_failure_rate por tema que muestra dónde falla la autoservicio.
  • Componibilidad. Funciona junto a otros servidores MCP. Pase datos de churn de Metabase o tendencias de tráfico de Google Analytics a generate_product_plan mediante kpi_context, y la metodología ajusta las prioridades en consecuencia.
  • Metodología PM integrada. Puntuación basada en opinión, construida sobre 7 años de gestión de productos en 9 productos y más de 1M de usuarios. Es un proceso real de toma de decisiones expuesto como recurso MCP, no un marco genérico.
  • Eliminación de PII. Los datos del cliente nunca llegan al LLM sin filtrar. Los números de seguro social, tarjetas de crédito (validadas por Luhn), correos electrónicos y números de teléfono se redactan antes del análisis. Las respuestas del agente se filtran de las citas.

Arquitectura

graph TD
    A[Claude Desktop / Code] -->|stdio| B[pm-copilot]
    A -->|stdio| C[Metabase MCP]
    A -->|stdio| D[Google Analytics MCP]
    B -->|Reactive| E[HelpScout: tickets]
    B -->|Proactive| F[ProductLift: feature requests]
    B -->|Deflected| I[Chatbase: AI agent chats]
    C -->|Quantitative| G[Conversion, Churn, Revenue]
    D -->|Acquisition| H[Traffic, Channels, Trends]
    B -.->|kpi_context| A

Claude orquesta múltiples servidores MCP. PM Copilot maneja las señales cualitativas del cliente. Otros servidores proporcionan métricas comerciales cuantitativas. El parámetro kpi_context es el punto de integración — no se requieren integraciones punto a punto.

Inicio Rápido

git clone https://github.com/dkships/pm-copilot.git
cd pm-copilot
npm install
cp .env.example .env   # Edit with your credentials
npm run build

Credenciales

HelpScout es obligatorio. ProductLift y Chatbase son opcionales — configure uno, ambos o ninguno, y el análisis se adapta.

VariableObligatorioDescripción
HELPSCOUT_APP_IDID de aplicación OAuth de https://secure.helpscout.net/apps/custom/
HELPSCOUT_APP_SECRETSecreto de aplicación OAuth
PRODUCTLIFT_PORTALSNoMulti-portal: name|url|key,name2|url2|key2
PRODUCTLIFT_PORTAL_URLNoURL de portal único
PRODUCTLIFT_API_KEYNoToken Bearer de portal único
PRODUCTLIFT_PORTAL_NAMENoNombre mostrado del portal (predeterminado: default)
CHATBASE_API_KEYNoClave secreta a nivel de cuenta de Chatbase → Configuración → Claves API
CHATBASE_AGENTSNoMulti-agente: name|agentId,name2|agentId2
CHATBASE_AGENT_IDNoID de agente único
CHATBASE_AGENT_NAMENoNombre mostrado del agente único (predeterminado: default)

El acceso a la API de Chatbase requiere un plan Chatbase Standard o superior. En un plan inferior, la API devuelve 403 y la señal de desviación se reporta como una advertencia en lugar de fallar todo el análisis. Un agente por producto es la forma útil — los agentes le dan atribución a nivel de producto que un buzón de soporte compartido no tiene.

Claude Desktop

Agregue a ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "pm-copilot": {
      "command": "node",
      "args": ["/absolute/path/to/pm-copilot/dist/index.js"]
    }
  }
}

Claude Code

claude mcp add pm-copilot -- node /absolute/path/to/pm-copilot/dist/index.js

O use el .mcp.json ya en la raíz del proyecto — Claude Code lo recoge automáticamente.

Herramientas

synthesize_feedback

Cruza referencias de tickets de HelpScout, solicitudes de funciones de ProductLift y conversaciones de Chatbase, y devuelve análisis con temas coincidentes y puntuaciones de prioridad.

ParámetroTipoPredeterminadoDescripción
timeframe_daysnúmero30Días a mirar hacia atrás (1-90)
top_voted_limitnúmero50Solicitudes más votadas por portal; las solicitudes recientes en el período de tiempo siempre se incluyen al inicio
mailbox_idstringFiltro de buzón de HelpScout (ID crudo)
mailbox_namestringNombre del buzón de HelpScout (insensible a mayúsculas); se resuelve automáticamente a un ID. Ejecute list_sources para ver nombres
portal_namestringFiltro de portal de ProductLift
agent_namestringFiltro de agente de Chatbase. Ejecute list_sources para ver nombres
source_filterstringFiltro de fuente de conversación de Chatbase, separado por comas para múltiples, ej. Widget or Iframe o WhatsApp,API. Insensible a mayúsculas. Ejecute list_sources para los valores válidos
detail_levelstring"summary""summary", "standard", o "full". El tamaño de salida escala con el volumen de datos — aproximadamente 20KB / 100KB / 600KB

Devuelve temas ordenados por puntuación de prioridad, cada uno con recuentos reactivo/proactivo, indicador de convergencia, resúmenes de evidencia y citas representativas de clientes.

generate_product_plan

Construye un plan de producto priorizado con evidencia y citas de clientes. Acepta métricas comerciales externas mediante kpi_context.

ParámetroTipoPredeterminadoDescripción
timeframe_daysnúmero30Días a mirar hacia atrás (1-90)
top_voted_limitnúmero50Solicitudes más votadas por portal; las solicitudes recientes en el período de tiempo siempre se incluyen al inicio
mailbox_idstringFiltro de buzón de HelpScout (ID crudo)
mailbox_namestringNombre del buzón de HelpScout (insensible a mayúsculas); se resuelve automáticamente a un ID. Ejecute list_sources para ver nombres
portal_namestringFiltro de portal de ProductLift
agent_namestringFiltro de agente de Chatbase. Ejecute list_sources para ver nombres
source_filterstringFiltro de fuente de conversación de Chatbase, separado por comas para múltiples, ej. Widget or Iframe o WhatsApp,API. Insensible a mayúsculas. Ejecute list_sources para los valores válidos
kpi_contextstringMétricas comerciales de otros servidores MCP
max_prioritiesnúmero5Número de prioridades a devolver (1-10)
preview_onlybooleanfalseModo auditoría: mostrar qué datos se enviarían
detail_levelstring"summary""summary", "standard", o "full". El tamaño de salida escala con el volumen de datos — para un buzón de 30 días, aproximadamente 5KB / 21KB / 375KB
formatstring"json""json" (estructurado, componible) o "markdown" (informe de producto listo para leer)

get_feature_requests

Acceso a datos crudos de ProductLift para explorar solicitudes de funciones directamente. Cada solicitud incluye su url público.

ParámetroTipoPredeterminadoDescripción
portal_namestringFiltrar a un portal específico
include_commentsbooleantrueIncluir comentarios en cada solicitud
statusstringFiltrar a solicitudes con este estado (insensible a mayúsculas), ej. open, planned, completed

list_sources

Lista las fuentes de datos a las que el servidor está conectado — buzones de HelpScout (id + nombre), portales de ProductLift (nombre + url) y agentes de Chatbase (nombre + id) — para que pueda descubrir los nombres para pasar a mailbox_name / portal_name / agent_name. Cuando Chatbase está configurado, también devuelve chatbase_conversation_sources, los valores que source_filter acepta (una lista fija de la documentación de Chatbase, no consultada por cuenta). Solo lectura; nunca devuelve claves API o datos de clientes. No toma parámetros.

Clases de señales

Tres fuentes, tres cosas diferentes que le dicen. Solo las primeras dos alimentan la regla de convergencia.

ClaseFuenteQué significaAlimenta
ReactivaTickets de HelpScoutAlgo está rotoFrecuencia, severidad, convergencia
ProactivaSolicitudes de ProductLiftAlgo se deseaFrecuencia, impulso de votos, convergencia
DesviadaConversaciones de ChatbaseAlgo fue preguntado, y el autoservicio lo manejó o noSolo frecuencia

Las señales desviadas cuentan para la frecuencia y llevan dos campos de evidencia por tema, pero no entran en los términos de severidad o impulso de votos y no cambian el impulso de convergencia 2x. La fórmula no cambia desde v2.1:

  • deflected_count — conversaciones que coinciden con el tema
  • self_serve_failure_rate — proporción de esas conversaciones donde la confianza más baja de respuesta del agente estuvo por debajo de 0.5
  • mean_answer_confidence — media de esa misma puntuación

Un tema con alto deflected_count y un alto self_serve_failure_rate es uno que los clientes siguen preguntando y que el autoservicio no resuelve. Chatbase no documenta qué mide su campo min_score, por lo que se reporta como evidencia para que el LLM la pese en lugar de integrarse en la puntuación de prioridad.

Las conversaciones llegan de varios canales (widget, WhatsApp, Messenger, API, …). El análisis informa un recuento chatbase_sources por canal, y el parámetro source_filter limita una ejecución a uno o más canales (separados por comas) — el filtro se aplica en el lado del servidor por Chatbase. Una advertencia: los recuentos pueden incluir canales que el filtro no cubre, como Playground o unknown (Chatbase omitió la fuente). Un valor de filtro fuera de la lista conocida se pasa con una advertencia en lugar de rechazarse, ya que cero coincidencias usualmente significa que el valor es incorrecto, no que el canal se silenció.

Chatbase es opcional. Sin CHATBASE_API_KEY configurado, los campos de desviación simplemente están ausentes y el análisis se comporta exactamente como antes.

Salida de ejemplo

Una respuesta synthesize_feedback recortada en el nivel de detalle summary predeterminado. Los valores son ilustrativos; note la eliminación de PII aplicada a la cita del cliente.

{
  "timeframe_days": 30,
  "detail_level": "summary",
  "portal_name": "all",
  "fetched_at": "2026-06-01T16:00:00.000Z",
  "pii_scrubbing_applied": true,
  "pii_categories_redacted": ["email", "phone", "credit_card"],
  "analysis": {
    "total_data_points": 612,
    "reactive_count": 548,
    "proactive_count": 64,
    "deflected_count": 312,
    "chatbase_sources": {
      "Widget or Iframe": 284,
      "WhatsApp": 23,
      "API": 5
    },
    "themes": [
      {
        "theme_id": "booking-scheduling",
        "label": "Booking & Scheduling",
        "category": "core",
        "priority_score": 87.1,
        "convergent": true,
        "signal_type": "convergent",
        "reactive_count": 211,
        "proactive_count": 19,
        "deflected_count": 96,
        "self_serve_failure_rate": 0.48,
        "mean_answer_confidence": 0.53,
        "evidence_summary": "326 signals (211 support tickets, 19 feature requests, 96 AI chat conversations). Convergent — appears in both support and feature requests (2x priority boost). The AI agent answered with low confidence in 48% of those chats — customers ask about this and self-serve often does not resolve it.",
        "representative_quotes": [
          "[Support ticket] \"Double-booked slots again after the timezone change — reach me at [EMAIL REDACTED]\"",
          "[Feature request, 47 votes] \"Let me block buffer time between meetings\"",
          "[AI chat, answer confidence 0.31] \"how do i stop people booking on weekends\""
        ]
      },
      {
        "theme_id": "list-management",
        "label": "List & Contact Management",
        "category": "audience",
        "priority_score": 41.7,
        "convergent": false,
        "signal_type": "deflected",
        "reactive_count": 0,
        "proactive_count": 0,
        "deflected_count": 58,
        "self_serve_failure_rate": 0.58,
        "mean_answer_confidence": 0.5,
        "evidence_summary": "58 signals (58 AI chat conversations). The AI agent answered with low confidence in 58% of those chats — customers ask about this and self-serve often does not resolve it.",
        "representative_quotes": [
          "[AI chat, answer confidence 0.22] \"how many contacts does pro allow\""
        ]
      }
    ],
    "emerging_themes": [
      { "pattern": "csv export", "frequency": 12 }
    ],
    "unmatched_count": 38
  }
}

Componibilidad en Acción

PM Copilot está diseñado para trabajar junto a otros servidores MCP. Aquí hay un ejemplo práctico que muestra cómo una anulación kpi_context cambia la clasificación. Los números son ilustrativos.

Paso 1: El PM hace una sola pregunta

Extraiga nuestros datos de churn y finalización de reservas, luego use pm-copilot para crear un plan de producto usando todo ese contexto.

Paso 2: pm-copilot analiza las señales y devuelve las prioridades principales

#TemaPuntuaciónTicketsSolicitudes de funcionesChatsFalla de autoservicioSeñal
1Facturación y Pagos91.12,3362024055%Convergente
2Reservas y Programación87.16827431045%Convergente
3Cuenta y Licencias69.71,955818038%Convergente
4Equipo y Colaboración64.41,875196050%Convergente
5Marca Blanca y Marca50.292309542%Convergente

Paso 3: Métricas comerciales de paneles llegan como kpi_context

Product A: booking completion rate dropped from 74% to 66% over last
30 days. Monthly churn increased from 3.1% to 4.2%. Organic traffic
up 22% MoM. Product B: document completion rate steady at 81%.
Churn flat at 2.8%.

Paso 4: Claude sintetiza ambos y anula la fórmula

Las puntuaciones dicen que Facturación y Pagos es #1. Pero la metodología dice que los datos de churn anulan la fórmula. Con la finalización de reservas del Producto A cayendo 8 puntos y el churn disparándose un 35%, Reservas y Programación se convierte en el verdadero #1 — es el producto principal rompiéndose.

El Producto B se desprioriza (métricas estables, sin fuego). El crecimiento orgánico del 22% del tráfico del Producto A eleva Marca Blanca y Marca como una jugada de crecimiento.

El servidor proporciona la clasificación de señales. El contexto de KPI proporciona el juicio de anulación. Claude sintetiza ambos.

Metodología

PM Copilot expone un recurso pm-copilot://methodology — el marco de planificación de productos de David Kelly, construido a lo largo de 7 años lanzando 9 productos a más de 1M de usuarios. Principios clave:

  • La regla del 5%. Completas alrededor del 5% de lo que los clientes piden cada mes. El marco identifica qué 5% importa más.
  • Las señales convergentes siempre ganan. El mismo tema en tickets de soporte y solicitudes de funciones es la señal de mayor confianza.
  • Reactivo > proactivo. Lo que está roto impulsa la deserción. Puedes sobrevivir sin tener una función; no puedes sobrevivir a errores.
  • Las métricas de negocio anulan la fórmula. El aumento de la deserción, la caída de la conversión o el impacto en los ingresos pueden cambiarlo todo.

La metodología está versionada (v2.1) y se sirve como contenido markdown a través del protocolo de recursos MCP. Cada respuesta de generate_product_plan enlaza a ella (methodology_resource) y, cuando se proporciona kpi_context, instruye a Claude para aplicarla — si realmente se lee depende de que el cliente MCP exponga los recursos.

Evaluación

La fórmula de puntuación solo importa si la coincidencia de temas subyacente es correcta. npm run eval mide eso.

Por qué coincidencia por palabras clave

Los temas se emparejan con listas de palabras clave — palabras clave de varias palabras como subcadenas, palabras individuales en un límite de palabra con un sufijo plural regular opcional — no con embeddings ni un clasificador LLM. Es una compensación deliberada:

  • El texto del cliente nunca sale del servidor hacia una API de embeddings o clasificación de terceros. Las garantías de PII a continuación solo se mantienen porque nada en la ruta de coincidencia hace una llamada de red.
  • La misma entrada siempre produce los mismos temas, por lo que una clasificación de prioridad puede auditarse y explicarse. Un clasificador LLM reorganizaría las clasificaciones entre ejecuciones.
  • Sin costo de tokens ni latencia por punto de datos, lo que permite que un análisis de 2,000 señales termine en menos de un minuto.

El costo es el recuerdo. Las listas de palabras clave pierden paráfrasis, y las pierden de manera desigual entre productos. En datos de chat en vivo retenidos, un tercio de las conversaciones aún no coincide con ningún tema. Eso es lo que la evaluación existe para cuantificar, y por qué el número se publica en lugar de ocultarse.

Ejecutarlo

npm run build && npm run eval
npm run eval -- --failures        # every miss and false positive
npm run eval -- --json           # machine-readable report
npm run eval -- --min-f1 0.90    # non-zero exit below threshold, for CI

La coincidencia es de múltiples etiquetas — una señal puede pertenecer a varios temas — por lo que el informe da precisión, recuerdo y F1 por tema, más dos tasas que importan más que los promedios: miss rate (se esperaba un tema, no coincidió con nada) y false alarm rate (no se esperaba nada, coincidió con algo).

Qué encontró la primera ejecución

El primer trabajo de la evaluación fue auditar la configuración v2, y encontró cinco defectos reales:

  • La cobertura de plurales era inconsistente. tier se listaba sin tiers, y las palabras clave individuales coincidían en un límite de palabra simple, por lo que "los niveles" no coincidía con nada. En datos de chat en vivo, este era el costoso — un aviso recurrente de widget, "¿cuáles son sus planes y precios?", no coincidía con ningún tema, porque plan pierde "planes" y pricing pierde "precios".
  • team se activaba con "equipo fundador" y "equipo de TI" — la mitad de los falsos positivos en el fixture.
  • plan etiquetaba "planeo lanzar la próxima semana" como Cuenta y Licencias.
  • upgrade estaba tanto en Facturación y Pago como en Cuenta y Licencias, por lo que un ticket de API que mencionaba una actualización aterrizaba en ambos.
  • Las palabras clave de varias palabras son subcadenas exactas, por lo que cant login perdía "no puedo iniciar sesión" y outlook calendar perdía "¿esto funciona con outlook?".

Los cinco están corregidos en v3: las palabras clave individuales ahora coinciden con un sufijo plural regular opcional, las palabras clave demasiado genéricas se acotaron (teammy team / team member / teams), las palabras clave duplicadas se asignaron a un solo tema, y se agregaron las variantes faltantes. Dos nuevos temas surgieron de conversaciones reales sin coincidencia — Sorteos y Concursos y Gestión de Listas y Contactos — para los cuales la configuración no tenía vocabulario en absoluto.

Línea base

Dos números, porque miden cosas diferentes.

Contra el fixture confirmado (82 ejemplos etiquetados a mano):

configprecisiónrecuerdoF1tasa de fallos
v288.7%68.8%77.5%25.0%
v395.8%96.8%96.3%2.6%

Trátalo con sospecha. La configuración se iteró contra este fixture, por lo que la cifra de v3 es dentro de la muestra y se halaga a sí misma. Es una puerta de regresión — te dice que un cambio rompió algo, no qué tan bien funciona la coincidencia.

El número que significa algo son datos reales retenidos. 1,100 conversaciones de chat en cuatro productos, de una ventana de 30 días antes de la de la que se derivaron los nuevos temas:

productoconversacionesv2 sin coincidenciav3 sin coincidenciacambio
Producto A43520.5%19.3%−1.1pp
Producto B46458.4%48.5%−9.9pp
Producto C13525.9%23.7%−2.2pp
Producto D6666.7%34.8%−31.8pp
todos1,10039.9%33.1%−6.8pp

Las ganancias llegan donde la teoría decía: los productos cuyo vocabulario la configuración nunca cubrió. Un tercio de las conversaciones aún no coincide con nada, así que queda mucho por hacer.

El registro resultó importar menos que la cobertura del producto. El chat del Producto A está mejor emparejado que los tickets, por lo que la redacción del chat por sí sola no es el problema — el vocabulario faltante del producto lo es, y los agentes de chat por producto exponen eso donde un buzón de soporte compartido lo promedia.

Limitaciones conocidas

  • Los avisos de widget predefinidos inflan los conteos. Botones preestablecidos como "Entré en un sorteo — ¿cómo sé si gané?" se repiten textualmente docenas de veces. No se deduplican, y eso es deliberado: veinte personas haciendo clic en un preestablecido son veinte personas con esa pregunta. Significa que el volumen de un tema con un preestablecido popular no es comparable al de uno sin él.
  • La coincidencia es solo en inglés. Los datos en vivo incluyen conversaciones en alemán, español e italiano, y todas aterrizan en unmatched.
  • Los plurales irregulares aún necesitan listarse. La regla de sufijos cubre plan/plans, no entry/entries.

Para un número de tus propios datos, exporta señales a un JSONL local con la forma del fixture y pasa --fixture ./local/real.jsonl. Los fixtures reales contienen texto de clientes — mantenlos fuera de git.

Seguridad

Los datos de los clientes fluyen a través de PM Copilot en su camino hacia Claude. Todo el texto se limpia antes de entrar en el pipeline de análisis o salir del servidor.

Limpieza de PII

CategoríaMétodoReemplazo
SSNCoincidencia de patrón (XXX-XX-XXXX)[SSN REDACTED]
Tarjetas de créditoSecuencias de 13-19 dígitos + validación Luhn[CC REDACTED]
Direcciones de correo electrónicoPatrón de correo estándar[EMAIL REDACTED]
Números de teléfonoFormatos de EE. UU. (+1, paréntesis, guiones, puntos)[PHONE REDACTED]
Campo de correo del clienteSiempre redactado[REDACTED]

Lo que excluimos por completo

DatosPor qué
Respuestas de agentes/administradoresSolo importa la voz del cliente; las respuestas de agentes podrían filtrar procesos internos
Notas internas de HelpScoutPueden contener credenciales, soluciones alternativas, discusiones internas
AdjuntosPodrían contener capturas de pantalla con PII, facturas, documentos médicos
Identidades de votantesLos conteos de votos son suficientes; la identidad individual no agrega valor de PM
Nombres de comentaristasEl rol (admin vs cliente) es todo lo que el análisis necesita
Turnos de asistente de ChatbaseSolo se analizan las propias palabras del cliente
Envíos de formularios de leads de ChatbaseCapturan nombres, correos y números de teléfono, y no tienen valor de PM
Identificadores de usuario final de ChatbaseuserId reduce la identidad entre conversaciones
País por conversación de ChatbaseLa geografía no agrega nada al análisis de temas y reduce la identidad

Nota sobre el chat como fuente de datos

Un widget de chat acepta texto libre ilimitado, por lo que es la superficie de PII más amplia de las tres fuentes — las personas pegan números de pedido, direcciones y claves de licencia en una caja de chat de una manera que no hacen en una publicación de hoja de ruta. Esto no es hipotético: en una ejecución en vivo de 30 días, agregar la fuente de Chatbase fue lo que primero hizo que credit_card apareciera en pii_categories_redacted. Los tickets y publicaciones de hoja de ruta en la misma ventana produjeron solo correos y números de teléfono.

Dos cosas lo mantienen contenido: solo se leen los turnos de role: "user", y cada turno pasa por el mismo limpiador que las otras fuentes antes de entrar en el análisis.

La atribución de mensajes de Chatbase es estructurada, lo que la convierte en la fuente de voz del cliente más limpia de las tres. La ruta de HelpScout tiene que adivinar el texto del agente con heurísticas de frases porque una vista previa de conversación puede ser de cualquier lado del intercambio; aquí role lo dice directamente, por lo que se omiten las heurísticas.

Controles de auditoría

  • preview_only: true en generate_product_plan muestra qué datos se enviarían sin obtenerlos
  • Cada respuesta incluye metadatos de pii_scrubbing_applied y pii_categories_redacted
  • Las categorías de datos se registran en stderr en cada llamada (solo categorías, nunca contenido)

Desarrollo

npm install          # Install dependencies
npm run build        # Compile TypeScript
npm run dev          # Watch mode
npm start            # Run the server
npm test             # Run the test suite
npm run eval         # Theme-matching eval (see Evaluation)

Pruebas locales

Llama a una herramienta de forma aislada sin reiniciar tu cliente MCP — útil para iterar sobre cambios y para verificar tamaños de respuesta:

npm run build
npm run tool -- --list
npm run tool -- list_sources '{}'
npm run tool -- get_feature_requests '{"portal_name":"<your-portal>","status":"open"}'

El ejecutor imprime el tamaño en bytes de cada respuesta. La salida puede incluir tus nombres/URLs de fuentes configuradas (y texto de cliente con PII limpiada) — redacta antes de compartir.

Configuración de temas

themes.config.json en la raíz del proyecto define qué temas buscar. Edita sin reconstruir — se carga en tiempo de ejecución.

Incluye 18 temas basados en datos en 12 categorías. Agrega los tuyos añadiendo al array de themes. Los puntos de datos sin coincidencia se analizan para patrones emergentes usando detección de frecuencia de bigramas/trigramas.

Después de editar, ejecuta npm run eval — informa precisión y recuerdo por tema y marca palabras clave que se activan en ejemplos de otro tema, que es como se detectan las demasiado genéricas.

Fórmula de puntuación

priority = (frequency × 0.35 + severity × 0.35 + vote_momentum × 0.30) × convergence_boost
  • Frecuencia (0.35): Conteo de puntos de datos, normalizado entre temas — incluye señales desviadas
  • Severidad (0.35): Solo señales reactivas — conteo de hilos (total, incluyendo respuestas de agentes), recencia (decaimiento de vida media de 7 días), aumentos de etiquetas
  • Impulso de votos (0.30): Solo señales proactivas — 80% votos + 20% comentarios
  • Convergencia (2x): Se aplica cuando un tema tiene tanto señales reactivas como proactivas. Las señales desviadas no lo activan

La frecuencia y el impulso de votos se normalizan contra el tema principal en la misma llamada, por lo que las puntuaciones son relativas a una ventana de análisis. Compara clasificaciones entre llamadas, no puntuaciones brutas.

Solución de problemas

  • Los cambios no surten efecto. El cliente MCP ejecuta el dist/ compilado. Después de editar el código fuente, ejecuta npm run build y reinicia el cliente (o la conexión del servidor MCP) para recoger el nuevo código.
  • No HelpScout mailbox named "…". Ejecuta list_sources para ver los nombres exactos de los buzones, o pasa el mailbox_id numérico directamente.
  • No portal found with name "…" / portal faltante. El portal debe configurarse en PRODUCTLIFT_PORTALS (o las variables de entorno de portal único). Ejecuta list_sources para ver los portales configurados.
  • Advertencia de Chatbase: A Standard plan or higher is required. El acceso a la API comienza en el plan Standard de Chatbase. El resto del análisis aún se ejecuta; solo faltan los campos de desviación.
  • chatbase_agents está vacío en list_sources. Tanto CHATBASE_API_KEY como una de CHATBASE_AGENTS / CHATBASE_AGENT_ID deben estar configurados — una clave por sí sola no configura nada.

Contribuir

  1. Haz un fork del repositorio
  2. Crea una rama de características (git checkout -b feature/your-feature)
  3. Asegúrate de que npm run build se ejecute sin errores
  4. Sigue los patrones existentes: las herramientas usan registerTool, los clientes de API obtienen su propio módulo, la limpieza de PII ocurre en la capa de formato
  5. Abre una solicitud de extracción

Licencia

MIT