MCP

Tedix: delega el trabajo en asistentes de IA y recupera solo las decisiones que te necesitan

Tedix encaja con quien quiere entregar el trabajo rutinario completo a Claude, ChatGPT o Codex y ocuparse personalmente solo de las decisiones clave; para probarlo en local hacen falta Git, Bun y Node.js 22+, sin cuenta, y el Tedix Cloud alojado es por ahora solo por invitación.

Official source · Tedix

Install

git clone https://github.com/tedix-hq/tedix.git && cd tedix
bun run-local --demo

Para quién es

Tedix es para quienes usan asistentes de IA con frecuencia, quieren entregar en bloque el trabajo rutinario y decidir personalmente solo en los puntos clave. El posicionamiento oficial: una vez entregado el trabajo, Tedix te trae de vuelta solo las decisiones que te necesitan, ordenadas por importancia, y se encarga del resto. Dicho de otro modo, no resuelve si se puede llamar a la IA, sino qué asuntos merecen tu propia mirada. Si ya avanzas tareas en Claude, ChatGPT o Codex y quieres reducir el ir y venir de vigilar el progreso, vale la pena probarlo.

En clientes, el soporte oficial cubre Claude, ChatGPT y Codex; otros clientes compatibles con MCP se conectan a través del MCP gateway. Si los asistentes fuera de ese rango se conectan sin problemas no está dicho en la evidencia: verifícalo por tu cuenta.

El punto de partida es una cadena de herramientas local: Git, Bun y Node.js 22+, con el énfasis oficial en un Node real, no un shim de Bun. Esta vía local no requiere cuenta ni credenciales de nube; el costo de prueba está sobre todo en preparar el entorno. Si encaja con el tipo de trabajo de tu campo tampoco aparece acotado en la evidencia: valida primero con tareas de bajo riesgo.

Por ahora no encaja para: quien solo quiere un servicio en la nube listo para usar y no piensa instalar herramientas locales. Tedix Cloud aún no abre registro y funciona por invitación; sin invitación y sin entorno local, hoy no hay forma de probarlo. A los equipos con necesidad firme de nube se les recomienda conseguir primero la invitación y evaluar después.

Un primer intento en 3 minutos

La vía principal recomendada es el modo demo local: arranca la app en local con datos de ejemplo, no depende de la nube y no pide cuenta ni credenciales de nube.

Primer paso, confirmar los requisitos: instala Git, Bun y Node.js 22+. Si ese conjunto de dependencias no se puede instalar localmente, esta vía no funciona.

Segundo paso, clonar el repositorio e iniciar la demo:

git clone https://github.com/tedix-hq/tedix.git && cd tedix
bun run-local --demo

Tercer paso, observar las señales de éxito: la app arranca en local y carga los datos de ejemplo. La descripción oficial llega hasta ahí; qué operaciones ofrece la interfaz de la demo y qué contienen los datos de ejemplo no está en la evidencia: obsérvalo y confírmalo en local. En el primer intento conviene solo observar, sin enviar tareas reales, y avanzar cuando el comportamiento cumpla lo esperado.

Dos avisos: primero, este paso es una ejecución local y no toca credenciales de nube; segundo, si la app lee otros datos locales o se conecta a la red no está en la evidencia, así que no des por hecho que no tiene impacto. Ambos puntos no impiden el primer intento, pero sí influyen en que sigas usándolo.

Las demás vías oficiales de acceso son solo referencia secundaria, sin ponerlas al nivel de la principal: los agentes que soportan Agent Skills pueden añadir las skills de Tedix con npx skills add tedix-hq/tedix-plugins; aparte de los clientes nombrados oficialmente, los clientes que hablan MCP se conectan vía MCP gateway. Qué configuración necesita cada vía no se dice en la evidencia.

Casos de uso

Caso uno: sin nube, entender su mecanismo de decisiones con los datos de ejemplo. Escenario: quieres juzgar si la forma de trabajar de «traer de vuelta solo las decisiones que te necesitan» te encaja, sin aportar datos reales. Manera: completa el clonado de arriba y ejecuta bun run-local --demo. Resultado esperado: la app arranca en local con datos de ejemplo, sin cuenta ni credenciales de nube en ningún momento; qué operaciones hay en la demo y qué salida se obtiene no está listado en la evidencia: manda lo que veas en local.

Caso dos: añadir las skills de Tedix a un agente que ya tienes. Escenario: tu agente de diario lee Agent Skills y quieres darle la capacidad de Tedix para procesar trabajo. Manera: ejecuta npx skills add tedix-hq/tedix-plugins. Resultado esperado: oficialmente, cualquier agente que lea Agent Skills puede añadir así las skills de Tedix; qué skills se ofrecen tras añadirlas y cómo se invoca cada una no está en la evidencia y no se puede confirmar al detalle ejecutable: revísalas tras añadirlas y haz primero una prueba con una tarea intrascendente.

Límites de uso

  • Lectura y escritura: de las capacidades concretas que exponen el modo demo y el MCP gateway, cuáles son de solo lectura y cuáles escriben estado local o remoto no está en la evidencia; aclara el impacto antes de ejecutar una acción, y una escritura local tampoco debe tratarse como lectura.
  • Credenciales y datos: en la vía local principal, lo oficial es claro: sin cuenta y sin credenciales de nube; el alcance de los archivos locales que lee la app, si se conecta a la red y cómo trata los datos siguen sin confirmarse.
  • Diferencia con la nube: Tedix Cloud es por invitación y no abre registro; qué capacidades cubren la demo local y el servicio de nube, y cuán grande es la diferencia, no está en la evidencia.
  • Consistencia entre clientes: si los clientes nombrados oficialmente y los conectados vía MCP gateway tienen las mismas funciones no está confirmado.
  • Deshacer y retención: la evidencia no menciona cómo deshacer operaciones, cuotas de uso ni retención de datos; que no se mencione no significa que no haya límites: antes de operaciones críticas, guíate por la documentación oficial. El alcance del contenido de los datos de ejemplo tampoco se menciona.