Portlatch

A mock-up of the screen, drawn from its layout, palette and typefaces. A build follows the full prompt below.

Start from this screenRead the build prompt

Typefaces

The catalog's own faces. A screen composed into a template is drawn in that template's typefaces.

• Source Sans 3Headings: Source Sans 3 600, 22px page title; 18px section titles
• Source Sans 3Body: Source Sans 3 400 16px/1.5

Patterns

• account settings sidebar with long flat list
• client selector chip group with icons
• per-client setup instructions panel
• promo/entitlement banner with badge
• searchable tool list with added-item chips
• checkbox options with helper descriptions
• section headers with right-aligned doc links

States it is designed for

• no client selected (first chip preselected)
• client with one-click setup vs manual config
• no tools added (helper text)
• search no results
• saving / saved / failed with retry
• free plan (banner shows upgrade) vs paid (banner shows entitlement)
• token missing (instructions link to create one)

Who it is for

• developers using AI assistants
• ML practitioners
• power users of agent tools

Layout

1. global top bar
2. settings sidebar (same as other account pages) with MCP item active
3. main: title + description; green-tinted banner with 'Pro' badge and entitlement text
4. 'Set up with your AI assistant' section with feedback link; chip group of clients (selected dark), instruction line, inner card with action button and note
5. 'Hosted tools' section: description, search input, added-tool chips with delete, open and view icons
6. option checkboxes in two columns with helper text
7. 'Configure tools' section with docs link and a table of built-in tools with toggles
8. mobile: chips wrap; options stack

Palette

Helpful and technical; a configuration page that feels like a guided setup.

• page background#ffffff
• section card#f7f8fa
• primary text#111827
• secondary text#5f6672
• selected chip#111827
• chip border#8a8f98
• banner fill#e9f8ee
• banner text#166534
• checkbox / link accent#2d5bd7
• divider#e5e7eb

Every checked pair, measured again

As vibld’s tokens

The palette on the fifteen colour tokens vibld styles a project with, each text colour on the fill it is read on. Marked tokens are solved from the palette, because no swatch held that role at 4.5:1.

• background
• card
• muted
• primary
• secondary
• accent
• destructive *

Type scale

Display

Source Sans 3 600, 22px page title; 18px section titles

Body

Source Sans 3 400 16px/1.5

Chip labels 15px 500; tool ids JetBrains Mono 14px; badge 12px uppercase 700 with 0.06em tracking.

Spacing and imagery

Comfortable: sections separated by 40px; chip group gap 8px, chips 32px tall with 8px radius; inner card 16px padding, 8px radius; options grid 2 columns with 24px gap.

Small generic client icons in chips (draw neutral glyphs: terminal, editor, chat bubble, desktop app); no third-party logos; line icons for actions.

Components

• SettingsSidebar
• EntitlementBanner
• ClientChipGroup
• ClientInstructions (config snippet with copy, deep-link button)
• ToolSearch (combobox)
• AddedToolChip (remove, open, view)
• OptionCheckbox with description
• BuiltInToolsTable with toggles
• DocsLink

Interactions

• selecting a client swaps the instructions (JSON config, CLI command or one-click button)
• copy buttons for config snippets
• tool search suggests matching hosted tools after 2 characters; Enter adds
• removing a tool asks no confirmation but offers undo
• option and tool toggles save immediately with a small 'Saved' indicator
• feedback link opens a short form

Data

• McpSettings{user_id, enabled_builtin_tools text[], dynamic_tools bool, strip_embedded_images bool, updated_at}
• McpToolRef{id, user_id, tool_slug, added_at}
• Client{id, label, setup_kind (oneclick|json|cli), template}
• AccessToken{id, user_id, scope, prefix, created_at}

Guardrails

Experience

• Use generic client labels in mocks (e.g. 'Desktop assistant', 'Code editor', 'Terminal agent', 'Other client').
• Show only the instructions for the selected client; keep the chip group visible for switching.
• Interpolate the user's server URL into snippets but reference tokens by environment variable.
• Save toggles instantly and show a quiet confirmation.
• Explain each option in one line under its checkbox.

Accessibility

• Client chips are a radio group with visible labels; selected state has fill and aria-checked.
• Tool search is an ARIA combobox with listbox results and announced counts.
• Checkbox helper text is linked with aria-describedby.
• Copy buttons announce success in a live region.
• Doc links indicate they open in a new tab.

Security

• Never render full tokens; show prefixes and link to the token page.
• RLS: settings and tool refs readable and writable only by their user.
• Validate tool slugs against the hosted catalogue server-side.
• Scope server tokens to read-only by default and allow revocation.

Build prompt

The baseline every prompt in the catalog assumes, then this design’s own ten sections, from goal to guardrails.

Copy the baseline and build prompt

### How to use these prompts
Paste an entry's build prompt into your coding agent as the first message. Each prompt names its own stack, tokens and acceptance criteria; the rules below apply to all of them and can be prepended once per project.

### Engineering baseline
- TypeScript strict mode, no `any`, small typed components, feature folders, and one source of truth for design tokens (CSS variables consumed by Tailwind).
- Validate every input with a shared zod schema on the client and again on the server or edge function. Never trust client-side checks alone.
- Show loading, empty and error states for every async view. Surface errors in plain language with a retry, and log details to the console in development only.
- Keep secrets out of the bundle. Only publishable keys (for example a Supabase anon key) belong in client code; service-role keys, API keys and webhooks live in server or edge-function environment variables.

### Data and auth baseline (full-stack entries)
- Enable Row Level Security on every table before inserting data. Default-deny, then add owner-scoped policies (`auth.uid() = user_id`) and explicit role checks for admin views.
- Store roles in a separate table checked by a security-definer function, never in a user-editable profile field.
- Upload files to private storage buckets with size and MIME limits, and serve them through signed URLs.
- Rate-limit public endpoints (forms, auth, AI calls) and add a honeypot field or captcha to anonymous forms.
- Take payments through a hosted checkout and verify webhooks by signature. Never handle raw card data.

### Accessibility and UX baseline
- Target WCAG 2.2 AA: 4.5:1 contrast for normal text and 3:1 for large text, input borders, focus rings and meaningful icons or chart lines. Every palette in this catalog lists its verified pairs; re-check with a contrast tool after any colour change.
- Keep body text at 16px or larger with 1.5 line height, nothing below 12px, no light weights under 24px, and uppercase only for short labels.
- Give every interactive element a visible focus ring, full keyboard support, semantic landmarks, labelled form fields, and alt text on meaningful images.
- Respect `prefers-reduced-motion` for every animation. Give drag-and-drop and carousels keyboard and button alternatives.
- Build mobile-first and test at 375px, 768px and 1280px.

### Content guardrails
- Use original copy, fictional sample data and placeholder or licensed imagery. Do not reuse another product's name, logo, screenshots or marketing text.
- Label demo testimonials and metrics as samples. Collect the minimum personal data the feature needs.

### SaaS screen baseline
- Design every screen for its full set of states: first-run empty, loading skeleton, partial data, error with retry, permission-denied, and success feedback. Each entry lists the states its screen needs.
- Keep destructive actions (delete, revoke, downgrade, remove member) behind a confirmation that names the object, and prefer undo over a second dialog where the action is reversible.
- Enforce authorisation on the server for every action a screen exposes. Hiding a button is not access control; check the role again in the API or RLS policy.
- Never show secrets (API keys, tokens) in full after creation. Show them once, then mask them, and offer rotate and revoke.
- Keep the app shell (navigation, workspace switcher, account menu) consistent across screens, and preserve filters, sort and scroll position when the user navigates back.

### Goal
Build **Portlatch**, the Model Context Protocol server settings page of a model hub. Users pick their AI client to see matching setup instructions, add hosted community tools to their server, and toggle server options, with every change saved instantly.

### Stack
React 18 + TypeScript + Vite, Tailwind CSS, shadcn/ui (RadioGroup, Command, Checkbox, Switch, Table, Toast), lucide-react, TanStack Query, react-hook-form + zod. Supabase Auth and Postgres.

### Pages & layout
1. **Settings shell**: top bar and settings sidebar.
2. **/settings/mcp**: banner, client setup, hosted tools, options, built-in tools table.
3. **/settings/tokens** link target (placeholder list).
4. Mobile: single column, chips wrap.

### Design system
- Colors: `--bg: #ffffff` (page background), `--card: #f7f8fa` (section card), `--fg: #111827` (primary text), `--muted: #5f6672` (secondary text), `--chip-selected: #111827` (selected chip), `--chip-border: #8a8f98` (chip border), `--banner: #e9f8ee` (banner fill), `--banner-fg: #166534` (banner text), `--accent: #2d5bd7` (checkbox / link accent), `--divider: #e5e7eb` (divider).
- Fonts: Source Sans 3 600, 22px page title; 18px section titles for headings; Source Sans 3 400 16px/1.5 for body. Chip labels 15px 500; tool ids JetBrains Mono 14px; badge 12px uppercase 700 with 0.06em tracking.
- Spacing: Comfortable: sections separated by 40px; chip group gap 8px, chips 32px tall with 8px radius; inner card 16px padding, 8px radius; options grid 2 columns with 24px gap.
- Radius: 8px chips, cards and inputs; full pill for the banner badge.
- Shadows: none.
- Motion: 150ms chip selection; 'Saved' indicator fades after 1.5s.

### Components & interactions
SettingsSidebar, EntitlementBanner, ClientChipGroup, ClientInstructions, CodeBlock, CopyButton, ToolSearch, AddedToolChip, OptionCheckbox, BuiltInToolsTable, SavedIndicator, FeedbackDialog.

Interactions: selecting a client swaps the instructions (JSON config, CLI command or one-click button); copy buttons for config snippets; tool search suggests matching hosted tools after 2 characters; Enter adds; removing a tool asks no confirmation but offers undo; option and tool toggles save immediately with a small 'Saved' indicator; feedback link opens a short form.

States to build: no client selected (first chip preselected); client with one-click setup vs manual config; no tools added (helper text); search no results; saving / saved / failed with retry; free plan (banner shows upgrade) vs paid (banner shows entitlement); token missing (instructions link to create one).

### Data & state
Client definitions are static config with setup templates. Settings upsert on change (debounced 400ms); tool refs insert/delete with optimistic updates and undo. Seed a user with one added hosted tool and two options on.

Model: `McpSettings{user_id, enabled_builtin_tools text[], dynamic_tools bool, strip_embedded_images bool, updated_at}`; `McpToolRef{id, user_id, tool_slug, added_at}`; `Client{id, label, setup_kind (oneclick|json|cli), template}`; `AccessToken{id, user_id, scope, prefix, created_at}`.

### Accessibility
Client chips are a radio group with visible labels; selected state has fill and aria-checked. Tool search is an ARIA combobox with listbox results and announced counts. Checkbox helper text is linked with aria-describedby. Copy buttons announce success in a live region. Doc links indicate they open in a new tab.
Verified contrast: body text: #111827 on #ffffff = 17.74:1; muted text on card: #5f6672 on #f7f8fa = 5.44:1; selected chip label: #ffffff on #111827 = 17.74:1; chip border: #8a8f98 on #ffffff = 3.25:1; banner text: #166534 on #e9f8ee = 6.49:1; checkbox / link accent: #2d5bd7 on #ffffff = 5.85:1.

### Security
Never render full tokens; show prefixes and link to the token page. RLS: settings and tool refs readable and writable only by their user. Validate tool slugs against the hosted catalogue server-side. Scope server tokens to read-only by default and allow revocation. RLS per table: `mcp_settings` and `mcp_tool_refs` select/insert/update/delete where `user_id = auth.uid()`; `access_tokens` select own (prefix only via view), insert via Edge Function; the tool catalogue is read-only public data.

### Performance & SEO
Debounce search at 200ms and cache results. Settings routes noindex.

### Guardrails
- Use generic client labels in mocks (e.g. 'Desktop assistant', 'Code editor', 'Terminal agent', 'Other client').
- Show only the instructions for the selected client; keep the chip group visible for switching.
- Interpolate the user's server URL into snippets but reference tokens by environment variable.
- Save toggles instantly and show a quiet confirmation.
- Explain each option in one line under its checkbox.
- Write all copy fresh; use invented people, companies and numbers only. No real brands, logos, wordmarks or third-party product names anywhere in the UI or seed data.
- Do not trace or copy any existing product's layout assets, icons or illustrations; draw generic ones.
- Acceptance criteria:
  - [ ] Switching clients swaps instructions
  - [ ] Snippets include the user's server URL and no secrets
  - [ ] Tools can be searched, added and removed with undo
  - [ ] Option toggles persist across reloads
  - [ ] All controls work by keyboard with visible focus

Open the builderAll templatesThis palette on its own