/telnyx-meeting-bot

name: telnyx-meeting-bot
description: >-
  Use when an agent must join, observe, react in, transcribe, summarize, or
  follow up on a Zoom, Google Meet, Microsoft Teams, or Webex meeting with
  Telnyx Meeting Bot. Handles vague requests, request-specific live polling,
  name/phrase and semantic triggers, explicitly authorized speak/chat actions,
  recovery, and all implemented transcript artifact types.
metadata:
  author: telnyx
  product: meeting-bot
  requires:
    env:
      - TELNYX_API_KEY

Telnyx Meeting Bot

Use this skill to attend a meeting visibly, monitor its finalized transcript, alert the requester, execute explicitly authorized live rules such as speaking one response, and produce evidence-based meeting results. The bot is **observe-only by default**: it must not speak, send chat, or make other in-meeting changes unless the requester explicitly asks for that.

Quick Workflow

1. Resolve only missing essentials: meeting URL, join now versus a scheduled time, desired live/final outputs, and trigger/action rules. Reuse authorized details; do not ask again. 2. Persist an operation record **before** creating the session and choose its transport. Ordinary sessions use MCP `join_meeting`. Any Portal Assistant or Anam avatar session uses REST `POST /v2/meeting_sessions` with the requested object(s). Persist one stable `idempotency_key`, the transport, and the exact logical create request; store only a secret reference for a write-only Anam key. REST-only sessions are immediate, so omit `join_at`; Assistant sessions also omit `barge_in`. For an ordinary session with an authorized later speech rule, set `barge_in: true` so human speech can stop bot output. 3. Poll `get_session`, `get_transcript`, and, when available, `get_events`. Select `wait_seconds` from the request—about `2` for “as soon as,” reactive speech, or urgent mentions—and persist cursors, seen segments, outboxes, claims, and IDs for recovery. 4. On each new final segment, evaluate requested literal or semantic rules; deliver mention notifications through the durable outbox, and atomically claim and execute each authorized `speak`/`send_chat` action at most once. 5. On a terminal session, drain transcript pages, wait a bounded time for `transcript.completed`, obtain requested implemented artifact types without duplicate creation, then deliver a Markdown report.

Preconditions and Safe Defaults

• Require `TELNYX_API_KEY` in a backend secret store. Never include it in a URL, transcript, event, artifact, chat message, or user-facing report.
• Before joining, ensure the runtime can keep monitoring or can resume from durable background state. Do not promise end-to-end monitoring from a process that disappears without preserving and resuming the operation record.
• Verify authorization for a visible bot. A host may need to admit it; never bypass a waiting room, password, platform policy, or consent requirement.
• Default notification target: **this current conversation**. Do not configure a `webhook_url` merely to send requester notifications.
• Default behavior is immediate join, `summarize_on_end: true`, observe-only, and no recording-media deletion. `speak`, `send_chat`, `speak_on_enter`, and `chat_on_enter` are opt-in.
• An explicit conditional request such as “when someone asks about lunch, say ‘I want pizza’” authorizes exactly that action. Before join, persist trigger, exact payload, one-shot/repeat policy, and latency target; do not interrupt the workflow to ask again.
• Select monitoring cadence from the request: default immediate reactions and urgent mentions to `wait_seconds: 2`, never silently substituting a 15-second cadence for “as soon as.”
• If the link is missing, ask for it. If timing is ambiguous, ask only now versus specified time. If “my name” is not resolvable from authorized request/context/profile data, ask for name/phrases and optional variants.

Connect to the Production MCP Server

Prefer the production Streamable HTTP MCP endpoint:

https://api.telnyx.com/v2/meeting_bot/mcp
Authorization: Bearer ***

Use the service's exact tools: `join_meeting`, `get_session`, `list_sessions`, `get_transcript`, `get_events`, `leave_meeting`, `get_recordings`, `speak`, `stop_speaking`, `send_chat`, `create_artifact`, `get_artifact`, and `get_artifacts`.

MCP tools return one JSON text block. Decode `result.content[0].text` only after checking `result.isError`. HTTP/transport failures (for example 401, timeouts, or 5xx) differ from an HTTP-200 MCP tool failure with `result.isError: true`; preserve the error code/message and do not treat HTTP 200 as success alone.

If MCP is unavailable, use the equivalent production REST base:

https://api.telnyx.com/v2/meeting_sessions

REST equivalents include `POST /`, `GET /{id}`, `POST /{id}/actions/speak`, `POST /{id}/actions/stop_speaking`, `POST /{id}/actions/send_chat`, `GET /{id}/transcript`, `GET /{id}/events`, `DELETE /{id}`, `GET /{id}/recordings`, `GET /{id}/artifacts`, `POST /{id}/artifacts`, and `GET /{id}/artifacts/{artifact_id}`. Send the standard bearer-token `Authorization` header. REST responses use `{ "data": ... }`. REST is a fallback transport for ordinary sessions when MCP is unavailable, but it is required for Portal Assistant and Anam avatar creates because MCP cannot express those objects. The lifecycle and durability rules remain the same.

Create or Schedule Exactly Once

Before the first session create, checkpoint a durable operation record outside transient chat memory whenever the host supports files, a task store, or durable workflow state. Store at least:

{
  "operation_id": "host-stable-id",
  "meeting_url": "redacted-or-secret-reference",
  "idempotency_key": "meeting-bot:<host-stable-id>",
  "create_transport": "mcp-or-rest",
  "create_request_without_write_only_secrets": {},
  "avatar_api_key_secret_ref": null,
  "session_id": null,
  "poll_wait_seconds": 2,
  "live_rules": [],
  "transcri