supovia.com

# Support operations with Supovia This skill drives the Supovia MCP connector. The user must connect Supovia and authorize an account with access to the intended organization. If a call fails with an authorization error, ask the user to connect or reauthorize Supovia instead of retrying with guessed identifiers. ## Privacy boundary Supovia exposes only bounded operational metadata and published help-center content. Message bodies, previews, and message identifiers are unavailable to both the model and every MCP App view. Customer identifiers, organization IDs, staff IDs, credentials, agent prompts, arbitrary metadata, and internal notes are intentionally unavailable too. Never claim to have read an excluded thread, ask the user to paste private customer data into chat, or try to recover fields the tools omit. `show_customer_inbox` returns only an unread-conversation aggregate to the model; its embedded view receives conversation IDs needed for an explicit follow-up plus channel, status, unread count, and timestamps. `get_conversation` is model-visible and returns only safe metadata plus bounded sender-category activity counts. `open_customer_inbox_conversation` is app-only because the inbox calls it when a row is selected, but it refreshes only the same safe metadata and never loads a thread. Do not instruct the model to call that app-only tool directly. ## Identifiers Do not guess identifiers. Resolve them from the connector: - Start with `list_websites` when the user names a site or domain. Use the returned website ID for filters that require `websiteId`. - Use `list_conversations` to resolve a conversation ID before a state change. - Use `list_documents` or `search_documents` to resolve a document ID or slug. - Campaign IDs are returned only as inventory by `list_campaigns`; there is no tool that sends a campaign. Opaque pagination cursors are bound to their original filters. Reuse a cursor only with exactly the same website, resolved-state, locale, or slug filters that produced it. Start a new listing when any filter changes. ## Available tools Workspace and workload: | Tool | Use it for | | ------------------------------------ | ------------------------------------------------------------ | | `list_websites` | Find organization-owned websites and their safe status | | `get_website` | Read one website's name, domain and customer-agent status | | `show_support_overview` | Render a bounded website and recent-conversation summary | | `get_unresolved_conversation_counts` | Get complete open-work totals with a top-100 website preview | Conversation triage: | Tool | Use it for | | ---------------------------------- | --------------------------------------------------------------------------------- | | `list_conversations` | Page through newest conversations, optionally by website and resolved state | | `show_customer_inbox` | Open a metadata-only inbox while returning only the unread aggregate to the model | | `get_conversation` | Read safe conversation metadata and bounded sender-category activity counts | | `open_customer_inbox_conversation` | Embedded-app-only metadata refresh, never a model workflow step | Knowledge base and campaigns: | Tool | Use it for | | ------------------ | -------------------------------------------------------------------- | | `list_documents` | Page through safe help-document metadata | | `search_documents` | Semantically find up to five documents for one owned website | | `get_document` | Read one owned article, capped at 20,000 characters | | `list_campaigns` | Inventory campaign identities without recipients, subject or content | Writes: | Tool | Use it for | | ---------------------- | ----------------------------------------------------- | | `send_message` | Create one operator reply in an existing conversation | | `resolve_conversation` | Idempotently resolve or reopen one conversation | Both writes declare `destructiveHint: true` because Claude's current review rule treats sends and state changes as destructive operations that require confirmation. That hint does not mean `resolve_conversation` deletes a thread; it remains an idempotent resolved-state update. There is no Supovia MCP tool for creating or editing websites, documents, campaigns, customers, phone numbers, or AI receptionists. Do not promise those actions or substitute an unrelated tool. ## Triage workflow When asked what needs attention: 1. Call `show_support_overview` for a compact card when the user wants a visual summary. 2. Call `get_unresolved_conversation_counts` when they need complete totals; its sorted per-website preview is capped at 100 and reports truncation; the overview count covers only its displayed sample. 3. Use `list_conversations` with `resolved: false` and the relevant website ID to identify the newest open threads. 4. Use `show_customer_inbox` when the user wants a visual unread-workload view. It shows only channel, status, unread count, timestamps, and the conversation ID needed for an explicit follow-up; it cannot display thread content. Report which website has the open work, the bounded page size, and whether a cursor says more results exist. Do not describe a sample as the full backlog. ## Researching a support answer For a product or policy question: 1. Resolve the website with `list_websites`. 2. Call `search_documents` with a concise semantic query and the website ID. 3. Read the best candidate with `get_document`. 4. Ground the answer in that article and say when the returned content was truncated. `get_document` verifies ownership even though the underlying public document route can resolve slugs across tenants. A `not-found` result is intentionally ambiguous; do not treat it as proof that another organization's article exists. ## Sending a reply `send_message` requires an idempotency key. Generate one stable, unique value for the approved conversation-and-text pair and reuse that same value only when retrying an ambiguous result. Reusing it with different input is rejected. Before calling it: 1. Resolve the exact conversation ID; never use an ID guessed from prose. 2. Obtain the exact reply text from the user, or present a draft based only on model-visible context and ask for explicit approval. 3. Show the destination conversation ID and final text together. 4. Generate a stable idempotency key, then call `send_message` after approval. 5. If the call times out or returns an ambiguous transport error, retry only with the exact same conversation, text, and idempotency key. The connector never supplies customer text. The user may provide the relevant context or an exact message without copying personal data the model does not need. ## Resolving or reopening `resolve_conversation` changes only the `resolved` field and is idempotent, but it still changes shared support state. Confirm the conversation ID and desired state when the user's intent is ambiguous. Use `resolved: false` only when the user explicitly wants to reopen a thread. Resolving a conversation does not send a customer message. If both are requested, send the approved reply first, verify success, then resolve. ## Campaign boundary `list_campaigns` exposes only campaign identity and timestamps. It deliberately omits recipients, subject and message content because the API's by-ID campaign route lacks a safe tenant boundary. There is no send operation. Never claim to have inspected campaign content or launched a campaign. ## Interactive views The support overview, activity inbox, and conversation activity summary are MCP App views. When a card already renders the requested facts, add only useful interpretation in prose. Never imply that an app contains thread text: no MCP App receives message bodies, previews, message identifiers, customer details, or internal notes.