El contexto mínimo viable (mastery gate C3)

5.1El problema

Tu equipo quiere añadir el quinto MCP server. El argumento es el de siempre: "más tools no hacen daño, las que sobran no se usan". Suena razonable. Y es falso: ahora puedes demostrarlo con un número.

La cifra publicada por Anthropic dice otra cosa: "a five-server setup with 58 tools consumes approximately 55K tokens before the conversation even starts". · fuente: code-execution-with-mcp, nov 2025 (corpus D.4). Son 55K tokens pagados antes de leer el encargo, en cada turno, contra el mismo attention budget de N0·L1.

El entregable de esta lección es ese contraargumento, medido en TU agente, no en un benchmark ajeno. Coges el Magallanes que amaneció con 40 tools y la biblioteca en el prompt. Lo entregas con medio contexto estático menos y la misma fiabilidad.

A lo largo de L1–L4 montaste las cuatro piezas por separado. Mediste el coste, curaste el catálogo, convertiste el corpus a carga bajo demanda, domaste los results. Esta lección las ensambla en un método y las somete a una rúbrica que dice cuándo el entregable está listo.

5.2Qué vas a poder hacer

Al terminar serás capaz de:

• Ejecutar el pipeline de adelgazamiento completo —medir → curar → JIT → domar results → re-medir— sobre el Magallanes inflado, en ese orden.
• Producir el entregable de C3: catálogo curado con evals de selección, corpus convertido a JIT, tool results domados, reducción medida con desglose y sweep re-ejecutado.
• Evaluar un entregable contra las 5 dimensiones de la rúbrica C3, distinguiendo una reducción válida de una que rompió la cobertura funcional.
• Defender tu reducción ante el "debate del quinto MCP server": medio contexto menos, misma curva.

Necesitas saber antes:

• De L1 (/cursos/context-engineering/tools-y-jit/cada-tool-paga-renta): cuánto cuesta una tool definition y dónde se paga.
• De L2 (/cursos/context-engineering/tools-y-jit/curar-el-toolset): consolidar, describir, namespacing, respuestas concisas — validado con evals de selección.
• De L3 (/cursos/context-engineering/tools-y-jit/just-in-time-y-progressive-disclosure): referencias ligeras + carga bajo demanda, y la frontera upfront/JIT.
• De L4 (/cursos/context-engineering/tools-y-jit/domar-los-tool-results): límites, paginación y tool result clearing con la context editing API.
• De N0·L4 (/cursos/context-engineering/diagnostico/el-context-sweep): el sweep que produce la curva calidad-vs-longitud. Es el listón a no empeorar.

5.3Recupera (las cuatro categorías del nivel, mezcladas)

Antes de seguir, responde de memoria. Estas cuatro preguntas mezclan a propósito las cuatro categorías del nivel —coste de definitions, principios de diseño, frontera JIT, técnica de results—, confundibles entre sí. Por eso van juntas.

1. ¿Cuánto cuesta una tool definition (rango) y dónde se paga ese coste?
2. Esta descripción de tool dice "busca documentos" y se solapa con otras tres. ¿Qué principio de diseño viola?
3. El encargo es repetitivo sobre una colección pequeña y conocida. ¿Upfront o JIT, y por qué?
4. Un leer() devuelve un tool result de 12K tokens que ya no se necesita. ¿Truncar, paginar o clearing?

5.4El concepto: el pipeline y la rúbrica

El pipeline de adelgazamiento

Aquí está el método que integra las cuatro lecciones. El pipeline de adelgazamiento es la secuencia medir → curar → JIT → domar results → re-medir que reduce el contexto de un agente sin perder fiabilidad. Cada paso depende del anterior.

La analogía: es el ciclo de un perfilador de rendimiento. Primero mides dónde se va el tiempo, luego atacas el punto más caro, y al final vuelves a medir para confirmar la mejora. Dónde falla la analogía: un perfilador mide una sola dimensión (tiempo). Aquí mides dos a la vez —tokens y fiabilidad— y la segunda puede empeorar mientras la primera mejora. Por eso re-medir no es opcional.

El orden importa, y no es decorativo:

• Sin la medición de L1, no hay justificación. Si no contaste los tokens antes, no afirmas el −50% después (dim 4).
• Sin el eval de selección de L2, no hay validación. Curar a ojo optimiza la estética del catálogo, no la selección. El eval antes/después es la única prueba de que no rompiste nada (dim 1).
• JIT (L3) viene después de curar: primero decides qué tools quedan, luego qué conocimiento entra upfront y qué se explora.
• Domar results (L4) es lo último: actúa por turno, no en el contexto estático; cierra la partida que crecía una vez fijado el coste fijo.
• Re-medir cierra el bucle. Re-cuentas con count_tokens y re-ejecutas el sweep de C0. Separa "creo que mejoró" de "mejoró un 62%, confirmado por la curva".

La rúbrica C3, dimensión a dimensión

El checkpoint C3 se aprueba contra cinco dimensiones, fieles a 03-arquitectura.md. Léelas como el contrato del entregable.

Dimensión 1 — Curación validada. Consolidación justificada + accuracy de selección antes/después. Tener menos tools no basta: hay que demostrar con un eval que la accuracy de selección no cayó (idealmente subió).

Dimensión 2 — Calidad de definición. Descripciones según los principios de L2: consolidar operaciones, semántica sobre UUIDs, respuestas concisas. Una tool bien descrita dice qué hace, cuándo usarla y cuándo NO.

Dimensión 3 — JIT correcto. Referencias ligeras (paths, ids, queries) + carga bajo demanda, con la frontera upfront/JIT razonada por la tarea: el volumen, la frecuencia de uso y el coste de exploración de TU encargo.

Dimensión 4 — Reducción medida. Contexto estático −50% o más, con desglose de tokens por partida. El número solo no vale: hay que mostrar qué partida bajó cuánto (system prompt, tools, corpus precargado).

Dimensión 5 — Fiabilidad preservada. El sweep de N0 no empeora —idealmente mejora—. Re-ejecutas el mismo sweep de C0, misma semántica, mismo seed, y comparas las curvas.

Los cuatro errores que invalidan un entregable

Normaliza esto: son los fallos más comunes y ninguno se ve a primera vista. Un entregable puede tener el −50% en grande y aun así no aprobar.

1. Curar sin eval de selección. Tienes 12 tools bonitas y ningún número que diga que la selección no empeoró. La dim 1 queda sin evidencia.
2. Reducir tokens perdiendo cobertura funcional. Borraste el filtro por fecha para ahorrar tokens, y el agente ya no puede una tarea que sí podía. La reducción no vale si rompe la capacidad.
3. Declarar el −50% sin desglose por partida. Dices "reduje a la mitad" y no muestras de dónde salió. Sin desglose, la dim 4 es una afirmación, no una medición.
4. Cambiar el sweep respecto a C0. Re-ejecutas con otro encargo u otro seed. Entonces comparas tareas, no contextos. La dim 5 se invalida de raíz — es el error nº1 del sweep de N0·L4, ahora en la validación.

Lo que NO es el contexto mínimo viable

El contexto mínimo viable no es el contexto más corto. Minimal ≠ corto: Anthropic lo dice explícito — "you should be striving for the minimal set of information that fully outlines your expected behavior". · fuente: corpus B.3. Un catálogo de 3 tools que no cubre la tarea no es mínimo viable: es mínimo y roto. El objetivo es el conjunto más pequeño de tokens de alta señal que mantiene la fiabilidad.

Tampoco es un umbral universal de tools. La heurística "con >30 tools la selección se vuelve crítica, con >100 el fallo es casi seguro" procede del paper RAG-MCP, recogida por Breunig. Es una heurística, no una ley. · fuente: corpus A.3, §8.9. El umbral real es el de TU modelo con TU catálogo, y se mide con un eval. Recuerda el contraejemplo de L1: GPT-4o apenas degrada en LongFuncEval (rango 11–14%); otros modelos caen mucho más. · fuente: corpus D.2.

5.5Míralo funcionar: un entregable de calibración

Antes de producir el tuyo, vas a evaluar uno ajeno: el entregable de un compañero sobre una variante del Magallanes inflado. Es fuerte en reducción y curación, flojo en la dim 3. Verlo así —bueno pero no perfecto— calibra el listón mejor que un ejemplo impecable.

Tiene varias piezas encadenadas (medición, eval, sweep). Antes de leerlas línea a línea, lee el bloque de corrido. Lo difícil no es ninguna pieza suelta: es ver que las cinco dimensiones salen de tres mediciones.

Paso 1 — Re-medir el contexto estático con desglose (dim 4)

La auditoría usa client.messages.count_tokens en dos llamadas: solo system y system+tools. El tercer valor (total estático) es con_tools directamente. La diferencia aísla cada partida.

1# auditar.py — desglosa el contexto estático antes/después (corpus F.6.d)
2# count_tokens no consume cuota de mensajes y tiene sus propios rate limits.
3import anthropic
4
5client = anthropic.Anthropic()
6MODEL = "claude-opus-4-5"
7
8def medir_estatico(system: str, tools: list) -> dict:
9    # 2 llamadas → 3 cifras (la tercera, derivada por diferencia).
10    solo_system = client.messages.count_tokens(
11        model=MODEL, system=system, messages=[{"role": "user", "content": "x"}],
12    ).input_tokens
13    con_tools = client.messages.count_tokens(
14        model=MODEL, system=system, tools=tools,
15        messages=[{"role": "user", "content": "x"}],
16    ).input_tokens
17    return {
18        "system_prompt": solo_system,
19        "tools": con_tools - solo_system,   # el coste de las definitions, aislado
20        "total_estatico": con_tools,
21    }

El desglose del compañero, antes y después:

partida              | antes (40 tools) | después (11 tools) | Δ
---------------------|------------------|--------------------|--------
system prompt (mapa) |          ~38.000 |            ~11.400 | −70,0%
tool definitions     |          ~21.000 |            ~11.000 | −47,6%
---------------------|------------------|--------------------|--------
total estático       |          ~59.000 |            ~22.400 | −62,0%

Estas cifras son ilustrativas —tu agente dará las suyas—; importa el método. La partida que más cae es el system prompt: arrastraba el índice de la biblioteca (el corpus precargado de la avería). La reducción total es −62%, por encima del listón. La dim 4 está cubierta, con desglose.

Paso 2 — El eval de selección antes/después (dim 1)

La curación no se valida por estética. Se valida con un eval de accuracy de selección: dado un conjunto de queries con su tool esperada, ¿elige el agente la correcta?

1# eval_seleccion.py — accuracy de selección de tool, antes/después de curar
2# Reutiliza el harness del apéndice A (provider promptfoo, corpus F.8).
3
4# 10 queries → la tool que DEBERÍA elegirse (held-out, no usado para curar).
5CASOS = [
6    {"query": "documentos sobre la ruta a las Molucas", "esperada": "buscar"},
7    {"query": "el texto completo del documento doc-014",  "esperada": "leer"},
8    {"query": "redacta la sección de financiación",       "esperada": "escribir_seccion"},
9    # ... hasta 10 casos que cubren las 3 familias funcionales
10]
11
12def accuracy_seleccion(grafo, casos: list[dict]) -> float:
13    aciertos = 0
14    for caso in casos:
15        # Se invoca el grafo y se inspecciona qué tool eligió en el primer paso.
16        elegida = primera_tool_elegida(grafo, caso["query"])
17        aciertos += 1 if elegida == caso["esperada"] else 0
18    return aciertos / len(casos)

Resultado:

catálogo        | accuracy de selección
----------------|----------------------
40 tools        | 0.60   (6/10 — confunde buscar_por_titulo con leer_metadatos, etc.)
11 tools curado | 0.90   (9/10)

La accuracy sube de 0,60 a 0,90 al curar: la consolidación no rompió la selección, la mejoró. El compañero justifica cada consolidación (las 12 variantes de búsqueda → una buscar con parámetros). Dim 1 cubierta. Refleja la evidencia de L1: RAG-MCP pasó de 13,62% a 43,13% (>3×) al pre-filtrar las tools. · fuente: corpus D.2.

Paso 3 — Re-ejecutar el mismo sweep de C0 (dim 5)

Aquí está la dimensión que más entregables descuidan. Se re-corre el mismo sweep de N0·L4: mismo encargo, mismo seed, mismas longitudes. Solo cambia el agente.

1# El mismo comando de N0·L4 — semántica congelada, seed fijo.
2npx promptfoo eval -c promptfooconfig.yaml

Las dos curvas, superpuestas:

calidad
1.0 |  o *          o = Magallanes inflado (40 tools, corpus precargado)
    |  *  o         * = Magallanes adelgazado (11 tools, JIT)
    |     * o
0.5 |        *  o
    |           *      o
0.0 +----+----+----+----+----
     0   10   25   50   docs irrelevantes

La curva del agente adelgazado (*) queda por encima de la inflada (o) en todas las longitudes, y su codo está más a la derecha. La fiabilidad no empeoró: mejoró. Dim 5 cubierta. Tiene sentido —menos ruido deja más attention budget para el encargo—, pero la afirmación se sostiene en la curva, no en el razonamiento.

Dónde flojea: la dimensión 3

Hasta aquí, un entregable fuerte. La grieta está en la dim 3 (JIT correcto). El compañero convirtió el corpus precargado a JIT —bien— pero la memoria de diseño dice:

"Dejé el mapa ligero y quité el índice completo porque parecía lo razonable."

"Parecía lo razonable" no es una frontera razonada por la tarea. La dim 3 pide justificarla con el volumen, la frecuencia de uso y el coste de exploración del encargo. La técnica está bien aplicada; la defensa falta.

Self-explanation

Antes de leer la respuesta, intenta tú: el entregable tiene −62% y la curva mejora. ¿Por qué no es un aprobado limpio?

5.6Hazlo tú = el checkpoint C3

Andamiaje decreciente: aquí no hay esqueleto. Esta práctica es el checkpoint C3. Produces el entregable completo sobre el Magallanes inflado del flag lab_n3, siguiendo el pipeline.

El entregable

Sobre el Magallanes con 40 tools y corpus precargado, produce:

(a) Cura el catálogo: 40 → ≤12 tools, con evals de selección antes/después. Aplica la receta de L2 a las cuatro familias. Consolida cada familia en una tool con parámetros. Mide la accuracy con un eval held-out y justifica cada consolidación. → dims 1 y 2.

(b) Convierte el corpus precargado a JIT. Saca el índice del system prompt; deja un mapa ligero (una línea por colección). Razona la frontera upfront/JIT con el volumen, la frecuencia y el coste de exploración de TU encargo —no por intuición—. → dim 3.

(c) Doma los tool results. Aplica los límites, la paginación y el truncado de L4. Si usas clearing, configura clear_tool_uses_20250919 con exclude_tools protegiendo la memoria. → cierra la partida que crecía por turno.

(d) Mide la reducción con desglose por partida. Re-cuenta el contexto estático con count_tokens antes y después. Muestra la tabla por partida y demuestra ≥50%. → dim 4.

(e) Re-ejecuta el mismo sweep de C0 y compara curvas. Mismo encargo, mismo seed, mismas longitudes. Superpón las dos curvas; la nueva no debe empeorar. → dim 5.

Elaborative interrogation — antes de empezar, predice

Cuando saques las 28 tools redundantes y des-precargues el corpus, ¿qué partida del contexto estático esperas que caiga más: el system prompt o las tool definitions? ¿Por qué?

5.7Comprueba: el gate de maestría C3

Sin pistas. Este es el gate. Se evalúa con la rúbrica de cinco dimensiones, con feedback formativo por dimensión.

Un compañero te pasa este entregable para validar antes de subirlo. Léelo y dictamina, dimensión a dimensión, qué aprueba y qué no.

Entregable de Magallanes adelgazado (resumen del compañero):

• Pasé de 40 a 9 tools. Borré las 31 que me parecían redundantes.
• El contexto estático bajó de 59.000 a 24.000 tokens, un −59%.
• Quité el índice de la biblioteca del prompt y dejé un mapa ligero. Decidí dejar upfront los nombres de las 3 colecciones más usadas porque el 80% de los encargos las tocan, y JIT el resto.
• Re-corrí el sweep con un encargo nuevo más representativo y la curva quedó plana, mejor que antes.
• No incluí eval de selección: con 9 tools tan distintas, la selección es obvia.

1. Dictamina cada una de las 5 dimensiones (aprueba / no aprueba) con una frase de por qué.
2. Identifica los dos defectos que invalidan el entregable y explica qué se mide mal con cada uno.

5.8Conecta

Cierra el arco de L1. El agente que amaneció con 40 tools y la biblioteca en el prompt ahora opera con el contexto mínimo viable. Once tools curadas, un mapa ligero, results domados. La curva del sweep lo demuestra —no empeoró; mejoró—.

Eso es lo que entregas en el debate del quinto MCP server. Ya no respondes "creo que no hace falta". Respondes con el desglose: coste por partida, accuracy de selección antes y después, las dos curvas superpuestas. Esa es la diferencia entre una opinión y un argumento de ingeniería.

El pipeline que ejecutaste —medir → curar → JIT → domar results → re-medir— es reutilizable. No es la receta de Magallanes: es la de cualquier agente inflado. Es el método para decidir con números cada "una tool más, un server más".

Y abre N4. Ya tienes un agente delgado y bien medido. Pero el adelgazamiento no resuelve un enemigo: la tarea que no cabe en UNA ventana, por bien gestionada que esté. Cuando explorar exige más contexto del que cualquier ventana sostiene, podar no alcanza — hay que partir el trabajo en sub-contextos aislados. Esa es la última palanca, isolate, y el checkpoint macro que integra todo lo que llevas.

Sigue en el nivel aislamiento: /cursos/context-engineering/aislamiento.

5.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida lo aprendido mejor que releer.

• ¿Qué aprendiste? Resume en una frase por qué re-medir el sweep convierte el adelgazamiento en una mejora demostrada y no en una apuesta.
• ¿Qué sigue sin estar claro? ¿Por qué un entregable con −82% puede no aprobar C3? Si no, vuelve a 5.4 y a 5.5 (la dim 3 floja).
• ¿Qué harías distinto? La próxima vez que alguien diga "más tools no hacen daño", ¿qué tres números le pondrías delante?

Esto requiere práctica. La intuición de "qué partida atacar primero" y "qué dimensión me falta" llega produciendo entregables y sometiéndolos a la rúbrica, no leyéndola. En N4 reutilizarás la misma disciplina de medir-antes-y-después.