Lectura completa
Actividad: Gemini NotebookLM
Armen un cuaderno con las tres piezas de un agente: un system, herramientas y contexto.
En NotebookLM esas piezas tienen un lugar concreto. Las instrucciones del cuaderno funcionan como el system: fijan el comportamiento del asistente para todo lo que pase dentro de ese cuaderno. Las fuentes que suben son el contexto: el material sobre el que el cuaderno puede razonar. Y las herramientas del Studio, como el resumen en Audio o el mapa mental, son las funciones que el cuaderno puede ejecutar sobre ese material.
Con el correo UC, NotebookLM es gratis: notebooklm.google.com.
- Entren con el correo UC y creen un cuaderno
- Suban dos fuentes: las diapositivas de agentes, o sus notas
- Peguen este system en las instrucciones del cuaderno
- Usen una herramienta del Studio: Audio o mapa mental
El system que van a pegar obliga al cuaderno a contrastar cada afirmación con las fuentes antes de seguir, a usar los términos del curso y a decir cuándo falta una fuente en vez de inventar una cita.
System
Contrasta las afirmaciones con hechos. Si no estan en las fuentes del cuaderno, cuestiona antes de seguir.
Usa los terminos del curso: system, herramienta, agente, ciclo.
No inventes citas. Si falta una fuente, dilo.Definición
MCP es un acrónimo para Model Context Protocol. Es un protocolo creado por Anthropic, diseñado para que los LLMs puedan tener más capacidades, a través de herramientas, recursos y plantillas (prompts).
La idea de fondo es entregar un mejor contexto al modelo para actuar sobre la solicitud del usuario. En vez de que cada aplicación invente su propia manera de conectar datos y funciones, el protocolo define una forma estándar: a un lado quedan las aplicaciones de IA, al otro los datos y las herramientas, y el flujo entre ambos es bidireccional.
Se debe configurar en la interfaz del agente. Normalmente se configura a través de un JSON, o de un formulario que replica esa información en un JSON.
La figura sale de la introducción oficial: modelcontextprotocol.io.
Pero, ¿qué es un protocolo?
Antes de abrir cliente y servidor, conviene detenerse en la palabra protocolo. Un protocolo es un conjunto de reglas compartidas. Dos sistemas se hablan porque ambos ya saben qué pedir, qué responder y en qué formato viaja el mensaje. Nadie negocia el formato en el momento: estaba acordado antes de la primera conversación.
Si estudian enfermería ya conocen uno. El SBAR de un traspaso fija el orden de la entrega: situación, antecedentes, evaluación y recomendación. Quien entrega y quien recibe ya saben qué preguntar y cómo anotarlo. La herramienta está descrita en IHI: SBAR.
Otro protocolo que usan todos los días es HTTP: el navegador y el servidor ya saben cómo pedirse una página. La especificación completa está en RFC 9110 y una lectura más corta en MDN: Overview of HTTP.
MCP juega ese mismo papel entre un agente y las fuentes de datos o funciones que quiere usar: ambos lados ya saben qué pedir y en qué formato responder.
MCP: Cliente
El cliente de un MCP es la aplicación en el lado del usuario que gestiona la conexión y el consumo del MCP. Vive en la misma máquina (o aplicación) que el agente: la interfaz del agente conecta el agente con el cliente del MCP.
El cliente establece la conexión entre cliente y servidor y comunica los resultados al agente. Para conectarse se necesitan configuraciones que dependen del tipo de servidor.
Muchas aplicaciones tienen pre-configurados MCPs disponibles para ser activados, pero uno puede agregar MCPs personalizados o adicionales. Así se ve el formulario para agregar uno en GitHub Copilot:
MCP: Servidor
El servidor es la otra mitad del protocolo: una aplicación que gestiona y expone capacidades y recursos para que un cliente pueda utilizarlos y consumirlos.
El servidor es una entidad separada del cliente, y por ende es necesario que exista una interfaz de comunicación entre ambas partes. Esta interfaz, normalmente, es un JSON que se transmite entre ambos lados.
Un mismo servidor se instancia una sola vez pero gestiona múltiples conexiones con varios clientes. El dibujo muestra exactamente eso: un usuario en Claude y otro en ChatGPT, conectados al mismo servidor MCP, que expone prompts, recursos y herramientas.
MCP: Tipos de servidores
Existen dos tipos de servidores: locales y remotos. La diferencia es dónde corre el servidor respecto del cliente.
- Local: se despliega (ejecuta) en la misma máquina donde está el cliente, y la comunicación cliente/servidor ocurre dentro de esa misma máquina. Hay dos formas de lanzarlo.
- Por comando: se ejecuta con un comando (script) que se lanza desde una terminal. Todo esto ocurre en el fondo.
- Por URL: apunta a un servidor que ya se está ejecutando localmente en la misma máquina. Normalmente parten con localhost:xxxx, donde xxxx es un puerto como 3000.
- Remoto: corre en una máquina separada de donde se está ejecutando el cliente. La comunicación debe ser sí o sí a través de internet por un URL (http).
MCP: Ejemplos
Tres ejemplos, uno por cada forma de correr un servidor:
| Nombre | Tipo | Descripción |
|---|---|---|
| Filesystem | Local / comando | Expone una carpeta de tu máquina. Se lanza con npx -y @modelcontextprotocol/server-filesystem y corre en el fondo. |
| Servidor propio | Local / URL | Un MCP que ustedes corren en esta máquina. El cliente apunta a http://localhost:3000/mcp. |
| Canva | Remoto | Crea y exporta diseños. La conexión va por el URL https://mcp.canva.com/mcp. La cuenta es gratuita. |
Tipos de recursos
El nombre puede confundir: un servidor MCP expone tres primitivas, herramientas, recursos y prompts, y recurso es solo una de las tres.
Herramientas: el servidor expone funciones ejecutables, cada una con un nombre, una descripción y un esquema de argumentos. El modelo las descubre y las llama.
Recursos: el servidor expone datos de contexto, cada uno con una URI. La aplicación decide cuándo leerlos y adjuntarlos.
Prompts: el servidor expone plantillas de mensajes, con argumentos opcionales. El usuario las invoca.
Fíjense en quién controla cada una: el modelo llama herramientas, la aplicación adjunta recursos y el usuario invoca prompts.
Recursos
Son archivos, documentos, datos o recursos en general que expone el servidor. Se consideran pasivos y, por lo tanto, relativamente estáticos: no son editables, solo se pueden leer y listar.
Cada recurso tiene una URI, una dirección estable que lo identifica dentro del servidor. Algunos ejemplos:
| URI | Descripción |
|---|---|
| blog://iic103g/2026-08-18 | Una entrada de blog del curso, del 18 de agosto |
| docs://mcp/intro | La página de introducción de MCP |
| sheets://finanzas/estado-2026-q2 | Una planilla de estados financieros del trimestre |
| ficha://paciente-a/turno-12 | La ficha de Paciente A. El nombre real se queda fuera |
Herramientas
Son funciones que el modelo puede llamar para actuar: buscar un vuelo, enviar un mail, editar un archivo. Cada herramienta tiene un nombre, una descripción y un esquema de argumentos, y los argumentos viajan en un objeto JSON: reserve_hotel({ hotel, check_in, huespedes }).
Si el servidor necesita un dato de ustedes, puede pedírselo a la persona por el cliente. Eso se llama elicitation: otra ronda de la conversación, con ustedes en el medio.
Ejemplos
| Nombre | Firma | Argumentos | Descripción |
|---|---|---|---|
| Reserva de hotel | reserve_hotel({...}) | hotel, check_in, check_out, huespedes | Reserva una habitación en esas fechas |
| Consultar clima | get_weather({...}) | ciudad, fecha | Trae el pronóstico para esa ciudad y ese día |
| Editar un Word | edit_document({...}) | path, instruccion | Reescribe un .docx con esa instrucción |
| Exportar un PDF | export_pdf({...}) | source, destination | Genera un PDF a partir de un archivo |
Descubrimiento progresivo
En la mayoría de las aplicaciones de agentes las herramientas se declaran todas al comienzo. Cuando hay muchas herramientas declaradas, el cliente puede no cargarlas todas de una: si lo hiciera, las firmas consumirían mucho contexto de la conversación antes de que el modelo lea el pedido.
Por eso hoy las aplicaciones de agentes cargan las herramientas en tres capas: catalogar las disponibles, inspeccionar la firma que sirve, y llamar solo esa. Con pocas firmas, cargarlas todas está bien; con muchas, este descubrimiento progresivo evita llenar el contexto y las herramientas siguen siendo útiles y descubribles por el agente.
Prompts
Son plantillas reutilizables que el servidor expone y que el usuario invoca. Traen un nombre, una descripción y argumentos opcionales. El cliente las lista y las pide; en la interfaz suelen verse como un comando, por ejemplo /plan-vacation.
¿Y para qué sirven? Para repetir un flujo con la misma forma. La plantilla ya trae el texto y los argumentos de ese pedido, así no lo escriben desde cero cada vez.
| Prompt | Para qué |
|---|---|
| plan-vacation | Arma un viaje: destino, días, presupuesto |
| summarize-meetings | Resume las reuniones del día |
| code_review | Revisa un archivo y sugiere cambios |
| draft-email | Arma un borrador de correo con el tono que pides |
Actividad: Conectemos un MCP
Para cerrar, conecten un MCP real. En Copilot, conecten el MCP de Canva: es remoto, va por HTTP y la cuenta es gratuita.
- Add MCP. Elijan HTTP
- URL: https://mcp.canva.com/mcp
- Inician sesión en Canva si se abre el navegador
- Dejen un Excel en la carpeta de la sesión y envían este pedido
Prompt
Contexto
Cuentas con un reporte financiero (en Excel) que representa los mejores y peores movimientos de acciones en la bolsa. Puedes encontrarlo buscándolo con comandos para listar archivos.
Instrucciones
Usando ese Excel que tienes en la carpeta, junto al MCP de Canva:
1. Analiza el Excel y planifica unas diapositivas para mostrar los resultados.
2. Crea esas diapositivas en Canva.
Restricciones
- Créalo desde cero, evitando usar plantillas.
- Evita solicitarme el archivo: ya cuentas con él, está en la carpeta de esta sesión, y puedes buscarlo así.