Token导航 LogoToken导航

MCP Server · 数据服务

MCP Data Analysis

一个在知识发现过程中通过自然语言引导用户、自动执行分析并生成交互式仪表板的对话系统。

stdio官方级别未说明来源级核验工具 0
数据分析工作流自动化PythonClaude机器学习Claude DesktopCursor

快速开始

作者 / 组织
fhp101ml
提供方
fhp101ml
运行时
Python

工具数量

0

来源目录标注

资源数量

0

来源目录标注

提示词数量

0

来源目录标注

GitHub Star

0

仓库热度

收录来源

2 个

MCP World

选型结论

MCP Data Analysis 属于数据服务类 MCP Server,公开资料标注 0 个工具,通过stdio 本地进程接入,适配 Claude Desktop、Claude、Cursor,有可以直接复制的安装命令;接入前要先准备 会话凭据。

分类

数据服务

传输方式

stdio

认证方式

会话凭据

部署方式

公开资料未说明

安装与配置

安装命令

python -m venv .venv

公开命令不是通用的启动方式,拼不出可靠配置示例;请在客户端 MCP 配置里按官方文档填写 command 和 args。

上手步骤

  1. 1

    准备运行环境

    stdio 服务在本地起进程,需要先装好 Python,再按安装命令拉取依赖。

  2. 2

    安装服务

    复制下面的安装命令执行;命令里带占位符的位置换成自己的密钥或路径。

  3. 3

    写入客户端配置

    在客户端的 MCP 配置里填启动命令和参数,保存后完全退出客户端再打开,让新配置生效。

  4. 4

    验证是否可用

    连接成功后客户端会列出 0 个工具,随便调一个只读工具确认能返回结果。

接入前确认

不要直接授予不必要的文件、网络或账号权限;先核对安装命令和配置内容。

详细介绍

KDD Conversacional

Descripción del Proyecto

Sistema conversacional que acompaña al usuario durante todo el proceso de Descubrimiento de Conocimiento en Datos (KDD). Funciona como un copiloto analítico, facilitador metodológico y orquestador del workflow que guía al usuario mediante lenguaje natural, ejecuta análisis de forma automática y culmina con la generación autónoma de un dashboard interactivo que sintetiza resultados, insights y modelos.

El Horizonte MCP (Model Context Protocol)

El objetivo final arquitectónico de la aplicación transciende su interfaz web (Streamlit). Una vez que el ciclo KDD esté totalmente operativo y el motor de agentes sea infalible, se creará una versión independiente exponiendo el sistema íntegramente como un servicio MCP. Esto significa que el proyecto actuará como un "Agente KDD Universal" conectable a cualquier ecosistema de IA corporativo o cliente compatible (como *Claude Desktop* o *Cursor*), permitiéndoles usar a nuestro experto en datos como si fuera una simple función o comando a la que delegarle la ingesta, análisis y creación de modelos de Machine Learning dentro del Sandbox aislado, devolviendo los *insights* y *artefactos* extraídos al agente principal.

Arquitectura del Motor Conversacional (Agentes)

El corazón conversacional de la aplicación funciona como una máquina de estados orquestada por LangGraph. A diferencia de un chatbot tradicional lineal, el sistema actúa como un grupo de agentes especialistas organizados por un Router:

  • Nodo Router: El usuario habla y el mensaje pasa por el router. Este nodo monitoriza la fase metodológica en la que se encuentra la conversación (1_understanding, 4_eda, etc.) y decide a qué agente experto enviarle el flujo.
  • Goal Agent (Especialista Fase 1): Un modelo dedicado exclusivamente a hacer preguntas exploratorias al principio de la conversación. No ejecuta código. Su misión es garantizar que el usuario define claramente "qué quiere conseguir" (predecir, agrupar, encontrar anomalías) y almacenarlo en la memoria del sistema.
  • Generic/Specialist Agents (Fases > 1): A medida que la fase avanza a perfilado, EDA o modelado, el router despertará a agentes que tienen capacidades de escribir Python (usando LLMs a los que se asocia el Tool_Node). Estos agentes delegarán la ejecución del código al [Sandbox Docker], recuperarán las respuestas y se las explicarán al usuario.

*Para el desarrollo es imprescindible que exista un archivo src/.env configurado que contenga al menos las API keys de los LLM predeterminados (Ej: OPENAI_API_KEY, MISTRAL_API_KEY, etc), que la aplicación se encargará de cargar en tiempo de inicialización.*

Utilidad

El valor principal del sistema no radica únicamente en el dashboard final, sino en el proceso guiado. Al actuar como un analista senior, el sistema:

  • Evita análisis estadísticos o de machine learning incorrectos.
  • Reduce errores en la preparación de datos.
  • Mejora la interpretación de los resultados.
  • Educa y enseña al usuario durante la exploración.

Instalación y Ejecución Local

Para reproducir este sistema en local, se recomienda el uso de pyenv para preservar la pureza del entorno de desarrollo.

Pre-requisitos

  • Python 3.12.3 (Configurado a través de pyenv)
  • Docker Desktop / Engine (Activo en segundo plano para el Sandbox Analítico)

1. Preparación del Entorno

# 1. Configurar la versión correcta de Python
pyenv local 3.12.3

# 2. Crear entorno virtual
python -m venv .venv
source .venv/bin/activate

# 3. Instalar librerías
pip install -r requirements.txt

2. Variables de Entorno

Es imprescindible crear un archivo src/.env y, opcionalmente, .env en la raíz del proyecto para definir las claves base de los LLM que alimentan LangGraph. Un ejemplo del archivo (o su plantilla .env.example si existe) sería:

OPENAI_API_KEY=sk-....
MISTRAL_API_KEY=your_key_here

3. Ejecución Paralela

El sistema utiliza una arquitectura bi-modal manual para depuración. Se requieren dos terminales abiertas:

Terminal 1: Iniciar el Motor Inteligente KDD (FastAPI) Conserva el contexto, la memoria SQLite de las sesiones, y el enrutamiento LangGraph.

source .venv/bin/activate
uvicorn src.main:app --host 127.0.0.1 --port 8000 --reload

Terminal 2: Iniciar la Interfaz de Usuario Experto (Streamlit) Levanta la SPA que interactúa con el backend consumiendo los endpoints REST.

source .venv/bin/activate
streamlit run src/ui/app.py

Accede posteriormente por navegador web a http://localhost:8501.

Fases de Construcción del Sistema

🟢 Fase 1 — Fundaciones del sistema (infraestructura base)

Objetivo: Crear el "esqueleto" donde todo podrá ejecutarse. Qué se construyó: Backend FastAPI async, contrato inicial de servers MCP, Docker sandbox para ejecución analítica aislada y logging estandarizado.

🟢 Fase 2 — Motor conversacional y estado del análisis

Objetivo: Que el sistema entienda conversaciones y mantenga contexto analítico. Qué se construyó: Grafo maestro de LangGraph, Memoria de sesión y Estado Global KDD.

🟢 Fase 3 — Ingestión y comprensión de datos

Objetivo: Que el sistema entienda datasets automáticamente. Capacidades: Upload CSV, Perfilado automático, Identificación de tipos, Evaluación de calidad, Resumen interpretado. Resultado: Dataset contextualizado.

🟢 Fase 4 — Interfaz Gráfica de Usuario (Web UI)

Objetivo: Permitir al experto interactuar con el flujo sin usar la terminal. Qué se implementa: Cliente Streamlit asíncrono, renderizado the componentes HTML (Reportes YData) y subida de archivos al Sandbox.

🟢 Fase 5 — Guía conversacional del proceso KDD y Memoria Avanzada

Objetivo: Que el sistema actúe como facilitador metodológico con memoria persistente. Qué se implementa:

  • Flujo guiado, Preguntas inteligentes, Propuestas de pasos.
  • Sustitución del Session Manager virtual por Checkpointers de LangGraph (SqliteSaver/PostgresSaver) para ganar persistencia nativa de hilos, capacidad de *Time Travel* (volver atrás en análisis) e interrupciones dinámicas (*Human-in-the-loop*).

🟢 Fase 6 — Ejecución de análisis exploratorio automático (EDA ampliado)

Objetivo: EDA profundo generado dinámicamente. Capacidades: Estadística descriptiva a demanda, Correlaciones avanzadas, Outliers dinámicos por el Sandbox.

🟢 Fase 7 — Agente Generador y Linaje de Datos con MinIO

Objetivo: Construir un pipeline reproducible y centralizado de artefactos. Qué incluye:

  • Almacenamiento físico de archivos (gráficos, CSVs procesados, modelos) en Buckets de MinIO (S3).
  • KDDState tracking: Inyección de metadatos ricos en el estado global para que el Dashboad Final o los agentes los consuman.

Estructura del Estado de Artefactos:

class KDDArtifact(TypedDict):
    nombre_artefacto: str
    breve_descripcion: str
    s3_path: str          # Ej: s3://kdd-artifacts/session_123/eda/correlaciones.png
    fase_generacion: str  # Ej: '4_eda', '5_modelado'
    tipo: str             # Ej: 'plot', 'dataset_limpio', 'model_pkl'

*Mecánica:* El Sandbox o el Agente sube el archivo a MinIO y añade un objeto KDDArtifact a la lista state["artifacts"]. Cuando se genere el Dashboard final, el LLM tendrá a su disposición el inventario completo, su descripción y su ruta directa para ensamblar interactividad.

🟢 Fase 8 — Modelado y descubrimiento de patrones

Objetivo: Extraer conocimiento y baseline predictors.

🟢 Fase 9 — Síntesis automática del conocimiento

Objetivo: Convertir análisis en narrativa coherente a los usuarios del KDD.

🟢 Fase 10 — Dashboard como artefacto vivo

Objetivo: Permitir iteración. Capacidades: Modificar paneles vía chat, Añadir gráficos de Plotly u otras librerías.

🟢 Fase 11 y 12 — Sandbox Alternativo y Robustez

Objetivo: Seguridad, logging, auditoria y alternativas LangChain.

🟢 Fase 13 — Interoperabilidad (El KDD como Servidor MCP)

Objetivo: Convertir el motor analítico en un "Agente Especialista" conectable (enchufable) a otros sistemas, proyectos y herramientas LLM (Claude Desktop, Cursor, etc.). Qué se implementa:

  • Exposición de la lógica LangGraph a través del protocolo estándar MCP (Model Context Protocol).
  • El sistema ofrecerá sus capacidades (*Tools*: perfilar datos, entrenar modelos en sandbox) y su memoria (*Resources*: insights, reportes EDA) a agentes "Generalistas" externos.
  • La aplicación mantendrá una arquitectura dual: Backend REST (para humanos vía UI) + Servidor MCP (para interoperabilidad IA a IA).

Historial de Versiones

  • v0.5.0 (Actual): Fase 6 (EDA Dinámico y Sandbox Efímero) y completado final de la Fase 5 (Recarga de historial desde bases de datos vectoriales persistentes). Agente de código Python plenamente funcional, enrutamiento condicional perfecto en el Session Manager.
  • v0.4.0: Fase 5 (Guía conversacional y Memoria Avanzada) completada. Integración de AsyncSqliteSaver nativo de LangGraph para ruteo asíncrono y reordenación del flujo para IA Proactiva post-perfilado.
  • v0.3.0: Fase 3 (Ingestión asíncrona y Pefilado con YData en Sandbox) y Fase 4 (UI en Streamlit con Reportes Interactivos) completadas.
  • v0.2.0: Infraestructura Docker y Arquitectura LangGraph completada. Carga de entornos integradas.
  • v0.1.0: Definición de la idea inicial, objetivos y fases del proyecto.

工具与能力

工具数量

0

资源数量

0

提示词数量

0

能力标签

数据分析Python本地部署机器学习自然语言处理自动化工作流知识发现

支持客户端

Claude DesktopClaudeCursor

数量来自来源目录的标注,具体工具清单以官方文档为准。

典型使用场景

用自然语言查库

不用手写 SQL,直接问数据,让模型组织查询语句。

数据巡检

定期拉指标、做对比,把异常项整理成一段说明。

打通业务数据

把数据库、数仓和接口接进同一个上下文,减少导出再上传。

选择建议

值得选的地方

  • 只提供 0 个工具,职责集中,接入后不容易误操作。
  • 有现成的安装命令,不用自己找入口,照着跑就能起服务。
  • 已经适配 Claude Desktop、Claude、Cursor,换客户端不用重新研究配置。

先想清楚的地方

  • stdio 方式要求本地装好 Python,换机器要重新装一遍。
  • 需要自备会话凭据,没有凭据没法直接试。
  • 公开摘要偏短,具体能力和限制要回到仓库确认。

更适合

  • 需要在数据服务场景里让模型直接调用外部能力的人。
  • 已经在用 Claude Desktop 的用户,接入路径最短。
  • 想先快速试一下、能接受在本地跑服务的人。

不太适合

  • 完全不想在本地装环境的人。
  • 暂时拿不到会话凭据的人。
  • 需要厂商级 SLA 和技术支持的生产环境。

同类对比

5 个同类
MCP Server工具数传输方式安装命令收录来源最后核验
MCP Data Analysis

MCP World · 本页

0stdio有2 个2026-05-17
Memory 9d25f64e

MCP World

9未说明未标注1 个2026-05-17
Prisma MCP Server

MCP World

0stdio有3 个2026-05-17
Astr Bot

MCP World

0stdio有1 个2026-05-17
Getzep MCP

MCP World

9stdio有1 个2026-05-17

按同分类和工具数量挑出最接近的几条,字段以各自详情页为准。

常见问题

5 条

MCP Data Analysis 怎么安装?

公开资料给出的安装命令是 python -m venv .venv,运行环境为 Python。装完后按客户端要求写进 MCP 配置,重启客户端生效。

MCP Data Analysis 怎么在 Claude Desktop、Cursor 里配置?

它是stdio 本地进程,客户端配置里要写启动命令和参数,运行环境是 Python;保存后完全退出客户端再打开,配置才会生效。

MCP Data Analysis 收费吗?

本站只整理公开资料,不代收费用,也没有标注具体价格。是否收费取决于服务本身和背后的接口额度,正式使用前按官方说明确认。

MCP Data Analysis 需要 API Key 吗?

公开资料标注的认证方式是会话凭据,也就是要先拿到凭据才能连上;凭据只填在自己本地的配置里,不要写进公开仓库。

MCP Data Analysis 支持哪些客户端?

公开资料标注支持 Claude Desktop、Claude、Cursor;其他客户端只要能配置 MCP Server,也能用同样的命令或地址接入。

来源信息

继续浏览同类 MCP