Skip to main content

Support Bot

The Support Bot is a chat assistant for the questions you would otherwise open a ticket for: "why is my build failing," "what does this error mean," "what changed in the last release," "what am I allowed to do on this project." It uses the same credentials as your session and can only see what you can see. When it cannot resolve a question, it files a support ticket on your behalf with the conversation context attached, and hands you the ticket ID.

There are two ways to reach it — the in-console widget (default, no install) and an MCP export for people who live in Claude Desktop or Claude Code.

Two modalities​

In-console widget (default)​

Every authenticated page in the console carries a floating chat launcher in the bottom-right corner. Clicking it opens the Support Bot inline; there is also a dedicated /support page for a full-height view. No install, no configuration — your session cookie authenticates the bot as you, and the bot's tool responses are scoped to what your role permits.

MCP export (Claude Desktop / Claude Code)​

If you already drive the platform from Claude Desktop or Claude Code, you can add the Support Bot as an MCP server and ask its tools directly from your assistant.

Install via the CLI once the packaged command ships:

c2a mcp install support

Or copy the JSON config from Access → Support MCP (/access/support-mcp in the console) into your MCP client's config file. The page issues a scoped token tied to your account and shows revoke instructions in the same place.

Both modalities talk to the same backend and use the same tools. The MCP export is convenient when you already have an assistant open; the widget is convenient when you're already in the console.

What the bot can do​

The Support Bot has eight tools. All of them respect your role — a VIEWER on a project sees read paths; a PROJECT_ADMIN sees writes; nobody sees another tenant's data.

ToolWhat it does
support_get_my_permissionsAnswers "what am I allowed to do?" by returning your effective role, account-level flags, and per-project grants — the same view the Roles and Permissions reference explains.
support_describe_my_appReturns the current status of one of your apps: build state, runtime state, URL, revision, last deploy time.
support_get_recent_build_failuresLists recent failed builds across your projects with the failure classification (missing SA, dead PAT, transient, unknown) — the same taxonomy the build-repair guide uses.
support_read_recent_app_logsPulls the last N lines from one of your apps (opt-in log-capture must be on for the namespace).
support_search_docsFull-text search across this documentation site — the bot cites the pages it draws from.
support_get_recent_release_notesPulls the last N release events from the platform's release feed. Same data that populates Release Notes.
support_diagnose_failureRuns an LLM-assisted root-cause pass on one specific failure (a build id, an app that's crash-looping) and returns a short explanation plus the recipe to apply.
support_file_ticketFiles a customer support ticket with the conversation so far attached. Fires automatically on unresolved questions; you can also invoke it explicitly ("please open a ticket").

When the bot cannot answer​

If the bot works through its tools and still cannot resolve your question — the failure is novel, the fix needs Clue2Solve staff, or you explicitly ask for a human — it calls support_file_ticket and returns:

  • the ticket ID (e.g. SCK-649)
  • a one-line summary of what it captured
  • the estimated first-response SLA for your account tier
  • a link to /support/tickets where you track every ticket you have open

The ticket lands in Clue2Solve's customer support Jira project with the conversation transcript, your app/project context, and any tool outputs the bot already gathered — support staff pick it up from there and reply into the ticket. You do not need to re-explain the problem.

Privacy — what the model sees​

Bot conversations flow through the Daari LLM Gateway, the same gateway apps use for their own LLM traffic. Two rules apply to every message:

  1. Tool responses are redacted before they enter the model context. Emails, JWTs, API keys, cookies, and anything matching the platform's secret pattern set is stripped and replaced with a placeholder token before the tool result is handed to the model. The model never sees the raw value.
  2. Your session data stays inside your tenant boundary. The gateway routes your prompts to the model without leaving your account's isolation. The bot is pinned to claude-haiku-4-5 and all traffic goes through the Daari LLM Gateway; requests never bypass the gateway, and the underlying provider is subject to change without notice.

The redaction pattern set and its exact regexes are governed by the platform's Data Classification Catalog (SOC 2 evidence surface, published separately to customers on request today; slated for public docs once reviewed).

Managing your MCP token​

The MCP export uses a per-user scoped token. To rotate or revoke it, visit Access → Support MCP (/access/support-mcp) in the console. Rotating issues a new token and immediately invalidates the previous one; a client using the old value will start getting 401 Unauthorized on its next call.

FAQ​

Does the bot answer billing questions?​

Yes for account and plan questions ("what plan am I on," "when does my trial end," "who is my ACCOUNT_ADMIN"). It escalates to a human for changes — plan upgrades, payment-method updates, invoice disputes — because those require billing-side actions that are not exposed through the bot's tool surface.

Can I export my chat history?​

Not in Phase 1. Widget conversations are session-scoped (they clear when you close the tab); MCP conversations live client-side in your assistant's own transcript. If a conversation results in a filed ticket, the transcript is preserved on the ticket itself and visible in /support/tickets.

Session export is on the Phase 2 roadmap.

What model does the bot use?​

claude-haiku-4-5, pinned, routed through the Daari LLM Gateway. The gateway is provider-agnostic and the underlying provider can change without notice; requests never bypass the gateway, and the model choice can change without any change to the tool surface.

Can I use the bot from the CLI?​

Not directly today. The CLI's c2a verbs give you the underlying primitives (c2a app get, c2a app logs, c2a builds list --failed) that the bot's tools compose. If you already prefer the CLI you likely do not need the bot; the bot's audience is people who want a conversational surface over the same data.

The bot said it filed a ticket but I don't see it in /support/tickets​

There is a short indexing lag between ticket creation and its appearance in the list. Refresh after 30 seconds; if it still is not there, open a ticket the old-fashioned way through Access → Contact support and reference the ticket ID the bot returned — support staff can reconcile.