unabyss-onboard

name	unabyss-onboard
description	Connect Unabyss MCP, drive the server-side unabyss_setup first-connect flow, then verify with whoami or query once the setup gate lifts.

Onboard Unabyss

Use this when the user asks to set up Unabyss, connect their context, finish MCP setup, or when Unabyss tools are missing / returning setup guidance after the plugin is installed.

Unabyss already runs a per-connection setup on the hosted MCP. Do not invent a parallel onboarding path. Drive unabyss_setup (and the unabyss-setup prompt if the client exposes it).

1. Confirm the MCP server

Unabyss is a hosted Streamable HTTP MCP at https://mcp.unabyss.com/.

If Unabyss tools are not available at all:

1. Try authenticating with mcp_auth on the Unabyss MCP server.
2. If that is unavailable, tell the user to open Cursor Settings → Tools & MCP, find unabyss, and click Connect (or use Command Palette → MCP).
3. Do not invent tokens or ask the user to paste secrets into chat unless they explicitly want a static unby_mcp_ token from app.unabyss.com/mcp.

If auth fails, continue the coding task normally and note that personal context is unavailable until they Connect.

2. First-connect setup (unabyss_setup)

After Connect, initialize may include an optional first-connect directive. While setup is unresolved for this credential, most tools stay gated: they return setup guidance text instead of real data (not an auth error).

Allowed while the gate is active:

• unabyss_setup
• list_skills, get_skill, read_skill_file
• list_integrations, propose_connection (for the Apps step)

Blocked until setup is completed or skipped: whoami, query, agentic_query, store, exports, and other non-whitelist tools.

Drive the flow

1. Call unabyss_setup with step1 (default opener). Relay user-facing text as written; follow the agent-only "Next step" notes.
2. Continue through the steps the server returns. Typical path:
   • step1 - what Unabyss is and which steps apply
   • step2 - connect apps via list_integrations / propose_connection (skipped when the user already finished web onboarding with ≥2 apps)
   • step3 - what to save back to Unabyss
   • step4 - client system prompt; pass the user's context_preference when the server asks for it
   • step5 / skill listings - optional skill overview (all-skills, essential-skills, or <category>-skills)
3. If a gated tool returns setup guidance, call unabyss_setup (or continue where they left off) instead of retrying whoami / query.
4. If setup was started but not finished, the gate may offer a skip hatch on a later gated call - only skip after the user explicitly wants to move on.

Hard rules

• Never record completed or skipped on your own. Only call those outcomes after the user explicitly chooses.
• Do not call whoami, query, or other gated tools until the gate lifts (or the user has skipped).
• During step2, present every available app; use propose_connection and give the user the connect link. The server expects at least 2 connected apps before later steps when web onboarding is not done yet.
• Prefer the unabyss-setup prompt / slash command when the client offers it; it opens the same step1 content.

3. Verify after the gate lifts

Once setup is completed or skipped and tools return real data:

1. Call whoami and summarize identity briefly.
2. Optionally run one small query that matches something they care about (stack, preferences, current project).

4. Ongoing use

• Tool reference: unabyss.com/mcp-docs
• More apps later: list_integrations / propose_connection (do not ask the user to paste data)
• Playbooks: list_skills / get_skill instead of inventing long procedures
• Day-to-day context rules live in the plugin's Unabyss integration rule