Hasta este punto nuestras tools MCP funcionan correctamente, pero el código tiene dos problemas que debemos resolver antes de escalar la solución. El primero es que el bloque de conexión de Netmiko se repite en cada tool, generando código duplicado. El segundo, y más crítico, es que las credenciales de los dispositivos están escritas en texto plano dentro del archivo Python. Por lo tanto, en esta clase aprenderemos a implementar el mecanismo del archivo env en automatización de redes, refactorizando el código para que sea limpio, reutilizable y seguro.

¿Qué lograrás con esta clase?

• Refactorizar el código duplicado de tus tools MCP centralizando la lógica de conexión de Netmiko en una función auxiliar reutilizable
• Identificar los riesgos de tener credenciales del switch escritas en texto plano dentro del código
• Implementar el mecanismo del archivo .env para separar credenciales sensibles del código
• Instalar y utilizar python-dotenv en el entorno virtual de tu servidor MCP
• Añadir nuevas tools de lectura en cuestión de segundos gracias al patrón refactorizado

Refactorización del código Netmiko en el servidor MCP

Antes de implementar el archivo env en nuestra clase de automatización de redes, primero resolveremos el problema del código duplicado. Si revisamos las tools actuales del servidor MCP, encontramos que el diccionario de conexión Netmiko, el bloque try/except y el context manager se repiten en cada herramienta. Lo único que cambia entre una tool y otra es el comando exacto que se ejecuta sobre el dispositivo de red. Refactorizaremos este patrón sacando el código repetido a una función auxiliar reutilizable que centraliza toda la lógica de conexión al dispositivo.

Después, un detalle importante que veremos en la práctica, es que esta función auxiliar no llevará el decorador @srvmcp.tool() porque no es una herramienta que la IA deba invocar directamente. Es una función interna que utilizan nuestras propias tools por debajo, sin que el modelo de IA necesite saber que existe. El resultado es que cada tool pasa de varias líneas a apenas dos o tres, y agregar una nueva herramienta de lectura sobre el switch se reduce a definir su docstring y devolver el comando correspondiente a través de la función auxiliar.

Archivo .env para credenciales en automatización de redes

Después entraremos a la parte de seguridad. Tener las credenciales del switch definidas directamente en el archivo de Python crea un problema obvio, ese archivo puede terminar compartido con un colega, subido a un repositorio, o estar disponible para cualquiera que tenga acceso a la máquina. En el momento en que el archivo sale de nuestro control, las credenciales del equipo de red salen con él. La técnica del archivo .env resuelve este problema separando completamente las credenciales del código de funcionamiento.

Veremos paso a paso cómo crear el archivo .env con la sintaxis correcta, qué reglas debe seguir para que python-dotenv lo interprete bien, y cómo modificar el código del servidor para que las credenciales se carguen dinámicamente desde el entorno en lugar de estar escritas. Abordaremos también el rol de tres componentes que aparecen en el código (os, Path y load_dotenv), explicando qué hace cada uno para que podamos proteger las credenciales del dispositivo de red.

Patrón escalable para añadir nuevas tools de red

Para cerrar la clase veremos el resultado del trabajo de refactorización: lo rápido que se vuelve añadir nuevas tools al servidor MCP. Una vez establecido el código re utilizable, crear una herramienta adicional que consulte la tabla de enrutamiento, las VLANs, las interfaces troncales o cualquier otra información del switch se reduce a un par de líneas.

¿Qué esperas? ¡Suscríbete!