Ejemplos

Flujos comunes ilustrados como interacción agente ↔ MCP. Cada paso usa los schemas reales documentados en Tools y Prompts y resources.

1. Crear un pipeline desde un intent

Operador (en chat): "Empezá a seguir a @growth_dr y armame drafts analíticos por cada post."

1. Agente invoca create_pipeline_from_intent con:

   {
     "handle": "growth_dr",
     "intent": "Track this competitor and turn their high-engagement posts into analytical drafts we can refine.",
     "tone": "analytical",
     "idempotency_key": "init-growth-dr-2026-05-16-001"
   }

2. MCP responde con { pipeline_id, run_id }.
3. Agente confirma al operador con un link al pipeline en la UI o el ID para usar con read_inbox.

Limitación: esta tool crea pipelines con source=x, kind=prose, scope=per_post. Para --auto-fanout, otro source, kind=structured o digest scopes, hay que usar el CLI o la UI.

2. Diagnosticar un pipeline que no produce

Operador: "¿Por qué pp_a1b2c3 no me está dando drafts hace 2 días?"

1. Agente invoca diagnose_pipeline con { "pipeline_id": "pp_a1b2c3" }.
2. MCP responde con shape:

   {
     "status": "running",
     "last_run": { "id": "run_5xyz", "status": "failed", "error_code": "credential_dead" },
     "suggested_action": "rotate_credential",
     "suggested_endpoint": "connect_x_account"
   }

3. Agente le explica al operador: "El scraper se quedó sin cookies vivas para esta cuenta. Te paso al wizard de rotación."
4. Si el operador pega cookies frescas en el chat (no recomendado pero posible), el agente invoca connect_x_account con { handle, auth_token, ct0?, idempotency_key }. El probe corre sincrónicamente y la respuesta dice si la credencial funciona.

3. Refinar drafts pendientes y publicar

Operador: "Decime qué hay listo en el inbox de pp_a1b2c3 y refiname los muy largos."

1. Agente invoca read_inbox con { "pipeline_id": "pp_a1b2c3" }.
2. MCP devuelve los rows del inbox. El agente revisa los preview y detecta drafts que superan 280 caracteres.
3. Por cada uno, el agente invoca el prompt refine_post con:

   {
     "artifact_id": "rf_4f5g",
     "goal": "shorter and punchier, keep the numbered-list hook"
   }

   El prompt devuelve un workflow narrado — el agente lo sigue: lee el artifact vía artifact://rf_4f5g, decide refinement_type=shorter, dispara el refinement, pollea, y al final invoca publish_artifact sobre el hijo si el operador aprueba.
4. El agente presenta al operador la lista (originales + variantes) y le pregunta cuáles publicar — una por una, no en batch silencioso.

4. Manejar una session de drafting end-to-end

Operador: "Abrime una session, metele los top 3 posts de pp_a1b2c3, y probá dos variantes — una thread de X, una LinkedIn largo."

1. Agente invoca session_create con { "name": "growth_dr · 2026-05-23" }. MCP devuelve el id de la nueva session.
2. Agente invoca read_inbox / list_posts contra pp_a1b2c3 y elige los 3 posts con más engagement.
3. Por cada post, el agente invoca session_add_item con los campos del snapshot (sourceKind: "x", externalItemId, title, snippet, capturedAt, metrics, raw).
4. El agente invoca session_add_variant dos veces:

   { "sessionId": "...", "presetId": "x-thread", "prompt": "Thread on growth tactics, hook-driven", "style": "punchy, numbered", "typeTag": "thread" }

   { "sessionId": "...", "presetId": "linkedin-long", "prompt": "Long-form LinkedIn post, analytical takeaway", "style": "professional, paragraph", "typeTag": "linkedin" }

5. El agente invoca session_generate_all con { "sessionId": "..." }. MCP encola ambas variantes; cada generación appendea un variant_round.
6. El agente invoca session_get para leer los rounds más recientes y le presenta ambas variantes al operador.
7. El operador elige la thread de X; el agente invoca session_export_variant con { sessionId, variantId, format: "markdown" } para registrar el evento de export.

Las sessions no publican. Exportar registra un evento y devuelve el texto del round — lo que pasa después (pegar en X, agendar vía otra tool) vive afuera de Whet.

Patrones a evitar

• No invocar publish_artifact en batch sin confirmación. Cada publish es una intención explícita del operador. Un agente que publique todo lo ready sin preguntar rompe el contrato del producto.
• No re-implementar scraping desde el agente. Si necesitás más datos, usá list_posts o creá otro pipeline — no intentes scrapear por tu cuenta.
• No guardar el idempotency_key en el chat. Generalo del lado del agente con un UUIDv4 y descartalo después del call. Reutilizar la misma key contra otro pipeline confunde el reemplazo idempotente.
• No asumir que create_pipeline_from_intent puede modificar un pipeline existente. La tool crea o resume el mismo pipeline cuando se reutiliza el idempotency_key. Para cambios de configuración hay que ir a la UI o al CLI.

Modelo de costos

Cada tool call consume recursos del deployment del operador (queries a Postgres, LLM calls en muchos casos). Whet no factura por call al MCP — el costo está en el retainer/setup fee. Si construís un agente que consume intensivamente, respetá los rate limits del Agent API (documentados en Integraciones · Errores).