132 — MCP: tools, resources y prompts

← Clase anterior · Índice de la parte · Clase siguiente →

Parte: 10 — Sistemas multiagente e interoperabilidad
Nivel: experto · Horas estimadas: 6
Laboratorio: workflow · Estado: EXECUTABLE_CORE

🎯 Propósito

Comprender mcp: tools, resources y prompts dentro de la evolución de la inteligencia artificial, implementar un experimento mínimo verificable y distinguir qué parte constituye evidencia frente a una afirmación todavía no comprobada.

📚 Resultados de aprendizaje

Al finalizar podrás:

Explicar mcp: tools, resources y prompts usando los conceptos MCP, tools, resources, prompts.
Ejecutar el laboratorio con una semilla explícita y revisar su contrato JSON.
Identificar al menos un supuesto, una limitación y un riesgo de aplicación.
Comparar el enfoque con la etapa anterior de la ruta de aprendizaje.
Producir una evidencia reproducible y una conclusión que no exceda los datos.

🧩 Conceptos centrales

MCP, tools, resources, prompts

🗺️ Ubicación en el mapa de la IA

Antes de MCP, conectar m aplicaciones LLM con n fuentes de datos/herramientas exigía m×n integraciones a medida. El Model Context Protocol (anunciado por Anthropic en noviembre de 2024 y adoptado después por los principales proveedores) estandariza esa frontera: un protocolo abierto para que cualquier cliente hable con cualquier servidor de contexto — el problema pasa de m×n a m+n. Es la materialización de los contratos de la clase 131, y el complemento "agente↔herramientas" del A2A "agente↔agente" que verás en la 131.

📖 Fundamentos

🏗️ Arquitectura: host, cliente, servidor

Host: la aplicación LLM (Claude Desktop, un IDE, tu agente) que orquesta y aplica las políticas de seguridad y consentimiento.
Cliente MCP: componente dentro del host que mantiene una conexión 1:1 con cada servidor.
Servidor MCP: programa que expone capacidades (tools, resources, prompts) sobre una fuente concreta: un sistema de archivos, GitHub, una base de datos.

La capa de mensajes es JSON-RPC 2.0 con un ciclo de vida explícito: initialize (negociación de versión y capacidades: cada lado declara qué soporta) → operación (requests/responses y notificaciones) → cierre. Transportes estándar: stdio (proceso local) y HTTP con streaming (remoto).

🧰 Las tres primitivas del servidor

Primitiva	Quién decide usarla	Análogo	Ejemplo
Tool	El modelo (model-controlled)	Función POST con efectos	`create_issue`, `query_db`
Resource	La aplicación (app-controlled)	GET de solo lectura, direccionable por URI	`file:///repo/README.md`
Prompt	El usuario (user-controlled)	Plantilla parametrizada invocable	`/summarize_pr`

Tools: se descubren con tools/list (nombre, descripción, inputSchema en JSON Schema) y se invocan con tools/call. Pueden tener efectos laterales; por eso la spec exige consentimiento humano en el host para operaciones sensibles.
Resources: datos identificados por URI que la aplicación inyecta como contexto (resources/list, resources/read, suscripciones a cambios). Sin efectos: leer no ejecuta.
Prompts: plantillas con argumentos que el usuario invoca explícitamente (prompts/list, prompts/get) — flujos empaquetados por el autor del servidor.

La distinción de quién controla cada primitiva es la decisión de diseño central del protocolo: separa lo que el modelo puede decidir hacer (tools, con permiso) de lo que la app decide mostrar (resources) y de lo que el usuario decide lanzar (prompts).

🔁 Primitivas del cliente y seguridad

El protocolo es bidireccional. El servidor puede pedirle al host: sampling (solicitar una completion al LLM del host — el servidor usa inteligencia sin tener API key propia), elicitation (pedir información al usuario) y logging. El host conserva el control: la spec obliga a que el usuario apruebe tools sensibles y a que el servidor nunca vea la conversación completa; un servidor malicioso es parte del modelo de amenazas (tool poisoning, exfiltración por descripciones), de ahí la revisión de servidores de terceros antes de conectarlos.

🧮 Ejemplo trabajado

Flujo completo host ↔ servidor de archivos (mensajes abreviados):

→ initialize        {protocolVersion, capabilities: {tools: {}, resources: {}}}
← initialize.result {serverInfo: "fs-server", capabilities: {tools: {listChanged}, resources: {}}}
→ notifications/initialized

→ tools/list
← [{name: "read_file",
    description: "Lee un archivo de texto del workspace",
    inputSchema: {type: "object",
                  properties: {path: {type: "string"}},
                  required: ["path"]}}]

  (el usuario pregunta: "¿qué dice el CHANGELOG?")
  el modelo decide invocar la tool; el host pide confirmación si es sensible

→ tools/call        {name: "read_file", arguments: {path: "CHANGELOG.md"}}
← result            {content: [{type: "text", text: "## v2.41 ..."}], isError: false}

  el host inyecta el contenido al contexto del modelo → respuesta al usuario

Los dos errores posibles viven en capas distintas y se señalizan distinto: error de protocolo (tool inexistente → error JSON-RPC) y error de ejecución (archivo no encontrado → isError: true dentro de un result válido, para que el modelo pueda leerlo y reaccionar — reintentar con otra ruta, avisar al usuario).

📊 Propiedades y comparación

Enfoque	Acoplamiento	Descubrimiento	Estandarización	Coste de integrar n fuentes
Function calling ad hoc por app	Alto (cada app define sus tools)	No	Por proveedor	O(m×n)
Plugins propietarios	Medio	Catálogo cerrado	Por plataforma	O(n) por plataforma
MCP	Bajo (protocolo abierto)	`tools/list` dinámico en runtime	JSON-RPC + spec versionada	O(m+n)
A2A (clase 134)	Bajo	Agent Card	Complementario: agente↔agente	O(m+n)

flowchart LR
    subgraph HOST[Host: aplicación LLM]
        LLM[Modelo] --- C1[Cliente MCP 1] & C2[Cliente MCP 2]
        POL[Política: consentimiento,
permisos por tool]
    end
    C1 <-- "JSON-RPC (stdio)" --> S1[Servidor fs
tools: read_file
resources: file://...]
    C2 <-- "JSON-RPC (HTTP stream)" --> S2[Servidor GitHub
tools: create_issue
prompts: /review_pr]
    S1 -.sampling: pide completion.-> HOST
    S2 --- API[(API GitHub)]

⚠️ Errores conceptuales frecuentes

"MCP es una librería de funciones." Es un protocolo con ciclo de vida, negociación de capacidades y transporte; las tools son una de sus tres primitivas.
Tratar resources como tools. Un resource es lectura direccionable por URI que controla la aplicación; convertir todo en tools cede al modelo decisiones que no le corresponden.
Ignorar la distinción de errores. isError: true es un resultado que el modelo debe ver y manejar; el error JSON-RPC es fallo de protocolo para el cliente. Mezclarlos rompe la recuperación.
Conectar servidores de terceros sin revisión. Las descripciones de tools entran al contexto del modelo: un servidor malicioso puede inyectar instrucciones (tool poisoning); el host debe tratar los servidores como código no confiable.
Suponer que el servidor ve la conversación. El servidor solo recibe las invocaciones y lo que sampling le devuelve filtrado por el host; el aislamiento es una garantía del diseño.

🚀 Del aprendizaje a la operación

Operar MCP en serio implica: gestionar el ciclo de vida de los procesos servidor (supervisión, reinicio); autenticación y autorización por servidor (OAuth en transportes HTTP); presupuestos y auditoría por tool (quién invocó qué, con qué argumentos); revisión de seguridad de cada servidor de terceros antes de habilitarlo; y versionado — la spec evoluciona por fechas (p. ej. 2025-06-18) y la negociación de initialize debe manejar clientes y servidores en versiones distintas.

🧪 Laboratorio

python lab.py

El laboratorio llama a ai_evolution.labs.run_lab("workflow"). Esta decisión evita 183 implementaciones divergentes: cada clase tiene un entrypoint propio, pero los motores didácticos se prueban como una biblioteca común.

🔍 Evidencia esperada

tipo de laboratorio y semilla;
entradas o decisiones observables;
resultado estructurado;
lista evidence con hechos que pueden inspeccionarse;
lista limitations que impide presentar la demo como producción.

📓 Notebooks

📓 notebook.ipynb: recorrido guiado con la materia resumida.
✍️ notebook_student.ipynb: ejercicios para resolver.
✅ notebook_solution.ipynb: solución de referencia explicada.

📝 Evaluación

Criterio	Peso
Comprensión conceptual	25 %
Ejecución reproducible	25 %
Interpretación basada en evidencia	25 %
Riesgos, límites y mejora propuesta	25 %

Consulta assessment.md para preguntas y criterio de aceptación.

⚠️ Errores comunes

Síntoma	Causa probable	Corrección
El código corre, pero no hay conclusión	Se confundió ejecución con aprendizaje	Explica qué demuestra y qué no demuestra
El resultado cambia sin explicación	No se registró semilla o configuración	Conserva semilla, versión y parámetros
Se promete uso real	Se extrapoló desde una demo educativa	Declara entorno, datos, límites y revisión humana
Se copia una métrica aislada	No existe baseline ni costo de error	Añade comparación y criterio de decisión

❓ Preguntas frecuentes

¿Debo usar una API comercial?
No. El núcleo funciona localmente. Las extensiones LIVE se documentan por separado.

¿El laboratorio representa una implementación industrial?
No por sí solo. Enseña el contrato y el patrón; producción exige integración, seguridad, observabilidad, pruebas y operación.

¿Dónde profundizo?
Revisa las especializaciones enlazadas en el README raíz y la ruta siguiente.

🔗 Referencias

Model Context Protocol — introducción: documentación oficial del protocolo.
MCP — especificación (2025-06-18): arquitectura, ciclo de vida, primitivas y requisitos de seguridad.
MCP — Tools, Resources y Prompts: las tres primitivas del servidor.
Anthropic — Introducing the Model Context Protocol (2024): anuncio y motivación m×n → m+n.
JSON-RPC 2.0: la capa de mensajes sobre la que se define MCP.

📜 Papers que fundamentan esta clase

Bloque generado por python scripts/link_papers_to_classes.py. La fuente es papers/catalog/papers.json.

Paper	Año	Qué desbloqueó	Miniatura
P16 · Sistemas agentic contemporáneos: memoria, reflexión, multiagente e interoperabilidad	2023	El agente deja de ser un bucle y pasa a ser un sistema: memoria, reflexión, planificación, presupuesto, múltiples agentes y protocolos de interoperabilidad.	notebook

Cada ficha explica el problema anterior, la matemática mínima, los límites y los errores de atribución más frecuentes. Para leerlas con método: cómo leer un paper de IA · anexos matemáticos.

📚 Bibliografía de apoyo

Bloque generado por python scripts/link_sources_to_classes.py. Cada obra lleva su localizador verificado en sources/bibliography.json.

Los papers dicen de dónde salió el mecanismo. Estas obras lo desarrollan con el espacio que una clase no tiene: teoría completa, demostraciones y ejercicios.

Obra	Edición	Localizador	Papel en esta clase
Michael J. Wooldridge — An Introduction to MultiAgent Systems	2009	ISBN 9780471496915	obra de referencia de la parte 10 · toda la parte
Russell, Stuart J. y Norvig, Peter — Artificial Intelligence: A Modern Approach	4.ª · 2020	ISBN 9780134610993 · web de la obra	obra de referencia de la parte 10 · decisión multiagente y teoría de juegos

Normas y documentación oficial que aplica esta clase: Model Context Protocol · MCP · Model Context Protocol

⬅️ Clase anterior

131 — Contratos de roles, capacidades y resultados

➡️ Siguiente clase

133 — Agent Skills como capacidades portables

📝 Evaluación completa

❓ Preguntas

Define mcp: tools, resources y prompts sin usar una marca o framework como definición.
Explica la relación entre MCP, tools, resources, prompts.
Ejecuta lab.py dos veces con la misma semilla. ¿Qué debe conservarse?
Identifica una afirmación permitida y una afirmación exagerada sobre el resultado.
Propón una prueba negativa o un caso límite.

🏆 Reto verificable

Amplía el resultado del laboratorio con una clave student_extension que incluya:

el supuesto que estás probando;
una medición o comprobación;
la conclusión;
una limitación.

✅ Criterio de aceptación

[ ] lab.py termina con código 0.
[ ] El resultado contiene kind, seed, evidence y limitations.
[ ] La extensión no modifica el comportamiento de otras clases.
[ ] La interpretación referencia datos impresos por el laboratorio.
[ ] Se declara al menos un riesgo o condición de no uso.