Semana 7 — MCP (dotar a un agente de sus propias herramientas, la forma estándar)

Parte de mi camino para subir de nivel mis habilidades de automatización mientras el campo se orienta hacia la IA. Esta semana trata sobre el Model Context Protocol (MCP) — en lugar de pegar datos en un prompt, al LLM se le entrega un pequeño conjunto de herramientas y decide por sí mismo cuáles llamar, en qué orden, para responder una pregunta.

Por qué importa esta semana: el hardcoding de datos en un prompt no escala más allá de una demo. MCP es el estándar emergente de "aquí tienes tus herramientas y tus fuentes de datos, ve" — es lo que permite que un agente se conecte a un sistema en vivo en lugar de a una instantánea.

La arquitectura

[client.py asks a question]
            |
            v
[Claude sees 3 tool definitions — no invoice data in the prompt]
            |  decides which tools to call, with what arguments
            v
[MCP server (server.py): list_invoices / get_invoice / get_purchase_order]
            |  returns live data over stdio
            v
[Claude reasons over the results and answers]

Continuidad: la semana 2 extrajo una factura de un documento. La semana 6 decidió qué hacer con una excepción de factura, con los datos que el bot ya tenía en la mano. Esta semana, los datos en sí viven detrás de un servidor MCP: un agente busca sus propios datos en lugar de que se los den ya puestos. Combina esto con el servicio de decisión protegido por políticas de la semana 6 y obtendrás el Portfolio Project #4 de la ruta: un agente que busca cosas y además entrega la decisión a una capa de reglas auditable.

Related MCP server: Invoice MCP Server

Qué contiene esto

1. Ejecútalo

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
# copy .env.example to .env and paste your key

python src/client.py

client.py levanta el propio server.py mediante stdio (así es como MCP funciona habitualmente para herramientas locales — no hay que administrar ningún puerto HTTP, a diferencia de la semana 6). Observa cómo se imprime [MCP tool call: ...] líneas a medida que Claude decide qué necesita consultar.

Ejecuta las pruebas unitarias para la lógica de las herramientas (no no hay una API key necesaria):

pytest

2. La idea clave de diseño: herramientas + datos sobre un protocolo estándar

Antes de MCP, "dar una herramienta al modelo" significaba crear a mano un JSON Schema y un dispatch if/elif para cada proyecto. MCP lo estándar: server.py declara las herramientas una vez con @mcp.tool(), y cualquier cliente que hable MCP — el client.py de este repositorio proyectos, Claude Desktop, el agente de otro equipo — puede descubrirlas y llamarlas de la misma manera. Esa es la propuesta de "conectar agentes con herramientas reales": el proveedor de la herramienta y el agente no necesitan estar escritos por la misma persona.

3. Lo que aprendí / listo para producción vs. no

• MCP separa quién posee los datos de quién razones sobre it — el servidor no lo había con quién no le importa qué LLM lo llama.

• La elección del modelo también importa aquí: es orquestación (decidir qué herramienta llamar), no un juicio difícil, así que un modelo barato/rápido (claude-haiku-4-5) es la opción correcta: deja el razonamiento de nivel Opus para el tipo de decisión que toma la semana 6.

• No listo para producción: el "ERP" es un dict en memoria, el servidor no tiene autenticación y no hay un recurso MCP real (solo herramientas) — una versión de producción probablemente exponga también los registros de facturas como recursos MCP. (+ 8).

Stack

Python · MCP (SDK oficial de Python) · Claude (claude-haiku-4-5 para manejar herramientas) · Anthropic SDK · pytest