software refactoriza tu ERP del siglo pasado por 4 perras gordas

MCP-Access: pilotando Microsoft Access desde Claude Code en lenguaje natural

Microsoft Access es de esas herramientas que casi nadie defiende en voz alta pero que media España usa en silencio: gestores de almacén, contabilidades de pyme, programas de citas de clínicas dentales, fichas de inventario de talleres. Funciona, va rápido, vive en un único fichero .accdb que se copia en un USB y ya está. El problema es que para hacer cualquier cosa medianamente avanzada necesitas conocer VBA, SQL, propiedades de formularios, eventos, controles… horas y horas de pelea. MCP-Access es un servidor MCP que conecta Claude Code (o Cursor, o Windsurf) directamente con Access y deja al modelo de IA crear bases de datos enteras, formularios, tablas, consultas, informes y código VBA hablándole en lenguaje natural. El proyecto vive en github.com/unmateria/MCP-Access.

Sesión de Claude Code creando una base de datos para una tienda de bicicletas: pidiéndole en lenguaje natural que monte el ERP, Claude llama una a una a las herramientas access_create_database y access_create_table para fabricar las tablas tbl_Config, tbl_Marcas, tbl_Tallas, tbl_Colores y demás
Sesión real construyendo el ERP de una tienda de bicicletas a partir de una descripción en castellano. Claude va llamando a las herramientas del MCP (access_create_database, access_create_table…) y pueblan el .accdb sobre la marcha.

Un aviso antes de seguir. Esto no es un proyecto académico ni una demo. Es un MCP personal que llevo usando a diario para refactorizar y mejorar mi propio ERP de 1999 — más de 200.000 líneas de código en un Access que sigue en producción todos los días. No lo he construido en abstracto: ha ido creciendo sobre la marcha, peleándose con problemas reales de una base de datos viva. Cuando me topo con un caso que no sabe resolver, abro un issue, y en cuestión de horas — al día siguiente como mucho — hay una herramienta nueva o un fix corrigiéndolo. Eso significa dos cosas: las 62 herramientas existen porque han hecho falta de verdad, y el proyecto se mueve rápido. Si lo descubres hoy y echas algo de menos, vuelve mañana.

01 — El problema: Access es potente, pero su curva de aprendizaje espanta

Cualquiera que haya intentado montarse su propio programa de gestión en Access — un control de stock para la tienda, una agenda de clientes para la gestoría, un cuaderno de mantenimiento para el taller — se ha topado con la misma pared. La parte de guardar datos es relativamente fácil: se diseña una tabla, se mete información, hasta ahí bien. La parte de presentarlos ya empieza a torcerse: hay que aprender a montar formularios, configurar controles, ligarlos a la tabla. Y la parte de hacer cosas con ellos — calcular un total, validar un campo, mandar un albarán a PDF, marcar como pagada una factura — exige escribir código VBA, que es un lenguaje de los 90 con su propia mitología y muy poca documentación moderna.

El resultado es que la mayoría de la gente que intenta hacerse su propia base de datos en Access acaba en uno de tres sitios: pagando a un programador para que se la haga, abandonando el proyecto, o conviviendo con un cacharro que casi funciona pero que nadie se atreve a tocar. Y eso es una pena, porque Access es brutalmente capaz para gestionar la operativa de una pyme de 1 a 10 personas — más que suficiente para llevar una empresa entera sin pagar SaaS mensuales ni depender de servidores ajenos.

Lo que cambia con un asistente de IA conectado por MCP es que la barrera de entrada deja de ser técnica y pasa a ser conceptual. Tú ya no necesitas saber qué es un QueryDef, ni cómo se escribe un DoCmd.OpenForm, ni la diferencia entre un recordsource y un rowsource. Solo necesitas saber lo que quieres: «una pantalla para meter clientes con su NIF, dirección y teléfono», «un listado de facturas pendientes con un botón para marcarlas como pagadas», «un informe mensual de ventas por categoría». Claude lo traduce a la operación técnica que toque y MCP-Access la ejecuta sobre el fichero .accdb directamente.

02 — Qué es un MCP y por qué cambia las reglas

MCP son las siglas de Model Context Protocol, un estándar que publicó Anthropic (la empresa detrás de Claude) para que asistentes de IA puedan «hablar» con programas externos. La idea es muy simple: en lugar de que tú le pidas a la IA «por favor escríbeme un código VBA para hacer X» y luego copies y pegues ese código en Access — con todos los errores que eso conlleva — la IA tiene un canal directo de comunicación con un servidor MCP, que es un programa que se ejecuta en tu ordenador y que sabe hacer cosas concretas. El asistente llama a esas herramientas y el servidor actúa sobre el sistema real.

Un MCP es, en la práctica, un puente entre el lenguaje natural y una herramienta concreta. Hay MCPs para GitHub, para bases de datos PostgreSQL, para Figma, para Excel, para servidores remotos por SSH. Cada uno expone una serie de tools (herramientas) — funciones bien definidas — que la IA puede invocar cuando lo crea oportuno. La IA no ve tu base de datos: ve un menú de herramientas como «access_list_objects», «access_create_table» o «access_run_vba». Cuando tú le pides algo, la IA decide qué herramientas combinar y en qué orden.

MCP-Access es uno concreto: el que se conecta a Microsoft Access. Lo que tiene de especial es lo profundo que llega. La mayoría de los MCPs son finos — exponen tres o cuatro operaciones básicas. Este expone 62 herramientas distintas, cubriendo prácticamente todo lo que se puede hacer con Access desde el editor visual y desde el editor de VBA. Eso significa que no se queda corto a las dos preguntas: hay margen para construir aplicaciones completas, no solo para hacer demostraciones.

03 — Lo que MCP-Access deja hacer

Las 62 herramientas se agrupan en bloques que cubren todas las áreas funcionales de Access:

El detalle importante es que estas herramientas están especializadas, no son un genérico «ejecuta este código y reza». Cada una sabe lo que hace, valida sus parámetros, devuelve errores comprensibles, y aplica medidas de seguridad — por ejemplo, las operaciones destructivas como borrar un objeto exigen un parámetro confirm=true explícito, y el editor de VBA hace una comprobación estructural después de cada cambio para no dejar el módulo roto.

04 — Instalación paso a paso

El servidor está escrito en Python y solo funciona en Windows, porque depende de la automatización COM — la API que Microsoft expone para que otros programas controlen Office. Necesitas:

Una vez con Python instalado, abre PowerShell y ejecuta:

pip install mcp pywin32

Ese par de paquetes son toda la dependencia. mcp es el SDK del protocolo, pywin32 es lo que permite a Python hablar COM con Access.

Después clona el repositorio en una carpeta de tu disco — yo lo tengo en C:\herramientas\MCP-Access pero la ruta da igual, lo único importante es recordarla:

git clone https://github.com/unmateria/MCP-Access.git C:\herramientas\MCP-Access

Si no tienes git, baja el ZIP desde la página del repo en GitHub y descomprímelo donde quieras.

El último paso de preparación es decirle a Access que se deje toquetear el código VBA desde fuera. Por motivos de seguridad, Access viene con esa puerta cerrada por defecto. Hay que abrirla manualmente:

  1. Abre Access (cualquier base de datos vale, o una en blanco).
  2. Menú Archivo → Opciones → Centro de confianza → Configuración del Centro de confianza → Configuración de macros.
  3. Marca la casilla «Confiar en el acceso al modelo de objetos de proyectos de VBA».
  4. Acepta y cierra Access.

Esto es un ajuste de una sola vez, queda guardado en el perfil del usuario. El repo incluye también un script enable_vba_trust.ps1 que lo hace por línea de comandos si prefieres no buscar la opción a mano.

05 — Conectar el MCP a Claude Code

Una vez todo instalado, registra el servidor en Claude Code con un único comando. Abre PowerShell en la carpeta donde tengas tu proyecto (o en cualquier carpeta si lo quieres global) y escribe:

claude mcp add access -- python C:\herramientas\MCP-Access\access_mcp_server.py

Ajusta la ruta al sitio donde hayas clonado el repo. Eso registra el MCP de manera global, disponible en cualquier sesión de Claude Code. Si prefieres que sólo esté activo en un proyecto concreto — porque solo trabajas con Access en ciertas carpetas y no quieres tener el servidor cargado todo el tiempo — usa la variante con scope de proyecto, que crea un fichero .mcp.json en el directorio actual:

claude mcp add --scope project access -- python C:\herramientas\MCP-Access\access_mcp_server.py

Para comprobar que está bien conectado, abre Claude Code en esa carpeta y escríbele algo como «lista las herramientas del MCP de Access». Si todo está bien, te debería aparecer el menú de las 62 herramientas que empiezan por access_. Si no aparecen, lo más habitual es que la ruta al script esté mal, o que falte alguno de los paquetes pip, o que Python no esté en el PATH.

06 — Crear una base de datos desde cero

Aquí viene lo divertido. Con el MCP funcionando, abres Claude Code en una carpeta cualquiera y le hablas como le hablarías a un compañero — pero en cristiano, sin tecnicismos ningunos. Por ejemplo, para empezar una base de datos para gestionar los socios de una asociación:

Hazme una base de datos para llevar los socios de mi asociación.
Quiero apuntar el nombre, los apellidos, el email, el teléfono,
la fecha en que se dieron de alta, si han pagado la cuota o no,
y un sitio para escribir notas.
Guárdala en mi escritorio.

Claude se encarga del resto: decide solo los tipos correctos para cada campo (texto, fecha, sí/no, etcétera), añade un identificador automático para cada socio, crea el fichero .accdb, y te dice dónde lo ha dejado. Abres con doble click y ahí está la tabla, lista para meter datos.

El siguiente paso natural es pedirle una pantalla para introducir socios sin tener que ver la tabla cruda:

Hazme una ventana bonita para apuntar socios nuevos, con un botón
para guardar y otro para cerrar.

Y ya está. Claude monta el formulario, le pone los campos, los botones, escribe el código VBA que hace falta para que los botones funcionen, y te avisa cuando está listo. Sin haber tocado VBA tú.

07 — Construir un mini-ERP hablándole a Claude

Lo anterior es la versión fácil. La que de verdad demuestra el potencial es construir una aplicación completa. Imagínate que llevas la administración de una microempresa — un taller, una tienda online pequeña, una academia — y quieres tu propio sistemita en Access para gestionar clientes, productos, pedidos y facturas. Eso, en programación tradicional, son varias semanas. Con MCP-Access es una conversación de un par de tardes. Una sesión podría empezar así:

Quiero montar un programita para mi tienda de bicicletas.
Tengo que llevar el control de mis clientes, de las bicis y
recambios que vendo, y de los pedidos que me hacen.
Cada pedido es de un cliente y puede tener varias bicis o
recambios dentro, con su cantidad. Y los pedidos pasan por
"borrador", "enviado" y "pagado".
Móntame la base como sea más razonable y guárdala en mi escritorio.

En unos segundos tienes el esqueleto: cuatro tablas (clientes, productos, pedidos y líneas de pedido) bien relacionadas entre sí, con sus claves y sus borrados en cascada cuando hace falta. Tú no has tenido que decidir nada de eso — Claude lo deduce de tu descripción en lenguaje normal. A partir de ahí vas pidiéndole pieza por pieza:

Cada una de esas frases dispara una secuencia de llamadas a herramientas del MCP — algunas crean controles, otras escriben VBA, otras crean consultas, otras informes. Y como Claude tiene la captura de pantalla entre sus herramientas (access_screenshot), si algo no queda como esperabas, le dices «no, mueve el botón a la derecha y hazlo más grande» y él mira cómo está, calcula coordenadas y lo arregla.

Conviene iterar en pasos pequeños: pedir una cosa, abrir Access, comprobar que funciona, y solo entonces seguir. No por desconfianza, sino porque tú vas afinando lo que quieres a medida que ves resultados — y porque si algo se tuerce es mucho más fácil identificar dónde.

08 — Editar una Access que ya existe

El otro escenario clásico es heredar una base de datos legada — esa Access que montó el primo de un amigo en 2014 y que sigue sosteniendo medio negocio — y querer modificarla sin romper nada. Aquí MCP-Access brilla especialmente, porque tiene herramientas pensadas justo para eso:

El flujo típico es: le pides a Claude que se haga un resumen de la base, le explicas qué quieres cambiar («añade un campo "comercial_id" a la tabla pedidos y mete una columna en el formulario de pedidos para elegirlo de un combo de la tabla empleados»), y él va navegando los objetos, leyendo el código existente, encontrando los sitios donde toca tocar, y aplicando los cambios. Si algo falla, las herramientas de compilación (access_compile_vba) detectan los errores con su línea exacta y Claude los corrige.

Una herramienta clave en bases de datos viejas es access_decompile_compact. Cuando una .accdb lleva años editándose, acumula basura compilada — código intermedio (p-code) que ya no corresponde al código fuente actual. El fichero crece sin parar y empieza a dar errores raros al compilar. Esta herramienta hace una operación de mantenimiento que tradicionalmente solo conocían los administradores avanzados de Access: lanza un decompile + compact que vacía la basura y deja la base limpia. Reducciones del 60-70% del tamaño del fichero son habituales.

09 — Portar un Access viejo a .NET o a web

Hay un caso de uso menos obvio pero igual de potente: usar MCP-Access no para seguir en Access, sino para salir de él. Cualquiera que haya intentado migrar una aplicación Access vieja a .NET, a Java, a una web moderna o a una app de escritorio en Electron sabe que el problema de fondo no es escribir el código nuevo — es entender el viejo. Hay decenas de miles de líneas de VBA escritas a lo largo de veinte años por gente que ya no está, formularios con eventos por todos lados, consultas SQL guardadas con JOINs raros, lógica de negocio repartida entre macros, queries y módulos. Reescribirlo a ciegas es un suicidio.

MCP-Access convierte Access en una fuente de datos legible para otra IA. Las herramientas access_export_structure, access_get_code, access_find_usages y access_find_definition permiten al modelo navegar la base completa, leer el VBA módulo a módulo, mapear qué consulta usa qué tabla, qué formulario llama a qué función, y construir un inventario exhaustivo de la lógica de negocio. Y como Claude entiende VBA perfectamente, puede traducirlo a otra cosa.

Un flujo típico de migración es algo así:

  1. Pídele a Claude un inventario completo: tablas, relaciones, formularios, informes, consultas guardadas, módulos VBA, qué función llama a qué. Que lo vuelque en Markdown.
  2. Pídele que extraiga la lógica de negocio función por función: qué hace, qué reglas aplica, qué tablas toca. Esa documentación es oro — probablemente la primera vez en años que esa información está escrita en algún sitio.
  3. Pídele que genere el equivalente en el stack destino. «Esta función VBA que calcula el descuento por volumen, dame el equivalente en C# para una API REST». «Este formulario de pedidos, móntame el equivalente en React con Tailwind». «Estas tablas Access, dame los CREATE TABLE para PostgreSQL preservando los tipos».
  4. Mientras la migración avanza, mantén el Access vivo en producción y úsalo como oráculo de comportamiento: cuando dudes si la lógica nueva es correcta, ejecutas la consulta o la función en el Access viejo a través del MCP y comparas resultados.

Lo bonito es que esto cambia radicalmente la economía del refactor. Lo que antes era «contratar una consultora durante seis meses para que entienda tu sistema antes de empezar a tocar nada» pasa a ser «un par de semanas leyéndolo conversacionalmente con Claude antes de decidir qué reescribir y en qué orden». Y como tienes la base original como referencia siempre disponible, puedes ir migrando módulo por módulo en lugar de hacer un Big Bang. La pregunta deja de ser «¿podemos permitirnos reescribirlo?» y pasa a ser «¿qué partes vale la pena reescribir y cuáles dejamos en Access otros diez años más?».

10 — Buenas prácticas y trampas conocidas

Cosas que es importante tener en cuenta:

11 — Para quién es esto

Esto está pensado especialmente para tres perfiles:

Lo que no es: una solución mágica que sustituya el pensamiento. Sigues teniendo que diseñar bien el modelo de datos, sigues teniendo que validar que lo que produce funciona, sigues teniendo que entender — al menos por encima — qué es una clave primaria o por qué una relación con borrado en cascada puede ser peligrosa. Pero la fricción técnica entre tener una idea y tener una aplicación funcional baja de semanas a horas. Y eso, para quien lleva años pensando «si yo supiera programar, me haría…», es la diferencia entre hacerlo y no hacerlo.

El proyecto está activo, con commits frecuentes y un changelog detallado. Lo que faltaba para que Microsoft Access — esa herramienta tan querida y tan denostada — entre en la era de la programación conversacional. github.com/unmateria/MCP-Access.

Gracias especiales a TvanStiphout-Home y CaptainStormfield, que se prestaron a hacer de betatesters desde el principio, reportaron múltiples fallos y ayudaron a resolverlos. Sin ellos el proyecto estaría bastante más verde.