Patrones de prompts para trabajo MCP de varios pasos
El servidor impone límites. No puede imponer una secuencia, contención ni verificación: eso depende de cómo formules la solicitud.
Estos son los patrones que merece la pena reutilizar. Los principios generales para crear prompts están en Prompting an MCP client; esta página trata específicamente de los trabajos de varios pasos.
El patrón de planificar primero
Enumera las herramientas que pretendes invocar y en qué orden, y espera a que te confirme antes de invocar ninguna.
La frase más útil de este capítulo. Convierte una secuencia opaca en un plan que puedes comprobar, y solo cuesta un turno.
Úsalo para cualquier cosa que no hayas hecho antes con este asistente, para cualquier cosa en plural y para cualquier cosa que afecte a precios, plantillas o ajustes del tema.
El patrón de leer-comprobar-escribir
Lee el registro actual y muéstramelo. Luego haz el cambio. Después vuelve a leerlo y muéstrame los campos que difieren.
Tres pasos explícitos. La lectura final es la que la gente omite, y es la que distingue «la llamada ha tenido éxito» de «el resultado es correcto».
El patrón de alcance delimitado
Indica qué queda fuera de los límites, no solo qué está dentro:
Modifica únicamente la entrada 412. No toques ninguna otra entrada, término, plantilla ni ajuste.
Trabaja solo con borradores. No cambies nada que esté publicado.
No borres nada. Si algo parece que debe borrarse, dímelo.
No cambies precios, existencias ni cupones.
Los asistentes generalizan de una tarea a lo que parece adyacente a ella. Un límite explícito es la corrección más barata disponible.
El patrón piloto
Para un trabajo sobre muchos registros:
Haz los tres primeros, luego detente y muéstrame los resultados antes de continuar.
Tres registros completados te dicen si el enfoque es correcto. Trescientos te dicen lo mismo a un precio mucho mayor.
Combínalo primero con un recuento: pide wp_count_posts o el equivalente para conocer el tamaño real antes de aceptar un lote.
El patrón de simulación
Usa una simulación cuando la herramienta lo permita, muéstrame el resultado y espera.
Cuando una herramienta de escritura acepta dry_run, esto te da un antes y un después sin cambiar nada. El soporte depende de cada herramienta; el asistente te dirá si no está disponible.
El patrón de validación
Para contenido del constructor y plantillas:
Lee primero el contexto de autoría y los esquemas de shortcode. Redacta el contenido, valídalo, muéstrame cualquier error y escribe solo cuando la validación se supere.
Consulta Validate builder or template markup before writing.
El patrón de recuperación
Pide lo que necesitarás si el trabajo sale mal, antes de que salga mal:
Antes de cada cambio, muéstrame el valor actual del campo que vas a modificar.
Ahora la conversación conserva los valores antiguos. Esta es tu forma de deshacer, y no cuesta nada prepararla con antelación. Consulta Recover from a failed write.
El patrón de detenerse ante un error
Si algún paso falla, detente de inmediato y dímelo. No reintentes ni continúes con los elementos restantes.
Sin esto, un asistente que se topa con un error a mitad de un lote puede reintentar, saltarse elementos o seguir adelante, dejándote sin saber en qué estado está el sitio.
Combinarlos
Una instrucción realista para un trabajo real usa tres o cuatro:
Quiero reetiquetar las doce entradas de la categoría «News». Primero cuéntalas y enumera sus IDs. Luego haz solo las tres primeras y detente para que pueda comprobarlo. No cambies títulos, contenido ni estado, solo las etiquetas. Si algo falla, detente y dímelo.
Plan, piloto, alcance delimitado, detenerse ante un error. Cuatro frases, y elimina la mayoría de las formas en que el trabajo podría salir mal.
Patrones que no funcionan
«Ten cuidado.» No significa nada accionable.
«No rompas nada.» Toda instrucción lo implica y ninguna lo impone.
«Usa tu criterio sobre qué entradas actualizar.» El criterio sobre tu contenido es precisamente lo que el asistente no puede tener.
«Arregla el sitio.» Un alcance ilimitado con acceso de escritura es la peor combinación posible.
Los controles que no son prompts
Los prompts moldean el comportamiento; no lo limitan. Lo que realmente limita son las compuertas de escritura, las capacidades del usuario que actúa y los ámbitos del token.
Si un límite de un prompt importa lo bastante como para escribirlo, plantéate si debería ser una compuerta cerrada. Consulta MCP security model.
Empieza por un prompt publicado
Para varios trabajos comunes, el servidor ya publica un prompt que codifica la secuencia correcta. Esos son más fiables que un patrón que montes tú mismo. Consulta Prompt recipes.