Diseño de Herramientas, Integración MCP y Gestión de Contexto: Lista de Verificación del Dominio CCA
Esta lista de verificación cubre dos dominios de CCA Foundations juntos, Diseño de Herramientas e Integración MCP (18%) y Gestión de Contexto y Fiabilidad (15%), porque en la práctica fallan juntos con la misma frecuencia que fallan por separado.
Una herramienta mal definida es frecuentemente la causa raíz de un presupuesto de contexto agotado, por lo que estudiarlos uno al lado del otro coincide con la forma en que se construyen realmente los escenarios del examen.
Cómo Usar Esta Lista de Verificación
- Trabaja primero en Diseño de Herramientas, ya que la forma de la salida de la herramienta impulsa directamente el consumo de contexto.
- Trata cada elemento como una pregunta que deberías poder responder en voz alta sin tener una referencia abierta, lo que coincide con el formato de examen a libro cerrado.
- Utiliza la sección específica de MCP incluso si tu experiencia de producción se limita a herramientas internas personalizadas; los conceptos de MCP se generalizan.
- Vuelve a visitar la sección de Gestión de Contexto justo antes del examen, ya que sus modos de fallo son los que se olvidan con más frecuencia bajo presión de tiempo.
Fundamentos de Diseño de Herramientas (1-6)
- Claridad en el nombre y la descripción de la herramienta: el nombre y la descripción de cada herramienta deben permitir a Claude elegirla correctamente sin prueba y error.
- Vago: una herramienta llamada
handle_datacon una descripción de una línea. - Claro: una herramienta llamada
lookup_order_statuscon una descripción que indica las entradas, salidas exactas y cuándo llamarla.
- Vago: una herramienta llamada
- Estrictez del esquema de entrada: define los campos, tipos y enumeraciones requeridos de forma estricta en lugar de aceptar un bloque de texto libre y vago.
- Flexible:
{"query": "string"}para una búsqueda estructurada. - Estricto:
{"order_id": {"type": "string", "pattern": "^ORD-[0-9]{6}$"}}.
- Flexible:
- Disciplina en el tamaño de la salida: la carga útil de retorno de una herramienta debe ser limitada y resumida, no una volcada cruda de un registro de base de datos completo o una respuesta de API.
- Idempotencia para herramientas mutables: cualquier herramienta que escriba datos debe ser segura para reintentar sin duplicar el efecto, ya que los bucles del agente a veces reintentan las llamadas.
- Exposición de errores, no ocultación: una llamada a herramienta fallida debe devolver un error estructurado sobre el que el agente pueda razonar, no un resultado vacío silencioso que parezca un éxito.
- Alcance de mínimo privilegio: una herramienta debe exponer la capacidad mínima necesaria para su trabajo, no una vía de escape de propósito general de "ejecutar cualquier consulta".
Integración MCP (7-13)
- Diseño del límite del servidor MCP: cada servidor MCP debe mapear a un área de capacidad coherente (por ejemplo, "sistema de tickets", "documentos internos"), no a una bolsa arbitraria de herramientas no relacionadas.
- Distinción entre recurso y herramienta: utiliza recursos MCP para contexto de solo lectura y direccionable (documentos, registros) y herramientas para acciones con efectos secundarios; confundir ambos confunde tanto al agente como al escenario del examen.
- Autenticación y alcance por servidor: las credenciales de un servidor MCP deben limitarse solo a lo que las herramientas de ese servidor necesitan, no a una credencial de administrador compartida en todas las integraciones.
- Descubribilidad sobre documentación: la descripción de herramientas de un servidor MCP bien diseñado debe ser autosuficiente; un agente no debería necesitar documentación externa para usarlo correctamente.
- Conciencia de versión y compatibilidad: ten en cuenta que las versiones del protocolo MCP y las capacidades del servidor pueden diferir, y que una integración de producción debe manejar con gracia un servidor que anuncie menos capacidades.
- Sandboxing de servidores MCP externos: trata un servidor MCP de terceros como una superficie de entrada no confiable; valida lo que devuelve antes de volver a introducirlo en el contexto del agente sin filtrar.
- Aislamiento de fallos: la caída de un servidor MCP no debería inhabilitar la disponibilidad de herramientas de un agente completo si otros servidores son independientes.
Gestión de Contexto y Fiabilidad (14-20)
- Planificación del presupuesto de tokens por turno: conoce aproximadamente cuántos tokens consumen una respuesta típica de herramienta, el prompt del sistema y el historial de conversación, y presupuesta en consecuencia antes de que el contexto se llene.
- Disciplina de ventana de contexto en ejecuciones largas: para bucles de agente de larga duración, poda o resume activamente los turnos más antiguos en lugar de permitir que el historial crezca sin límites.
- Detección de contexto obsoleto: reconoce cuándo el contexto arrastrado de los primeros turnos ya no es relevante y está agregando ruido en lugar de una base útil.
- Conciencia del caché de prompts: entiende cuándo reutilizar un prefijo estable (como un prompt de sistema grande o un conjunto de esquemas de herramientas) entre llamadas reduce tanto el costo como la latencia.
- El desbordamiento silencioso es un modo de fallo, no un caso límite: una ventana de contexto que trunca silenciosamente los mensajes más antiguos puede producir respuestas con confianza erróneas; el examen evalúa si detectarías esto en una revisión de diseño.
- Estrategia de reintento y retroceso: un agente fiable maneja los límites de tasa y los errores transitorios con retroceso, no un bucle de reintento ajustado que consume presupuesto y empeora los límites de tasa.
- Observabilidad del uso del contexto: registra los recuentos de tokens por llamada en producción para que los fallos relacionados con el contexto sean diagnosticables después del hecho, no solo adivinados.
Aplicación de la Lista de Verificación en Orden
- Elementos 1-6 (Diseño de Herramientas): hazlos bien primero, ya que una herramienta mal diseñada crea problemas de contexto y fiabilidad posteriores que son más difíciles de solucionar más adelante.
- Elementos 7-13 (Integración MCP): aplícalos una vez que el diseño básico de la herramienta sea sólido; MCP formaliza los límites de herramientas y recursos entre sistemas.
- Elementos 14-20 (Gestión de Contexto): trátalos como una disciplina continua para cualquier agente que se ejecute más allá de unos pocos turnos, no como un paso de configuración único.
Preguntas Frecuentes
¿Por qué se cubren el Diseño de Herramientas y la Gestión de Contexto en una sola lista de verificación?
Porque una herramienta mal definida (salida sin límites, sin idempotencia) es una de las causas raíz más comunes de un presupuesto de contexto agotado o una ejecución de agente poco fiable, por lo que el examen a menudo combina ambas.
¿Cuál es la diferencia entre un recurso MCP y una herramienta MCP?
- Un recurso es contexto de solo lectura y direccionable, como un documento o un registro.
- Una herramienta es una acción con efectos secundarios, como crear un ticket o enviar un correo electrónico.
¿Por qué es importante la disciplina del tamaño de la salida para las herramientas?
Una respuesta de herramienta sin límites (una volcada cruda de base de datos, por ejemplo) puede consumir una gran parte de la ventana de contexto en una sola llamada, desplazando el espacio para el razonamiento y los turnos posteriores.
¿Qué significa el alcance de herramientas con mínimo privilegio en la práctica?
Una herramienta debe exponer solo la capacidad específica que necesita para realizar, en lugar de una vía de escape de propósito general como "ejecutar cualquier consulta", que amplía el radio de explosión de un error o una inyección de prompt.
¿Por qué es importante la idempotencia para las herramientas que escriben datos?
Los bucles del agente a veces reintentan una llamada después de un tiempo de espera o un error transitorio; si la acción subyacente no es idempotente, un reintento puede duplicar el efecto (como crear dos tickets en lugar de uno).
¿Qué es el desbordamiento silencioso de contexto y por qué es peligroso?
Es cuando una ventana de contexto trunca mensajes antiguos sin ninguna señal visible, lo que puede hacer que un agente responda con confianza basándose en información incompleta en lugar de fallar de forma ruidosa.
¿Debo tratar cada servidor MCP como confiable por defecto?
No. Un servidor MCP de terceros debe tratarse como una superficie de entrada no confiable, y su salida debe validarse antes de volver a introducirla en el contexto del agente sin filtrar.
¿Cómo se relaciona el caché de prompts con la gestión de contexto?
Reutilizar un prefijo estable, como un prompt de sistema grande o un conjunto fijo de esquemas de herramientas, entre llamadas puede reducir tanto el costo como la latencia, lo que es una optimización de gestión de contexto que vale la pena conocer para el examen.
¿Qué debería devolver una herramienta cuando falla?
Un error estructurado sobre el que el agente pueda razonar y potencialmente recuperarse, no un resultado vacío silencioso que podría confundirse con una llamada exitosa sin resultados.
¿Por qué es importante el alcance de la autenticación por servidor MCP?
Si cada servidor MCP comparte una credencial de administrador amplia, una vulnerabilidad o mal uso en una integración expone a todos los demás sistemas a los que esa credencial puede acceder.
¿Cuál es el modo de fallo de gestión de contexto más comúnmente evaluado?
El desbordamiento o truncamiento silencioso de contexto en una conversación de agente de larga duración, ya que produce resultados erróneos con confianza en lugar de un fallo obvio.
¿Es estrictamente necesario el reintento con retroceso para la fiabilidad?
Sí, para sistemas de producción; un bucle de reintento ajustado sin retroceso puede empeorar los límites de tasa y consumir presupuesto más rápido de lo que habría costado el error transitorio original.
Relacionados
- Dominios del Examen CCA Foundations de un Vistazo - dónde se sitúan estos dos dominios en relación con los otros tres por peso.
- Estudio de Arquitectura y Orquestación de Agentes: El Dominio Más Grande del Examen CCA - el dominio de orquestación que soportan estas decisiones de herramientas y contexto.
- Estudio de Caso: Un Asistente de Conocimiento Interno con RAG y Citas - una compilación completa donde las decisiones de diseño de herramientas y gestión de contexto se aplican de extremo a extremo.
- Mejores Prácticas de CCA Foundations - guía práctica basada en esta lista de verificación y los otros dominios.
Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y el SDK oficial de Python
anthropic(última versión 0.x). Los nombres de modelos, precios, formato de examen y versiones de SDK cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs y la guía oficial del examen CCA antes de confiar en ellos.