Confirmaciones de dos pasos
Cuándo la aprobación del cliente MCP no basta, qué herramientas se pueden poner tras un segundo cerrojo y cómo se completa una acción pendiente.
El default: ejecución directa
Cuando un agente llama emit_document, emite.
Facturia no interpone su propio paso de aprobación, porque la UI de aprobación de herramientas del
cliente MCP — eso que te muestra «Claude quiere llamar emit_document, ¿permitir?» — es el humano
en el ciclo. Agregar una segunda confirmación del lado de Facturia sobre eso, para cada escritura,
sería redundante en la enorme mayoría de las llamadas y derrotaría la mitad del punto de una interfaz
de agente.
Dónde eso no alcanza
Existen dos modos de falla distintos, y la aprobación del cliente solo resuelve uno:
El agente intenta hacer algo que la persona no pidió. Lo resuelve el paso de aprobación del propio cliente — para eso existe exactamente.
La persona aprueba por reflejo todo lo que su cliente de chat le pregunta, y algo con consecuencia financiera real — declarar un formulario tributario, un reclamo irreversible — sale porque alguien hizo clic en «permitir» en piloto automático y no porque haya revisado deliberadamente esa cifra. La aprobación del cliente no resuelve esto: es el mismo clic en ambos casos.
require_confirmation ataca el segundo.
Encenderlo
Es una bandera por empresa en automation_settings, al lado de auto_emit_46 y compañía. Viene
apagada, como toda automatización.
curl -X PATCH https://api.facturia.cl/v1/empresas/emp_01K2R6.../automation_settings \
-H "Authorization: Bearer $FACTURIA_KEY" -H "Content-Type: application/json" \
-d '{"require_confirmation": true}'Es un campo REST, no un ajuste solo de MCP: los llamadores REST y el panel ven y controlan la misma bandera. La API REST descrita en el resto de esta documentación no cambia de comportamiento por encenderla.
Qué herramientas toca
emit_document, file_f29, emit_tipo46 y reclaim_received_document — el conjunto «emitir /
declarar / reclamar».
Toda otra escritura (accept_received_document, por ejemplo) sigue siendo directa aunque la bandera
esté encendida: aceptar ya coincide con el default legal que ocurriría por silencio de todas formas,
así que ponerle un cerrojo no protege nada.
Cómo se ve
// → file_f29
{ "empresa": "77928532-4", "period": "2026-07", "confirm_total_payable": 1373000 }
// ← pending_confirmation (la empresa tiene require_confirmation: true)
{
"status": "pending_confirmation",
"confirmation_id": "conf_01K2SD3P7Q",
"confirmation_url": "https://app.facturia.cl/aprobar/conf_01K2SD3P7Q?token=mcpapv_9lQpV3fA…",
"action": "file_f29",
"summary": "File F29 for período 2026-07 — CLP 1.373.000 payable, due 2026-08-20.",
"expires_at": "2026-08-14T14:45:00Z"
}Nada se declaró. El agente te entrega el resumen y el enlace, y ahí se detiene.
Quién la completa: tú, en una página
Abres confirmation_url, ves qué empresa, qué acción y con qué cifra, y aprietas Confirmar o
Rechazar. No hace falta iniciar sesión: el enlace lleva un token de un solo uso, válido esos 15
minutos y para esa acción y ninguna otra. Recién ahí se declara el F29 — con exactamente los datos
que se resumieron cuando el agente lo planteó, no con lo que haya en el mundo en ese momento.
El agente no puede completarla, y eso es el punto
No hay ninguna herramienta MCP que cierre una acción pendiente. La hubo — confirm_action — y se
retiró: si el agente puede completarla diciendo «el usuario me dijo que sí», entonces el registro de
tu aprobación es la palabra del agente, que es exactamente lo que esta bandera existe para no
aceptar. Si le dices al agente que ya aprobaste, que lo verifique leyendo (get_document_status, o
file_f29 con un filing_id).
Confirmar dos veces reproduce el resultado original en vez de ejecutar dos veces — la misma garantía
que Idempotency-Key le da a un llamador REST. Rechazar dos veces tampoco es un error: querías que
no pasara, y no está pasando.
Una aprobación vence a los 15 minutos sin recoger. Vencida, la página lo dice y el agente tiene que volver a plantear la acción para generar una nueva.
Sandbox: se ensaya acá
El doble paso funciona igual en sandbox: si enciendes require_confirmation en una empresa de
prueba, la emisión se aparca, se acuña el enlace y la página /aprobar se abre como en live —
marcada como prueba, para que nadie confunda el ensayo con lo real.
Antes esto no se podía ensayar
Hasta septiembre de 2026 el sandbox ignoraba la bandera: la API la aceptaba, la devolvía encendida y la emisión salía directo igual. Es decir, el puente más delicado del producto — ese en el que un agente le pasa una decisión a una persona — solo se podía ver por primera vez con documentos de verdad. Ahora se prueba con cero riesgo.
La demo de sesenta segundos no cambió: la bandera viene apagada por defecto, así que una empresa de sandbox recién creada sigue emitiendo en una sola llamada.
Los estados que no son errores
Dos comportamientos de esta capa que conviene tener claros en el cliente:
- Límite de tasa y confirmación pendiente no son fallas. El equivalente a un
429y las respuestaspending_confirmationson resultados ordinarios de la herramienta con un campostatusclaro, no errores lanzados. Un agente debería leerlos y decidir qué decir a continuación, no tratarlos como algo roto. - Cada descripción de herramienta declara sus propios modos de falla probables. Un agente que
elige entre
emit_documentydraft_document, o que decide si es seguro reintentar tras unsii_error, nunca debería tener que consultar documentación externa a media conversación. Por esoretriableviaja en cada motivo de rechazo.
Catálogo de herramientas
Hasta 90 herramientas del servidor MCP, según los scopes del grant, agrupadas por dominio, con sus entradas, sus salidas, sus anotaciones y cuáles pasan por confirmación.
Referencia de la API
Todos los endpoints de /v1, generados desde el OpenAPI 3.1 que publicamos junto con la especificación.