Microsoft enseña a construir servidores MCP con Python

El Model Context Protocol, que Anthropic publicó como estándar abierto a finales de 2024, lleva tiempo fuera del jardín de su creador. La confirmación más reciente llega de Redmond: Microsoft ha sacado una serie de vídeos sobre cómo construir servidores MCP con Python y Azure, dirigida a desarrolladores que quieren exponer sus propios datos y servicios a un modelo.

El detalle relevante no es el formato, es el emisor. Un protocolo deja de ser una propuesta y empieza a ser infraestructura cuando lo documenta y lo enseña alguien que no lo inventó, y más aún cuando lo hace con su propia nube como destino de despliegue. Microsoft ya había incorporado MCP a sus herramientas de desarrollo durante 2025; publicar formación específica en Python es el paso siguiente y el más aburrido, que suele ser buena señal.

Qué hace un servidor MCP, en corto

Un servidor MCP expone tres cosas a un cliente compatible: tools (funciones que el modelo puede llamar), resources (datos que puede leer) y prompts (plantillas reutilizables). El cliente, que puede ser Claude Desktop, Claude Code u otro, descubre esas capacidades en tiempo de ejecución en lugar de tenerlas cableadas en el código.

La alternativa, que es lo que hacíamos todos antes, era escribir una integración a medida por cada combinación de aplicación y herramienta. Con MCP se escribe el servidor una vez y lo consume cualquier cliente que hable el protocolo. Es una idea sencilla, y en esa sencillez está buena parte de su adopción.

Dónde se complica: del stdio local al servidor remoto

Montar un servidor MCP local en Python es rápido. En nuestra experiencia, el SDK oficial resuelve el andamiaje y con unas pocas decenas de líneas ya tienes tools respondiendo desde Claude Code. Ese tramo es el que aparece en cualquier tutorial.

El problema llega al sacarlo del portátil. Un servidor que corre por stdio en la máquina del desarrollador no necesita autenticación, ni gestión de secretos, ni control de concurrencia, ni trazas. Uno remoto, compartido por un equipo, necesita las cuatro cosas. Ahí es donde entra la parte de Azure: identidad gestionada, almacén de secretos, hosting con escalado y logs centralizados. Es trabajo de plataforma clásico, poco lucido, y es exactamente donde se atascan los equipos que solo han visto el ejemplo de juguete.

Para quién es útil

Para equipos con Python en producción y datos en Azure, una combinación muy común en banca, seguros y administración pública en España. Para desarrolladores que ya usan Claude Code a diario con servidores MCP de terceros y quieren escribir el suyo. Y para quien tenga que justificar internamente que el protocolo no es una apuesta arriesgada: cuando Microsoft publica formación oficial, la conversación con el comité de arquitectura cambia de tono.

Conviene templar la expectativa. Un curso en vídeo no resuelve el diseño de tu servidor. Las decisiones difíciles siguen siendo qué operaciones expones y cuáles no, cómo delimitas permisos por usuario, y cómo evitas que el modelo alcance una tool destructiva sin confirmación humana. Eso no lo da el SDK.

Cómo encaja con el resto del ecosistema

Un servidor MCP se conecta a Claude Desktop a través de claude_desktop_config.json, o se añade directamente desde Claude Code. A partir de ahí convive con las demás piezas: skills para empaquetar instrucciones y contexto reutilizables, subagentes para delegar tareas concretas, hooks para ejecutar comandos en eventos del ciclo de vida y plugins para distribuir todo junto. El servidor MCP es la puerta hacia fuera; el resto organiza lo que pasa dentro.

Llevamos meses construyendo servidores MCP para clientes y el patrón se repite: la parte de protocolo se resuelve en una tarde y la de permisos, despliegue y auditoría se lleva el resto del proyecto. Material como el de Microsoft ayuda a cruzar el primer tramo, que es justo el que menos cuesta.