Support Through Your AI Assistant

If you've connected an AI assistant (an "MCP harness" — Claude, ChatGPT, Cursor, and so on) to StackJack, it can work with StackJack support directly. StackJack exposes a set of built-in stackjack_* tools that let your assistant check platform status and file, read, and reply to support tickets on your behalf.

Tickets your assistant files are opened in Featurebase, the same place your widget conversations live, so you and the StackJack team work one thread either way.

Checking platform status and advisories

These tools are available to any connected assistant:

There is no public status page — asking your assistant to run stackjack_get_service_status is the way to answer "is StackJack having an issue right now?"

Ticket tools

All four ticket tools are available automatically to any assistant you connect yourself. They don't need to be added to your connection's allowed-tools list, and a restricted tool list doesn't hide them — the same is true of the status and advisory tools above. (Only StackJack's automation tools work differently: running an automation requires the Agentic Orchestration feature and, per client, an explicit grant.)

Ticket ids. stackjack_create_support_ticket returns two numbers. ticketId is StackJack's own id, and it is the one stackjack_get_support_ticket and stackjack_add_support_ticket_message accept. ticketNumber is the Featurebase number a person quotes when following the ticket up with support.

StackJack automations are the exception. An automation runs against its own MCP connection, and on those connections the two write tools — stackjack_create_support_ticket and stackjack_add_support_ticket_message — are unavailable unless a person has turned them on for that specific automation. The two read tools stay available either way.

Filing a ticket after a failed tool call

When one of your assistant's StackJack tool calls fails with an error worth escalating (authentication failures, upstream connector errors, timeouts, and similar), the error response your assistant receives includes a ready-made support ticket draft — a suggested subject, description with the failing tool and error details, and a priority. Your assistant can show you the draft and file it with one stackjack_create_support_ticket call, so "that failed — want me to open a ticket with StackJack?" is a one-step handoff.

Tickets filed this way by an assistant you connected carry the technical context (failing tool, error type, correlation id) into the Featurebase ticket body, so support can start from the actual failure, and the same diagnostics bundle a widget-filed ticket gets is attached automatically. Any error context your assistant includes is validated, length-capped, and put through pattern-based masking of common credentials and tokens before it's stored — the same best-effort masking described in Submitting a ticket, not a guarantee that every sensitive value has been removed. Tell your assistant not to paste secrets, and read what it proposes before you approve the ticket. You also get a "we received your request" email from StackJack on this path. Tickets filed by an automation work differently — see the next section.

Opening a ticket does not start StackJack's automated research. A StackJack operator starts that deliberately, and only operators see the result. See Replies and notifications.

Guardrails you might notice

• Duplicate suppression. If a matching assistant-created ticket (same failing tool and error) was already opened in the last 15 minutes and isn't closed, StackJack returns the existing ticket's id instead of creating a duplicate — your assistant will report that a matching ticket already exists.
• Volume cap: 30 attempts per hour. An organization gets 30 create attempts per hour, counted across every connected assistant and automation together. The counter increments before the duplicate check, so an attempt that is answered with an existing ticket id still spends one of the 30 — the cap is a runaway-loop guard, not a count of tickets you received. Beyond 30, creation is rejected until the next hour; open urgent issues in the messenger instead.
• No diagnostics in responses. Ticket responses returned to your assistant never include the internal diagnostic files — those are for the support team.
• The support lane can report itself unavailable, and not every failure means the same thing. If StackJack's connection to Featurebase is not configured, no ticket was attempted and nothing exists anywhere — that one is unambiguous. If the call to Featurebase was attempted and failed, your assistant is told no ticket was opened, and StackJack releases its duplicate guard so a retry is free to try again. A third outcome is possible but rare: the Featurebase ticket is created first and StackJack's own record is written second, so an unexpected failure between the two can return an error over a ticket that does exist. Before refiling the same report, ask your assistant to run stackjack_list_support_tickets, or look in the messenger. StackJack also holds a short duplicate claim on an identical report, so an immediate retry converges on the ticket the first attempt opened rather than opening a second one.

When an automation files a ticket

A StackJack automation can open a support ticket when a run hits a platform or connector error. This is a separate, narrower path from the assistant you connected yourself, and it is off unless someone turns it on.

It's off by default, and only a person can turn it on

• New automations start with ticket filing off. The automation reports the error in its run output only.
• Automations that existed before this changed keep the capability, because it used to be implicit — they were switched on so nobody lost it silently. The diagnostics opt-in below was left off for every automation, new and existing alike.
• An automation can never grant itself either setting. They're writable only from the Portal; an attempt to set them from the AI-assistant side is refused outright, in either direction. That's deliberate — an automation that could enable its own diagnostics and then file a ticket would be a way to push your data out.

You control both settings per automation: open the automation's builder in the Portal (Automations → the automation, or /automations/builder/<automation-id> directly), scroll to Guardrails and deploy, and use the two controls in the Guardrails and consent card:

Turning the main switch off also clears the diagnostics opt-in, so re-enabling later is a fresh decision rather than a silent restore.

While the main switch is off, the two ticket-writing tools don't appear in that automation's tool list at all, and a call to either one is refused with a message naming the setting to turn on.

What's in the diagnostics when the opt-in is off

With the diagnostics opt-in off — the default for every automation — a ticket the automation files gets a platform-only diagnostics bundle. Specifically omitted:

• Member and invite records, and any email addresses.
• Identity ids for your users.
• Connector validation-error and "why it was disabled" text (free-form fields most likely to contain a leaked value or customer data).
• Error message text from your recent tool calls.

What remains is the platform picture support needs to triage: connector types with their enabled/valid status, plan and subscription state, counts (how many active members, how many pending invites), and which tool calls ran, whether they succeeded, and how long they took. The bundle is explicitly marked as having identity detail omitted, so support knows to ask you rather than assume.

Turning the opt-in on restores the full bundle — the same one a widget-filed ticket gets.

One thing this setting does not cover: every ticket, from every source, also carries StackJack's own server-log bundle for your organization. Neither switch affects it. That bundle goes through the same pattern-based masking of common credentials and tokens described in Submitting a ticket — a best-effort filter for recognized secret shapes, not a promise that every sensitive value has been removed.

Repeat errors are appended, not re-filed

If the same automation hits the same failing tool and error type again within 24 hours, StackJack adds an occurrence note to the ticket it already opened instead of filing a new one, mirrors that note onto the Featurebase conversation, and reports the existing ticket's id.

You'll see those notes in the conversation — they read "Automated occurrence report: this agent hit the same error signature again…" and appear as your organization's own messages, because your automation, not StackJack support, wrote them.

Closed tickets are excluded from that match — if you close a ticket and the failure comes back, the automation opens a fresh one rather than reopening the closed thread.

The daily cap

Across all of your organization's automations, at most 20 new automation-filed tickets per day. Past that, further tickets are suppressed: no ticket is created, and the automation is told this is expected rather than an error, so it doesn't retry or treat the suppression as its own failure. If something needs attention while you're capped, open it in the support widget.

Where the two surfaces meet

Featurebase holds the conversation; StackJack holds its own mirrored copy. A ticket your assistant opens appears in your widget, and a reply you send from the widget becomes visible to your assistant through stackjack_get_support_ticket once StackJack mirrors the update. Internal operator notes — including StackJack's AI research findings — are deliberately left out of that mirror, so your assistant never sees them either.