Resources y prompts

Además de las tools, el servidor ofrece tres cosas que el cliente usa por su cuenta: resources (documentos que el usuario adjunta a la conversación), prompts (guiones listos que el usuario elige) y completions (autocompletado de sus argumentos). En la era 2026-07-28 también pide confirmación antes de ejecutar una tool destructiva.

Nada de esto abre un camino nuevo hacia tus datos: todo pasa por las mismas tools, con los mismos permisos y el mismo alcance del token. Resources, prompts y completions cuentan como lectura, así que siguen disponibles con un token solo de lectura.

Resources

Un resource es un documento identificado por una URI. El usuario elige, por ejemplo, un cobro, y el cliente lee el documento y lo pone en el contexto, sin que el modelo tenga que llamar a una tool.

URI	Tool que lo lee	Qué vuelve
kobana://dunning/me	dunning_me	La identidad de la conexión (JSON)
kobana://dunning/metrics/recovery	dunning_metrics_recovery	Las métricas de recuperación (JSON)
kobana://dunning/notification-preferences	dunning_notification_preferences_get	Las preferencias de notificación (JSON)
kobana://dunning/people/{id}	dunning_people_get	Un deudor (JSON)
kobana://dunning/people/{id}/statement-pdf	dunning_people_statement_pdf	El extracto del deudor (PDF)
kobana://dunning/charges/{id}	dunning_charges_get	Un cobro (JSON)
kobana://dunning/charges/{id}/settlement-pdf	dunning_charges_settlement_pdf	La carta de finiquito (PDF) — solo de un cobro pagado
kobana://dunning/agreements/{id}	dunning_agreements_get	Un acuerdo (JSON)
kobana://dunning/agreements/{id}/pdf	dunning_agreements_pdf	El término del acuerdo (PDF)
kobana://dunning/disputes/{id}	dunning_disputes_get	Una disputa (JSON)
kobana://dunning/collection-rules/{id}	dunning_collection_rules_get	Una regla de cobranza (JSON)
kobana://dunning/collection-rules/{id}/steps	dunning_collection_rule_steps_list	Los pasos de una regla (JSON)
kobana://dunning/templates/{id}	dunning_templates_get	Una plantilla de mensaje (JSON)

resources/list trae las URIs fijas y resources/templates/list las plantillas con {id}.

• Permisos. Cada resource se lee con la tool de la tabla. Solo aparece, y solo se lee, si puedes ejecutar esa tool.
• Binarios. Los PDF vuelven en base64 (blob), hasta 10 MB. A diferencia de las tools, que solo describen el archivo, aquí el documento es la respuesta: lo pidió el cliente.
• No encontrado. Una URI desconocida, o un registro que no existe en esta organización, es -32002 en la era 2025 y -32602 en la 2026-07-28 — ve Errores.
• Sin suscripción a cambios. El servidor es stateless: no hay resources/subscribe.

Prompts

Un prompt es una instrucción lista que eliges en el cliente y que se convierte en el primer mensaje de la conversación. Solo aparece si puedes ejecutar todas las tools en las que se apoya.

:::info Todos los prompts solo leen Ningún prompt envía mensajes, negativa ni protesta. Cada uno termina sugiriendo los próximos pasos y le dice al modelo que no actúe sin que se lo pidas. :::

Prompt	Argumentos	Qué hace
review_overdue_charges	person_id (opcional, UUID)	Los cobros vencidos — overdue, o pending con vencimiento hasta ayer (la fecha ya va calculada) —, en una tabla por antigüedad y agrupados por tramo de atraso (hasta 30, de 31 a 90 y más de 90 días), con sugerencias de próximos pasos.
debtor_overview	person_id (obligatorio, UUID)	El retrato de un deudor: datos, cobros, acuerdos y últimas interacciones.
recovery_report	months (opcional, de 1 a 24, por defecto 6)	Informe de recuperación: valor y cantidad recuperados, tasa, días promedio de atraso, pasos promedio de la regla, lo que sigue vencido, la serie mensual y los cortes por método y canal.
pending_legal_actions	—	Negativaciones y protestos con status pending (esperando aprobación humana), señalando inconsistencias. No aprueba ni cancela nada.

Un argumento obligatorio ausente, o fuera de formato, es -32602.

Completions

completion/complete sugiere valores mientras escribes un argumento:

• person_id, y el {id} de people, charges y templates: busca en el listado correspondiente con search, bajo el mismo permiso de ese listado.
• El {id} de agreements, disputes y collection-rules: toma los ids más recientes del listado y los filtra por el prefijo que escribiste.
• months: 3, 6, 12 y 24.

Como mucho vuelven 100 valores. Sin fuente de sugerencias, la respuesta es una lista vacía — nunca un error — y sigues escribiendo.

Confirmación de tools destructivas

Las tools destructivas llevan destructiveHint:

• borrar y archivar, también en lote;
• cancelar — cobros en lote, acuerdos, protestos, negativaciones;
• hablar con el deudor o con un tercero — dunning_charges_notify, dunning_notifications_create, dunning_notifications_resend, negativar (dunning_negativations_create), protestar (dunning_protests_create), aprobar una negativación o un protesto (*_update), probar y reintentar un webhook;
• aplicar una regla a cobros (dunning_charges_bulk_assign_rule), porque dispara mensajes;
• aceptar un acuerdo (dunning_agreements_accept) y resolver una disputa (dunning_disputes_update);
• crear o cerrar una campaña de descuento y rotar el secreto de un webhook.

Una actualización común de configuración (*_update) no es destructiva.

El servidor no confía solo en el cliente: en la era 2026-07-28, con un cliente que declara elicitation de formulario, pide la confirmación él mismo:

1. El primer tools/call no ejecuta nada. Vuelve con resultType: "input_required", un pedido inputRequests.confirm (elicitation/create, un booleano "Run this action") y un requestState.
2. El cliente muestra la pregunta y reenvía la misma llamada con el requestState y la respuesta en inputResponses.confirm.
3. Solo action: "accept" con confirm: true la ejecuta. Rechazar o cancelar devuelve un resultado isError con USER_DECLINED, y nada cambia.

La confirmación vale solo para esa llamada: la misma tool, los mismos argumentos, la misma persona y organización, durante 5 minutos. Si el estado falta, venció o fue alterado, el servidor simplemente vuelve a preguntar. Y es de uso único: reenviar una llamada ya confirmada devuelve isError con confirmation_replayed, sin ejecutar nada — para repetir la acción, llama a la tool de nuevo y confirma otra vez.

Un cliente que no puede confirmar — en la era 2025, o en la 2026-07-28 sin declarar elicitation de formulario — no ejecuta tools destructivas: la llamada devuelve isError con confirmation_required y no se ejecuta nada. La lectura y la escritura común siguen funcionando. Si el servidor no puede registrar la confirmación en ese momento, la tool también se rechaza, con confirmation_unavailable.

:::warning Destructivo aquí es de verdad Estas tools envían mensajes a deudores, negativan y protestan en el mundo real. Empieza en sandbox — ve Clientes. :::