Kit MCP page

The page could have been four tabs (Setup + Capabilities + Activity, with Prompts and Tools folded together), or six (separating first-time Setup from ongoing connection management). We landed on five for two reasons. First, Prompts and Tools serve different mental models — Prompts are stitched workflows ("do this multi-step task for me"), Tools are atomic primitives ("show me which API actions exist"); collapsing them hides that distinction at the exact moment creators need it. Second, Overview earns its slot as the landing surface because most session visits aren't first-time setups — creators come back to grab the MCP URL, browse recipes, or check how things are working, and a hero + recipes layout serves that intent better than dropping them into Connections by default.

Order matters too: Overview → Connections puts the value proposition before the setup, so creators encounter "why" before "how." Activity sits last because it's the surface creators use after they've connected (verification, audit, debugging) rather than during onboarding. The order is deliberate even though tabs are non-linear.

Setup is the moment that breaks. The earlier iteration tried to handle setup inline in the hero card on a single-page surface, which compressed five distinct client setup rituals into a single "Walk through setup for Claude, ChatGPT, or Cursor →" link. That link pointed to # in the prior prototype because there was nowhere good to point it to.

Making Connections a dedicated tab gives setup the surface area it actually needs — an intro, a per-client deep dive, a verification path, and troubleshooting — without pushing it deep into a modal or settings page. The Overview tab still keeps a setup affordance ("Upgrade to connect" buttons, the MCP URL card, and "Walk through setup" link) so creators who already know what they want can move fast. Connections is where creators go when they don't.

Our prior is Variant B (card grid + drilldown). Setup is a high-effort one-time task that benefits from depth (method picker, copy-ready config, verification, troubleshooting in one focused view) more than from breadth, and Stripe Connect's per-platform card flow validated that one extra click is acceptable when the detail page does meaningfully more. Variant A (the Figma reference) is the safer pattern — it puts every client in the eye line and matches what reviewers expect to see — but its detail per client is shallower because the tab format can't comfortably hold a method picker plus a troubleshooting accordion without scrolling beyond the fold.

We'll decide between them on three criteria from prototype review and (if possible) a 4–6 creator usability pass: (1) time-to-first-tool-call after landing on Connections, (2) whether creators who don't know which client they'd use feel oriented by the variant, (3) drop-off rate before reaching the copy-paste config. Variant A wins if creators stall in B's grid trying to pick a client; Variant B wins if creators in A skim the steps but bail on the first troubleshooting question they hit. We're not asking the team to pick a winner from the prototype alone — we're asking which criteria are missing.

Each client's setup steps in this prototype reflect the actual UX as of May 2026 — not a generic "edit config.json" template. Claude Desktop steers creators to the Connectors UI (and explains, in the FAQ, why pasting a remote URL into claude_desktop_config.json silently fails). ChatGPT calls out the Developer mode toggle that's hidden by default and the Plus/Pro write restriction. Cursor leads with a one-click deep link (the lowest-friction option since Cursor 0.40+) and notes the ~40 tool cap. Claude Code uses claude mcp add --transport http with explicit scope flags.

This matters because every wrong instruction in a creator-facing setup flow becomes a support ticket. The Variant B troubleshooting accordion captures the failures that real users hit — "I don't see Connectors" (free plan), "No tools found" (tool cap or restart needed), "Add to config.json did nothing" (wrong file). These are concrete; not theoretical.

Research across SaaS onboarding flows points to "first-call success state" as the most reliable connection signal — the moment the server sees the first authenticated tool call, the UI flips to Connected. Building a separate "Connection status: ✓" widget would duplicate state and risk drifting from reality. The Activity tab already has to exist for trust and audit reasons; making it the verification surface means the same thing the creator sees on day 30 is what they saw on minute one.

Both Connections variants include a verify strip with "Ask: What Kit account am I connected to?" and a hard link to the Activity tab. The implicit message is: don't trust a status widget, watch what your AI tool actually does.

The previous ai-tools iteration showed a Gemini logo on the hero card alongside Claude, Cursor, and OpenAI/ChatGPT, but had no setup instructions for Gemini and used "OpenAI" instead of "ChatGPT" everywhere else. Logos without instructions are the worst of both worlds — they teach creators to expect support and then strand them when they try. Either path (full support or remove) is honest; the broken middle isn't.

This iteration commits to full Gemini CLI support: a tab in Variant A, a card in Variant B, and a real setup flow using ~/.gemini/settings.json. ChatGPT is named ChatGPT everywhere. We're committing because Gemini CLI's install base skews toward the developer-leaning end of Kit's creator segment — the same segment that's most likely to be early MCP adopters — and parity with the other three clients costs us a single tab and a JSON snippet, not engineering work. If validation review surfaces that Gemini volume doesn't justify the surface area, the cleanup path is to drop the tab and card; what we're not going to do is keep the logo and skip the instructions.

Prompts and Tools are the two MCP concepts creators have the weakest mental model for, and the explanation has to live somewhere. The candidates were: (1) modal on first visit, (2) inline definition as a heading paragraph, (3) tooltip on a "?" icon, (4) a dismissable banner above the content. We picked the banner because it's the only option that's cheap to dismiss but hard to miss — modals block work and feel heavy, inline definitions get scrolled past and absorbed into the noise of "more body copy," and tooltips require a deliberate hover that creators don't do when they're skimming. The Figma references use banners and we preserved the pattern; we'd have picked the same thing from scratch.

The banner intentionally includes a "Learn more about prompts →" CTA rather than fully explaining the concept inline — the goal is "read it once on first visit, ignore it after," not "teach MCP theory in 200 words." The destination of that link is still TBD; minimum is a Help Center article, ideal is a short video.