Tutorial de Model Context Protocol en Python: crea tu primer servidor MCP
Aprende Model Context Protocol en Python con un tutorial práctico de tu primer servidor, los conceptos centrales de MCP y la ruta más rápida desde scripts personalizados hasta herramientas de IA reutilizables.
La mayoría del contenido sobre MCP se queda en la gran idea: una forma estándar de conectar herramientas de IA con sistemas externos. Eso es útil, pero no ayuda demasiado cuando estás frente a un proyecto de Python preguntándote qué construir primero. Esta guía toma la ruta práctica. Si quieres entender Model Context Protocol Python lo suficientemente bien como para lanzar algo, el mejor punto de partida es un servidor pequeño que exponga una herramienta, un recurso y un caso de uso claro.
Ese enfoque tiene una fuerte intención de búsqueda ahora mismo porque los desarrolladores están superando los experimentos genéricos de “agentes de IA” y haciéndose una pregunta más concreta: ¿cómo conecto los modelos con archivos, API y lógica de negocio reales sin inventar cada vez una capa de pegamento personalizada? Si todavía estás construyendo tu primer agente, comienza con nuestra guía sobre Cómo crear agentes de IA con Python.
Por qué este tema es tendencia ahora
MCP ha pasado de ser una conversación de protocolo de nicho al flujo de trabajo principal de los desarrolladores.
Anthropic anunció en diciembre de 2025 que MCP estaba siendo donado a la Agentic AI Foundation con el apoyo de Anthropic, OpenAI, Microsoft, Google, AWS, Cloudflare, Block y Bloomberg. En el mismo anuncio, Anthropic afirmó que MCP tenía más de 10.000 servidores públicos activos y había sido adoptado por productos como ChatGPT, Cursor, Gemini, Microsoft Copilot y VS Code. Eso importa porque convierte a MCP de una idea interesante en un canal de distribución.
Para los desarrolladores de Python, el momento es especialmente bueno. La página oficial de SDK lista a Python como un SDK de Nivel 1, lo que indica un fuerte compromiso de mantenimiento y completitud de funciones. En otras palabras, el stack de Python para MCP ya no es una palabra clave especulativa. Se corresponde con un conjunto de herramientas que ya cuenta con documentación oficial, un SDK activo y patrones de implementación claros.
Qué les ofrece realmente MCP a los desarrolladores de Python
La forma más sencilla de pensar en MCP es esta: estandariza la frontera entre una aplicación de IA y el contexto o las acciones que puede usar.
El SDK oficial de Python describe tres bloques fundamentales para construir servidores:
- tools para las acciones que el modelo puede invocar
- resources para el contexto de solo lectura que la aplicación puede cargar
- prompts para plantillas de interacción reutilizables
Esa distinción es importante.
Tools
Las tools son la parte activa de tu integración. Pueden ejecutar código, llamar a API, escribir datos o desencadenar efectos secundarios. Si tu asistente necesita crear un ticket, consultar una API del clima o iniciar un trabajo, eso pertenece a una tool.
Resources
Los resources son la parte pasiva. Se comportan más como los endpoints GET de una API tradicional. Exponen contexto útil como documentación, configuración o datos de referencia sin mutar nada.
Prompts
Los prompts te permiten empaquetar instrucciones reutilizables o patrones de interacción para que los clientes puedan invocarlos de forma estructurada.
Esta separación es el verdadero valor. Antes de MCP, muchos equipos metían todo en un esquema de tool sobredimensionado o solo en la ingeniería de prompts. Con este protocolo, la arquitectura se vuelve más fácil de razonar y de reutilizar entre clientes.
En mi experiencia desplegando patrones de llamada a herramientas en Codiste, esta distinción entre tools y resources nos habría ahorrado un tiempo significativo de refactorización. Cuando construí un sistema de Document AI usando transformers ajustados, inicialmente expusimos el análisis de documentos tanto como una acción como una fuente de datos a través de la misma interfaz, lo que generó confusión sobre cuándo debía invocarlo el modelo frente a cuándo debía precargarse el contexto. Una separación a nivel de protocolo como la que impone MCP lo habría evitado por completo.
Construye primero un servidor MCP pequeño
El inicio rápido del SDK oficial de Python usa FastMCP, que es el lugar adecuado para empezar. Mantiene los detalles del protocolo fuera del camino para que puedas centrarte en la capacidad real que quieres exponer.
Instálalo con uv o con pip:
1
uv add "mcp[cli]"
o:
1
pip install "mcp[cli]"
Luego comienza con un servidor mínimo:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Demo", json_response=True)
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers."""
return a + b
@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
"""Return a greeting resource."""
return f"Hello, {name}!"
@mcp.prompt()
def greet_user(name: str) -> str:
return f"Write a friendly greeting for {name}."
if __name__ == "__main__":
mcp.run(transport="streamable-http")
Ese pequeño ejemplo enseña el modelo que deberías seguir para casi cualquier servidor real:
- define la capacidad
- clasifícala como tool, resource o prompt
- ejecuta el servidor con un transporte estándar
- conéctalo desde una aplicación host o un inspector
Este es el enfoque práctico de palabra clave que hace que valga la pena apuntar a Model Context Protocol Python. Quienes buscan normalmente no quieren un ensayo sobre el protocolo. Quieren un primer servidor funcional que puedan adaptar hoy.
Cuándo MCP es mejor que el pegamento de herramientas personalizado
Si solo necesitas un ayudante privado para una aplicación, una llamada directa al SDK puede ser suficiente. Pero MCP empieza a ganar en cuanto la reutilización y la interoperabilidad importan.
Usa MCP cuando:
- la misma capacidad debe funcionar en varios clientes de IA
- quieres un contrato limpio entre tu aplicación y tus herramientas
- tu equipo necesita que tools, resources y prompts se mantengan diferenciados
- esperas que la superficie de integración crezca con el tiempo
Evita la sobreingeniería cuando:
- estás probando un prototipo desechable
- la lógica está fuertemente acoplada a una sola aplicación y no se reutilizará
- aún no sabes si la capacidad merece una interfaz formal
La idea clave es que MCP no se trata solo del acceso al modelo. Se trata de empaquetar contexto y acciones de una manera que otros clientes puedan entender. Esa es una historia a largo plazo más sólida que escribir una y otra vez wrappers puntuales de llamada a funciones. Por ejemplo, podrías exponer un sistema RAG como un resource de MCP para que cualquier agente pueda consultar tu base de conocimiento.
Mejores prácticas para un comienzo apto para producción
El README oficial del SDK y la documentación de conceptos de servidor apuntan a algunos hábitos que vale la pena adoptar pronto.
Mantén las tools acotadas
No crees una sola tool llamada do_everything. Las tools más pequeñas son más fáciles de elegir correctamente para los modelos y más fáciles de probar para ti. Cuando construí flujos de trabajo de agentes de IA para segmentación de imágenes usando ControlNet, lo aprendí por las malas: una tool amplia “process_image” causaba un enrutamiento incorrecto constante, mientras que dividirla en “segment_image”, “apply_controlnet” y “postprocess_output” le dio al modelo límites de decisión claros.
Pon los datos de solo lectura en resources
Si algo debe cargarse como contexto en lugar de ejecutarse como una acción, exponlo como un resource. Eso mantiene clara la semántica.
Usa el contexto solo donde ayude
El SDK de Python admite la inyección de contexto para las tools, incluyendo informes de progreso y acceso a recursos gestionados por el ciclo de vida. Eso es potente, pero no lo necesitas en cada endpoint.
Comienza con un transporte y un cliente
El SDK admite transportes como stdio, SSE y Streamable HTTP. Elige un camino, demuestra el flujo de trabajo y luego expande. El OpenAI Agents SDK es un cliente que funciona bien con servidores MCP.
Prueba con herramientas estilo inspector
El inicio rápido apunta explícitamente al MCP Inspector como una forma de probar tu servidor antes de conectarlo a una aplicación host completa. Es un buen hábito porque aísla los problemas del protocolo de los problemas del producto.
Conclusión final
La razón por la que Model Context Protocol Python tiene un valor SEO real ahora mismo es simple: combina el impulso de la tendencia con una intención de implementación inmediata. Los desarrolladores escuchan sobre MCP en los principales productos de IA y luego se dan la vuelta para buscar la ruta más rápida de Python para usarlo ellos mismos.
Si ese es tu objetivo, no empieces con una plataforma de agentes completa. Empieza con un servidor MCP útil dentro de un proyecto de Python que ya entiendas. Expone una tool pequeña, añade un resource, pruébalo con el inspector y conéctalo al cliente que realmente usas.
Ese flujo de trabajo enseña el protocolo más rápido de lo que jamás lo hará la lectura abstracta. Una vez que funcione, puedes crecer desde un único servidor local hasta una interfaz reutilizable para herramientas internas, sistemas de documentación, flujos de trabajo de soporte o automatización para desarrolladores.
Si quieres un siguiente paso concreto esta semana, construye un pequeño servidor MCP en torno a una tarea que ya repites manualmente. Esa suele ser la ruta más corta de la curiosidad a algo genuinamente útil.
Publicaciones relacionadas
- Tutorial de OpenAI Agents SDK en Python - Crea flujos de trabajo multiagente que consumen tools y resources de MCP
- Cómo crear agentes de IA con Python - Entiende el bucle del agente, el uso de herramientas y los patrones de memoria que MCP estandariza
- RAG con Python: Retrieval-Augmented Generation - Construye un sistema de recuperación de conocimiento que puedas exponer como un resource de MCP
Fuentes
Machine Learning Engineer at Codiste, specializing in Generative AI, NLP, and Computer Vision. Building production AI systems with Python.