Leaning toward Automations, pressure-testing Settings → Developer Settings with Design
Kit's existing V4 API Keys UI sits under Settings → Developer Settings — the conventional home for tokens, aimed at developers building on the API. Putting the MCP setup there would be the cheapest path: we could reuse the existing kit_… key creation flow, the same one-time reveal modal, the same list UI, and ship in days.
Our current preference is to put it under Automate instead — the brief explicitly flagged Automations as the intended home, and the mental model fits ("an AI acts on my behalf based on what I ask it" is a sibling to Rules and Visual Automations, not to API keys). Placement under Automate also signals this is for every creator, not only the subset who've written code. The tradeoff is that we're introducing a second token concept (MCP tokens here, V4 API keys in Developer Settings) and need to keep them visually distinct — the prototype prefixes MCP tokens with kit_mcp_. Placement is in the validation questions below because we want Design to pressure-test it before we lock it.
Kit Automate IA (menu-definitions.js) · feature brief
Token-first for beta; OAuth teased as the next step
The MCP authorization spec (2025-06-18) recommends OAuth 2.1 with dynamic client registration, and competitors like Linear and Notion lead with big "Connect to Claude" OAuth buttons — the friendliest path for a non-technical audience. For beta, OAuth is the right destination but not the right starting point: Kit's existing API-key infrastructure (the kit_… format, one-time reveal modal, reset/revoke flow) can be extended to MCP tokens in days, whereas a production OAuth flow for MCP is weeks.
The prototype ships tokens as the primary mechanism and leaves visible space for an OAuth upgrade — so when OAuth lands, it's a UI addition, not a restructure. The "Which client are you connecting?" framing in the tabs also makes OAuth a natural per-client button to add later, without reshuffling anything else on the page.
MCP authorization spec · Linear · Notion · Kit api_key.rb
One-time token reveal with an "I've saved this" acknowledgement
Every serious token UI — Stripe API keys, GitHub PATs, Kit's own existing KeyCreatedModal — shows the token value exactly once on a confirmation screen with a copy-to-clipboard button and a warning. Breaking this convention registers as a security red flag. The hash (not the token) is stored server-side, so a breach can't expose usable tokens.
What the prototype adds on top of Kit's existing pattern is an "I've saved this token" acknowledgement checkbox that must be checked before the Done button activates. GitHub relies on a warning banner alone and users still tab away without copying; the extra click makes the contract explicit. The modal can't be closed with Esc — only via Done after acknowledgement — because the failure mode (lost token, creator has to revoke and start over) is worse than the friction of one extra click.
Stripe · GitHub · Kit KeyCreatedModal
"USB-C port for AI" analogy placed above the enable toggle
Kit's audience is overwhelmingly non-technical, and activation is a known friction point in Automations — the most-cited theme in Enterpret records about automation setup is conceptual confusion, not configuration errors. A setup page that leads with "enable MCP" and buries the concept below is optimised for people who already know what MCP is — not the people we're actually launching to.
The prototype leads with the "USB-C port for AI" analogy from the official MCP docs — a mental model creators can picture physically, already socialised across Cloudflare and other places they might have read about MCP. It's paired with a small Kit ↔ MCP ↔ AI client diagram and three concrete Kit example prompts. The explainer sits above the enable toggle specifically so creators read what MCP is before flipping the switch. We avoid "protocol", "standardised interface", and "API surface" in the first 100 words.
modelcontextprotocol.io · Cloudflare · Kit VA v2 internal research
Per-client tabbed setup with copy-paste config, not a wizard
An alternative framing would be a multi-step wizard: pick your client, answer a few questions, click Next, generate a token, paste the config. We rejected that because wizards front-load commitment — a creator just exploring can't see what they're signing up for without walking through the whole thing.
Every MCP-native product we looked at (Neon, Linear, Intercom, Zapier) instead ships per-client tabs with a single copy-paste JSON block per tab. It's a small sample — worth flagging that we may be pattern-matching, but the pattern is consistent enough that bucking it would need a stronger reason than we have. The creator reads only the instructions that apply to their client, sees the exact snippet they'll paste, and can experiment with a different tab without losing state. Kit's four tabs cover Claude Desktop, ChatGPT, Cursor, and Claude Code. We also match Claude's native "Add custom connector" field names exactly, so there's zero translation burden between our docs and Claude's UI.
Neon · Linear · Intercom MCP docs · Claude connector UI
Read-only default scope, write scope opt-in for beta
Beta scope is deliberately narrow. New tokens default to read-only; read-and-write is a second radio option that we can — in a follow-up — gate behind a confirmation modal enumerating what could change (create/delete subscribers, send broadcasts, etc). Coarse scopes are enough for now. Once we learn what creators actually want to let AI do, we can add per-resource granularity (the Stripe restricted-keys pattern).
This is a judgment call on safety versus expressiveness. A more expressive scope model (per-resource Read/Edit/None matrix) would be defensible, but at two weeks out it risks over-engineering a beta surface that we'll iterate on based on real usage. Read-only default + opt-in write lets us ship with low blast radius and raise the ceiling later.
Stripe restricted keys · GitHub fine-grained tokens · beta scoping
Success state with Kit-specific example prompts ("What can I ask Claude?")
Token setup flows almost universally end at "Connected ✓" and strand the creator at the hardest step: knowing what to actually say to the AI. Zapier, Asana, and Notion all solved this the same way — after successful connection, surface a curated list of example prompts the creator can click to copy into their AI client.
For Kit, these are concrete and creator-specific: "Summarize my last 5 broadcasts and their open rates", "Draft a welcome email in the style of my 'Newsletter 101' sequence", "Which tags have grown the most this month?", "Create a segment of subscribers who opened my last 3 emails". Each is a copy-to-clipboard chip. This also doubles as a lightweight tool-discovery surface — creators learn what MCP can do for them by using it, not by reading a tool reference.
Zapier · Asana · Notion MCP success flows
Activity log visible even when empty — trust hypothesis, not settled
An activity log that only appears once there's activity is less useful than one that's visible from the moment MCP is enabled. Before first use, the empty state explains exactly what will appear: timestamp, token name, client, action, target. The hypothesis is that making "what could an AI actually do with my Kit account" concrete before the creator has used it lowers the trust bar to granting access — but this is untested and worth validating in reviewer feedback or creator interviews before we treat it as load-bearing.
For beta, the log is read-only and surfaced on this page only. A follow-up could add filtering by token or client, exportable audit logs, and Slack/email alerting on write actions. We don't need those in v1; the trust-of-empty-state is the part we want to pressure-test.
our call (no external precedent) · validation hypothesis
What we're deliberately not shipping for beta
Keeping scope tight for a two-week ship means several things are visible in the prototype as stubs or absent entirely. Flagging here so reviewers don't spend cycles on decisions we've already punted:
Deferred to post-beta: OAuth "Connect to Claude / ChatGPT" flows (token-first for now); per-resource scope granularity Stripe-style (coarse read-only vs read+write is enough); the destructive-actions confirmation modal when switching a token to read+write; activity log filtering, export, and Slack/email alerts on write actions; plan-tier gating; per-user vs per-account tokens (Kit accounts can have multiple users). Not in scope at all: a tool-reference page explaining every MCP action — the success-state example prompts are deliberately the only surface for that in v1.
beta scoping