🐍 Creando tu primer MCP Server

Un MCP Server está compuesto por componentes esenciales: el objeto FastMCP, que lo gestiona todo; las funciones decoradas, que definen tools, resources y prompts; y el punto de entrada, que inicia el servidor. Cada parte tiene una responsabilidad clara.

Conocer la anatomía de un server te permite entender cualquier código MCP que encuentres y crear tus propios servers con confianza, sabiendo dónde encaja cada pieza.

FastMCP, objeto server, decorators, punto de entrada, componentes, responsabilidades.

La inicialización de un MCP Server implica crear la instancia FastMCP con un nombre, configurar parámetros opcionales como la versión y la descripción, y preparar el entorno para recibir conexiones. En la configuración se registra todo.

Una configuración bien hecha garantiza que tu server funcione correctamente desde el primer momento. Los errores de inicialización son los más difíciles de diagnosticar si no entiendes el proceso.

FastMCP(), nombre del server, parámetros de configuración, instanciación, configuración inicial.

Registrar tools es el proceso de decorar funciones de Python con @mcp.tool() para que estén disponibles para el modelo de IA. El decorator extrae automáticamente el nombre, la descripción y el schema de parámetros de la función.

El registro de tools es la operación más fundamental de un MCP Server. Dominar este proceso es esencial para crear servers que expongan funcionalidades útiles al modelo.

@mcp.tool(), registro automático, introspección de funciones, schema generation, decorators de Python.

El ciclo de vida de un MCP Server incluye: inicialización, handshake con el Client, registro de capabilities, espera de solicitudes, procesamiento de llamadas y cierre ordenado. Cada fase tiene eventos y comportamientos específicos.

Entender el ciclo de vida permite crear servers robustos que gestionan correctamente cada fase, incluidos el inicio y el cierre limpios.

Lifecycle, handshake, capabilities, request loop, graceful shutdown, eventos del ciclo.

La estructura de archivos de un MCP Server típico incluye el archivo principal del server, un pyproject.toml o requirements.txt para las dependencias y, de forma opcional, módulos separados para las tools complejas. Los servers sencillos pueden constar de un solo archivo.

Una buena organización de archivos facilita el mantenimiento, las pruebas y la colaboración. Seguir convenciones permite que otros desarrolladores entiendan rápidamente tu server.

Estructura del proyecto, archivo principal, dependencias, pyproject.toml, módulos, organización.

Las configuraciones esenciales de un MCP Server incluyen el nombre del server, la versión, el transporte utilizado y las variables de entorno. Estas configuraciones definen cómo se presenta el server ante el Client y cómo se comporta en distintos entornos.

Configurar correctamente tu server garantiza la compatibilidad con distintos Hosts y entornos. Las configuraciones incorrectas son una causa común de problemas de conexión.

Nombre y versión, transporte, variables de entorno, configuración del Host, compatibilidad.

El objetivo es crear el MCP Server más sencillo posible: un server con una sola tool que devuelve "¡Hola, mundo!". Este es el equivalente de Hello World para el ecosistema MCP: lo mínimo funcional que demuestra que todo está funcionando.

Empezar con lo mínimo funcional elimina la complejidad y permite enfocarse en lo esencial. Una vez que funciona Hello World, tienes una base sólida para agregar features.

Hello World, mínimo funcional, prueba de concepto, base de aprendizaje, simplicidad.

Crear el archivo del server implica definir el directorio del proyecto, crear el archivo Python principal (por ejemplo, server.py) y asegurarse de que el entorno virtual esté configurado con las dependencias correctas instaladas mediante pip.

Saber crear correctamente la estructura inicial evita problemas de importación, dependencias y ejecución. Es la base sobre la que se construye todo lo demás.

Creación del proyecto, server.py, entorno virtual, pip install, estructura de directorios.

El código del Hello World MCP consiste en importar FastMCP, crear la instancia del server, definir una función decorada con @mcp.tool() que devuelve "¡Hola, mundo!", y agregar el punto de entrada con mcp.run(). Son menos de 10 líneas de código.

Escribir el código desde cero, en vez de copiarlo y pegarlo, garantiza que entiendas cada línea. Este es el conocimiento fundamental que ampliarás en todos los módulos siguientes.

from mcp.server.fastmcp import FastMCP, instanciación, @mcp.tool(), return string, mcp.run().

Para que Claude Desktop reconozca tu server, debes agregarlo a claude_desktop_config.json. La entrada incluye el comando para ejecutar Python, la ruta al archivo del server y, opcionalmente, variables de entorno.

La configuración en el Host es el paso que conecta tu código con el modelo de IA. Sin ella, tu server existe, pero nadie puede usarlo. Es el puente entre el desarrollo y el uso real.

claude_desktop_config.json, mcpServers, command, args, ruta del script, reiniciar Claude.

Probar el Hello World implica reiniciar Claude Desktop, verificar que el server aparezca en la lista de conexiones y enviar un mensaje que active la tool. Claude debe llamar a tu tool y mostrar «¡Hola, mundo!» en la respuesta.

Ver tu primer server funcionando es el momento más motivador del curso. Confirmar que todo funciona te da confianza para construir servers más complejos.

Prueba manual, verificación de conexión, tool calling, respuesta esperada, troubleshooting básico.

Un análisis línea por línea del código Hello World: el import incorpora el framework, FastMCP() crea el server, @mcp.tool() registra la función, la docstring se convierte en la descripción de la tool, el return define la respuesta y mcp.run() inicia el ciclo de eventos.

Entender cada línea en profundidad transforma el código memorizado en conocimiento real. Sabrás modificar y ampliar cualquier parte del server con seguridad.

Import statement, instanciación, decorator pattern, docstring como metadata, event loop, ejecución.

Los decorators en Python son funciones que envuelven otras funciones y agregan comportamiento sin modificar el código original. El símbolo @ antes de una función indica que está siendo decorada. En MCP, los decorators registran funciones como tools, resources o prompts.

Los decorators son el mecanismo central de FastMCP. Sin entenderlos, el código parece mágico. Con este conocimiento, controlas exactamente lo que está sucediendo.

Decoradores de Python, @syntax, funciones wrapper, metaprogramación, registro automático.

El decorator @mcp.tool() transforma una función Python común en una tool MCP. Extrae el nombre de la función, su docstring como descripción y los type hints de los parámetros como esquema de entrada. También acepta parámetros opcionales para personalizar el registro.

@mcp.tool() es el decorator que usarás en el 90% de los casos. Dominar sus opciones y comportamientos te permite crear tools precisas y bien documentadas.

@mcp.tool(), nombre automático, docstring como descripción, type hints, parámetros opcionales.

Los schemas de parámetros definen los tipos de entrada que acepta una tool. FastMCP usa las sugerencias de tipo de Python (str, int, float, bool, list, dict) para generar automáticamente el JSON Schema que el modelo usa para construir llamadas correctas.

Los schemas bien definidos garantizan que el modelo envíe datos en el formato correcto. Sin schemas adecuados, tus tools reciben datos inesperados y fallan silenciosamente.

JSON Schema, sugerencias de tipo, str, int, float, bool, Optional, parámetros obligatorios frente a opcionales.

Las tools MCP pueden devolver cadenas simples, diccionarios que se serializan en JSON o listas de contenido con tipos específicos (texto, imagen, etc.). El tipo de retorno define cómo el modelo interpreta y presenta el resultado al usuario.

Elegir el tipo de retorno adecuado influye en cómo el modelo usa el resultado. Los retornos bien formateados permiten que el modelo genere respuestas más precisas y útiles.

Return string, return dict, TextContent, ImageContent, serialización, formato de respuesta.

Las descripciones de las tools provienen de las docstrings de las funciones de Python. El modelo lee esas descripciones para decidir cuándo y cómo usar cada tool. Las descripciones claras y específicas ayudan al modelo a usar sus tools de forma más inteligente y precisa.

La calidad de las descripciones influye directamente en la calidad de las interacciones. El modelo ignorará o usará incorrectamente una tool con una descripción deficiente.

Docstrings, descripción de tool, descripción de parámetros, ingeniería de prompts para tools, claridad.

Las buenas prácticas para tools de MCP incluyen: nombres descriptivos en snake_case, docstrings detalladas, type hints en todos los parámetros, valores predeterminados cuando tenga sentido, respuestas informativas y un manejo coherente de errores.

Seguir buenas prácticas desde el inicio crea hábitos que dan como resultado servers más robustos, más fáciles de mantener y más eficaces al interactuar con el modelo.

Convenciones de nomenclatura, documentación, seguridad de tipos, valores predeterminados, manejo de errores, consistencia.

Planificar las tools de la calculadora implica definir 4 operaciones matemáticas (sumar, restar, multiplicar, dividir), sus parámetros (dos números), los tipos de entrada (float) y comportamientos especiales, como la validación de la división por cero.

Planificar antes de programar es un hábito esencial. Definir la interfaz de las tools antes de implementarlas garantiza la coherencia y evita tener que rehacer el trabajo.

Planificación de API, definición de interfaz, parámetros coherentes, edge cases, validación.

Implementar suma y resta como tools MCP implica crear funciones decoradas que reciben dos parámetros float, realizan la operación y devuelven el resultado formateado. Son las tools más simples y sirven como modelo para las siguientes.

Empezar con las operaciones más sencillas permite enfocarse en el patrón de implementación. Una vez que funcionan la suma y la resta, la multiplicación y la división siguen el mismo modelo.

Implementación de tools, parámetros float, retorno formateado, docstrings descriptivas, patrón replicable.

La tool de multiplicación sigue el mismo patrón que las anteriores, pero brinda la oportunidad de hablar sobre el formato de resultados con muchos decimales y sobre cómo presentar números grandes de forma legible para el modelo.

La multiplicación parece trivial, pero plantea cuestiones prácticas sobre el formato y la precisión numérica que son relevantes para cualquier tool que trabaje con números.

Multiplicación, formato numérico, precisión decimal, números grandes, presentación del resultado.

La tool de división introduce el primer caso real de validación de entrada: verificar si el divisor es cero antes de ejecutar la operación. Esto muestra cómo manejar errores con elegancia y devolver mensajes informativos al modelo.

La validación de entrada es una habilidad crítica para cualquier server. La división por cero es el ejemplo perfecto para introducir el concepto de cómo las tools deben manejar entradas no válidas.

Validación de entrada, división por cero, mensaje de error, retorno condicional, robustez.

Probar todas las tools de la calculadora implica verificar cada operación con diferentes tipos de entradas: números enteros, decimales, negativos, cero y números muy grandes. Incluye probar el caso de división por cero para confirmar que la validación funciona.

Las pruebas exhaustivas garantizan que tu server funcione en todos los escenarios. Crear el hábito de probar con distintos inputs evita bugs en producción.

Pruebas manuales, casos de prueba, edge cases, inputs variados, verificación de validación.

Mejorar la calculadora con un manejo de errores sólido incluye: agregar try/except para capturar excepciones inesperadas, validar los tipos de entrada, limitar el tamaño de los números aceptados y devolver mensajes de error estandarizados que el modelo pueda interpretar.

Transformar un prototipo funcional en código robusto es una habilidad profesional. Este paso muestra cómo hacer que tu server pase de «funciona» a «funciona siempre».

Try/except, validación robusta, límites de entrada, mensajes de error estandarizados, programación defensiva.

Elegir una API meteorológica gratuita y confiable es el primer paso para construir el servidor. APIs como Open-Meteo ofrecen datos meteorológicos sin necesidad de una clave de API, lo que hace que la configuración sea más sencilla y accesible para aprender.

Saber elegir y evaluar APIs externas es una habilidad fundamental. Muchos MCP Servers en la práctica son wrappers que conectan modelos de IA con APIs existentes.

API del clima, Open-Meteo, API gratuita, endpoints, documentación de API, límites de solicitudes.

Hacer solicitudes HTTP dentro de un MCP Server requiere bibliotecas asíncronas como httpx, ya que FastMCP se ejecuta en un event loop asyncio. Las solicitudes obtienen datos de la API y devuelven respuestas JSON que deben parsearse.

Las solicitudes HTTP son la base de cualquier integración con servicios externos. Dominar las llamadas asíncronas garantiza que tu server no se bloquee mientras espera respuestas de APIs.

httpx, async/await, solicitud GET, análisis de JSON, headers, parámetros de consulta.

Implementar la tool de clima implica crear una función async decorada que recibe el nombre de la ciudad como parámetro, realiza la solicitud a la API, extrae los datos relevantes (temperatura, humedad, condición) y devuelve una cadena formateada con la información.

Esta es la primera tool que conecta tu server con el mundo externo. El patrón de recibir input, buscar datos y formatear la respuesta se usa en el 80% de los MCP Servers reales.

async def, parámetro ciudad, llamada a la API, extracción de datos, formato de la respuesta.

Formatear la respuesta significa transformar datos sin procesar de la API en una cadena organizada y legible. Esto incluye presentar la temperatura con unidades, la condición climática en texto descriptivo y la información adicional de forma estructurada para que el modelo la interprete.

La calidad del formato determina qué tan bien interpreta y presenta el modelo los datos al usuario. Los datos bien formateados generan respuestas más naturales e informativas.

Formato de datos, f-strings, unidades de medida, estructuración de la información, legibilidad.

Los errores de red son inevitables: la API puede estar fuera de servicio, la conexión puede interrumpirse o la respuesta puede llegar en un formato inesperado. Para tratar estos errores se usan try/except para httpx.HTTPError, tiempos de espera configurables y mensajes de error informativos.

Las tools que dependen de APIs externas deben ser resilientes. Sin manejo de errores, una falla de red hace caer todo el server en lugar de devolver un mensaje útil.

HTTPError, timeout, ConnectionError, lógica de reintentos, fallback, mensaje de error amigable.

Probar con Claude implica preguntar sobre el clima en diferentes ciudades y verificar que el modelo llama a la tool correctamente, recibe los datos y presenta la información de forma natural al usuario. Incluye probar con ciudades inexistentes para validar el manejo de errores.

La prueba con Claude es la prueba real de integración. Muestra cómo el modelo decide cuándo usar tu tool y cómo interpreta los resultados que devuelve.

Prueba de integración, interacción con Claude, tool calling real, validación end-to-end, escenarios de error.

En el código, los Resources son funciones decoradas con @mcp.resource() que devuelven datos cuando se accede a ellas mediante una URI específica. A diferencia de las tools, los resources no ejecutan acciones: exponen información que el modelo puede leer para enriquecer su contexto.

Los Resources son el segundo pilar de un MCP Server. Implementarlos en el código complementa los conocimientos teóricos de la Trilha 1 y amplía las capacidades de tu server.

@mcp.resource(), URI, retorno de datos, exposición de contexto, diferencia con las tools.

Los Resources estáticos siempre devuelven el mismo contenido, como documentación, guías, configuraciones predeterminadas o cualquier dato que no cambie entre llamadas. Son los más fáciles de implementar e ideales como contexto de referencia.

Los Resources estáticos son la forma más sencilla de proporcionar contexto enriquecido al modelo. Pueden mejorar la calidad de las respuestas al darle al modelo información de referencia siempre disponible.

Contenido estático, documentación, configuraciones, guías de referencia, datos inmutables.

Los resources dinámicos calculan o buscan datos en cada acceso, como el estado actual del sistema, datos de una base de datos o información que cambia con el tiempo. Usan las mismas URIs, pero devuelven contenido actualizado.

Los resources dinámicos permiten que el modelo acceda a datos en tiempo real sin necesidad de hacer tool calls. Son ideales para dashboards, estados e información que cambia con frecuencia.

Contenido dinámico, datos en tiempo real, cálculo bajo demanda, actualización automática, freshness.

Los esquemas URI definen cómo se identifican y se accede a los resources. Cada resource tiene una URI única (p. ej., config://app/settings, data://users/list) que el Client usa para solicitar el contenido. El esquema indica el tipo y la ruta identifica el recurso específico.

Las URI bien diseñadas hacen que tus recursos sean intuitivos y organizados. Un buen esquema de URI facilita que el modelo descubra y use los recursos.

URI, esquema, ruta, identificación única, convenciones de nombres, jerarquía de recursos.

El protocolo MCP permite que el Client liste todos los resources disponibles en el Server mediante resources/list. Esto permite descubrirlos automáticamente: el modelo sabe qué datos están disponibles sin necesitar documentación externa.

El listado de resources es lo que hace que el protocolo se autodocumente. El modelo puede explorar los resources disponibles y elegir los más relevantes para cada situación.

resources/list, descubrimiento automático, autodocumentación, metadata de resources, listado dinámico.

Probar resources implica verificar que aparezcan en la lista, que se pueda acceder a sus URI, que el contenido devuelto sea correcto y que los resources dinámicos actualicen sus datos. La prueba puede hacerse mediante Claude o MCP Inspector.

Probar resources garantiza que el modelo tenga acceso a los datos correctos. Los resources que no funcionan pueden hacer que el modelo genere respuestas basadas en información desactualizada o incorrecta.

Prueba de resources, verificación de URI, contenido correcto, actualización dinámica, debugging.

En el código, los Prompts son funciones decoradas con @mcp.prompt() que devuelven plantillas de mensajes predefinidas. Pueden aceptar parámetros para personalizarlas y devuelven una lista de mensajes que guía el comportamiento del modelo.

Los prompts son el tercer pilar de MCP y el menos aprovechado. Implementarlos en el código completa tu dominio de las tres capacidades de un MCP Server.

@mcp.prompt(), plantillas de mensajes, parámetros, lista de mensajes, role (user/assistant).

Un prompt simple es una función que devuelve un mensaje fijo sin aceptar parámetros. Por ejemplo, un prompt que indica al modelo que actúe como revisor de código o asistente de depuración, con instrucciones detalladas sobre el comportamiento esperado.

Los prompts simples son el punto de partida más accesible. Demuestran el mecanismo sin la complejidad de los parámetros y permiten centrarse en la estructura y el formato.

Prompt sin parámetros, mensaje fijo, instrucción de comportamiento, formato de respuesta, simplicidad.

Los prompts con parámetros aceptan argumentos que personalizan el mensaje generado. Por ejemplo, un prompt de revisión de código que recibe como parámetros el lenguaje de programación y el enfoque de la revisión, y genera instrucciones específicas para cada caso.

Los prompts parametrizados son mucho más versátiles que los prompts fijos. Permiten crear plantillas reutilizables que se adaptan a distintos contextos con un solo código.

Parámetros de prompt, plantillas dinámicas, f-strings en prompts, personalización, reutilización.

Al igual que las tools y los resources, el Client puede listar los prompts mediante prompts/list. El listado muestra el nombre, la descripción y los parámetros aceptados por cada prompt, lo que permite al Host ofrecer al usuario una interfaz de selección.

El listado de prompts es la forma en que el Host descubre qué workflows están disponibles. Los prompts bien documentados aparecen claramente en la interfaz de usuario.

prompts/list, descubrimiento de prompts, metadata, descripción de parámetros, interfaz del Host.

Los mejores casos de uso para los prompts MCP incluyen: workflows estandarizados (code review, análisis de datos), onboarding de nuevos usuarios, instrucciones de dominio específico y templates que combinan el contexto de resources con instrucciones para usar tools.

Saber cuándo usar prompts vs. tools vs. resources es una decisión de diseño importante. Los prompts destacan en situaciones donde es necesario guiar el comportamiento del modelo de manera consistente.

Flujos de trabajo estandarizados, onboarding, instrucciones de dominio, combinación con tools y resources, consistencia.

Probar prompts implica verificar que aparezcan en la lista, que acepten parámetros correctamente y que los mensajes generados guíen al modelo según lo esperado. La prueba incluye verificar el comportamiento del modelo cuando se activa el prompt.

Los prompts mal probados pueden hacer que el modelo se comporte de forma inesperada. Probarlos garantiza que las instrucciones sean claras y produzcan el comportamiento deseado.

Prueba de prompts, validación de parámetros, verificación del comportamiento, calidad de las instrucciones, iteración.

Los errores en MCP Servers se dividen en categorías: errores de entrada (parámetros no válidos), errores de ejecución (fallas en la lógica), errores de red (APIs inaccesibles), errores del sistema (falta de memoria, disco lleno) y errores de protocolo (mensajes mal formados).

Clasificar los errores es el primer paso para tratarlos correctamente. Cada tipo de error requiere una estrategia de tratamiento diferente y un mensaje de respuesta adecuado.

Errores de entrada, errores de ejecución, errores de red, errores del sistema, clasificación, estrategia.

La validación de entrada es el proceso de comprobar que los parámetros recibidos sean válidos antes de ejecutar la lógica de la tool. Incluye verificar los tipos, los rangos, el formato de las cadenas, el tamaño de las listas y cualquier condición que deban cumplir los datos.

Validar la entrada es la primera línea de defensa contra errores. Es más fácil y seguro rechazar inputs incorrectos que lidiar con los errores en cascada que causan durante la ejecución.

Validación de entradas, verificación de tipos, verificación de rangos, retorno temprano, mensajes de rechazo claros.

Usar try/except en tools permite capturar excepciones durante la ejecución y devolver mensajes de error útiles en lugar de crashes. El patrón recomendado es capturar excepciones específicas, registrar el error y devolver un mensaje que el modelo pueda usar para informar al usuario.

Un try/except bien implementado marca la diferencia entre un server que falla y uno que se recupera con elegancia. Las excepciones sin manejar pueden hacer caer todo el server MCP.

try/except, excepciones específicas, logging, recuperación, mensaje de error como respuesta.

Los errores de red incluyen conexión rechazada, DNS sin resolver, tiempo de espera de conexión y respuestas HTTP con estado de error. Cada tipo requiere un tratamiento específico: reintentos para errores transitorios y una alternativa cuando la indisponibilidad se prolonga.

Si tu server depende de APIs externas, los errores de red son inevitables. Saber manejarlos garantiza que tu server siga siendo útil incluso cuando fallan los servicios externos.

ConnectionError, TimeoutError, códigos de estado HTTP, retry, fallback, circuit breaker.

Los timeouts limitan cuánto tiempo puede tardar una operación antes de cancelarse. En las tools MCP, es esencial configurar timeouts para llamadas de red, operaciones de disco y cualquier procesamiento que pueda bloquearse. asyncio.wait_for() es la herramienta estándar.

Sin timeouts, una tool puede quedar bloqueada indefinidamente, lo que bloquea el server y frustra al usuario. Los timeouts garantizan que el server siempre responda en un tiempo razonable.

asyncio.wait_for(), timeout configurable, TimeoutError, cancelación, tiempo de respuesta.

El logging en MCP Servers usa el módulo logging de Python para registrar eventos, errores e información de depuración. Los logs deben enviarse a stderr (no a stdout, que se usa para el protocolo). Niveles como DEBUG, INFO, WARNING y ERROR ayudan a filtrar la información.

Sin logs, depurar un MCP Server es como navegar a oscuras. Los logs de calidad son esenciales para diagnosticar problemas durante el desarrollo y en producción.

módulo logging, stderr frente a stdout, niveles de log, formato, depuración en producción, trazabilidad.

MCP Inspector es una herramienta oficial que permite conectarte a un MCP Server y probar sus tools, resources y prompts de forma interactiva, sin necesidad de un modelo de IA. Funciona como un Client MCP con interfaz visual.

El Inspector es la herramienta más eficiente para desarrollar y depurar MCP Servers. Te permite hacer pruebas rápidamente sin depender de Claude Desktop y acelera el ciclo de desarrollo.

MCP Inspector, herramienta de prueba, interfaz visual, MCP Client, desarrollo rápido.

MCP Inspector se puede ejecutar con npx sin instalarlo de forma permanente. El comando npx @modelcontextprotocol/inspector inicia la herramienta, que abre una interfaz web donde puedes conectarte a tu server y explorar sus capacidades.

Instalar y ejecutar el Inspector rápidamente es una habilidad práctica que agiliza todo tu flujo de trabajo de desarrollo MCP. Es una herramienta que usarás constantemente.

npx, @modelcontextprotocol/inspector, interfaz web, sin instalación permanente, Node.js.

Para conectar el Inspector a tu server, debes especificar el comando para iniciar el server (p. ej., python server.py), el transporte (generalmente STDIO) y hacer clic en conectar. El Inspector ejecuta el handshake de MCP y muestra todas las capabilities disponibles.

Saber conectar el Inspector a tu server es el paso fundamental para usarlo. La conexión revela de inmediato si hay problemas de inicio o configuración en tu server.

Conexión STDIO, comando de ejecución, handshake, capabilities, detección de problemas.

El Inspector permite seleccionar cualquier tool de la lista, completar sus parámetros manualmente y ejecutarla. El resultado aparece en la interfaz con todos los detalles: contenido devuelto, tiempo de ejecución y cualquier error que haya ocurrido.

Probar tools en Inspector es mucho más rápido que hacerlo mediante Claude. Puedes iterar rápidamente, probar casos límite y verificar que tus tools funcionen correctamente antes de integrarlas.

Ejecución manual, ingreso de parámetros, visualización del resultado, tiempo de ejecución, iteración rápida.

Analizar las respuestas en Inspector significa examinar el contenido devuelto por tools, resources y prompts en formato raw. Puedes ver exactamente el JSON que envía el server, incluidos los tipos de contenido, los metadatos y la estructura de la respuesta.

Ver las respuestas raw permite entender exactamente qué recibe el modelo. Esto es crucial para optimizar el formato y garantizar que las respuestas sean interpretables.

Respuestas raw, JSON, tipos de contenido, metadata, formato, análisis de output.

El Inspector muestra errores detallados cuando algo falla: stack traces de Python, errores de protocolo, timeouts y problemas de conexión. Junto con los logs del server, permite identificar rápidamente la causa raíz de cualquier problema.

La depuración eficiente es lo que distingue a un desarrollador productivo de uno que se queda bloqueado durante horas. El Inspector es tu herramienta principal para diagnosticar y resolver problemas en MCP Servers.

Stack traces, errores de protocolo, diagnóstico, causa raíz, corrección, ciclo debug-fix-test.