Run the whole growth engine from your AI workspace.

Connect the official TrafficWins remote MCP, inspect this workspace, build its production-ready blog surface when needed, and configure a complete verified automatic-publishing TrafficWins content workflow.

Goal
- Connection name: trafficwins
- Remote Streamable HTTP endpoint: https://api.trafficwins.com/api/mcp
- Authentication: OAuth 2.1 (preferred)
- Scope: user/global, unless I explicitly ask for project-only configuration

Rules
1. Detect the current client and operating system from your runtime before changing anything. Supported clients include Codex, Claude Code, Claude web/desktop/mobile, Cursor, VS Code with GitHub Copilot, Windsurf, Gemini CLI, and ChatGPT. If TrafficWins is already connected, verify it and continue instead of adding a duplicate. If the client cannot be identified reliably, ask me one concise question and wait.
2. Use the client's native remote HTTP MCP support. Do not install an npm package, clone a server, create a local proxy, or modify application source code to host the MCP. TrafficWins is already hosted at the endpoint above.
3. Preserve all existing MCP servers and settings. Make the smallest additive configuration change. Back up a config file before editing it when the client does not provide a native add command.
4. Prefer browser OAuth. Never ask me to paste a password, OAuth code, access token, refresh token, API key, or publishing credential into chat. Never print secrets. Let the browser and client store OAuth credentials.
5. Use the matching native setup path:
   - Codex: run codex mcp add trafficwins --url https://api.trafficwins.com/api/mcp, verify with codex mcp get trafficwins --json, then run codex mcp login trafficwins. Use ~/.codex/config.toml only if the native command is unavailable.
   - Claude Code: run claude mcp add --transport http --scope user trafficwins https://api.trafficwins.com/api/mcp; then open /mcp and authenticate trafficwins.
   - Cursor: add trafficwins under mcpServers in ~/.cursor/mcp.json with { "url": "https://api.trafficwins.com/api/mcp" }, preserving existing JSON; enable it in Settings > MCP and authenticate.
   - VS Code: add trafficwins under servers in the user or workspace mcp.json with { "type": "http", "url": "https://api.trafficwins.com/api/mcp" }, preserving existing JSON; start it with MCP: List Servers and authenticate.
   - Windsurf: add trafficwins under mcpServers in ~/.codeium/windsurf/mcp_config.json with { "serverUrl": "https://api.trafficwins.com/api/mcp" }, preserving existing JSON; enable it in Cascade and authenticate. If more than 100 tools are active, keep only needed TrafficWins tool domains enabled.
   - Gemini CLI: run gemini mcp add --transport http --scope user trafficwins https://api.trafficwins.com/api/mcp; then run /mcp auth trafficwins.
   - Claude web or desktop: open Customize > Connectors > Add custom connector, use name TrafficWins and remote MCP URL https://api.trafficwins.com/api/mcp, then connect with OAuth. Once configured, the remote connector can also be used on supported Claude mobile clients. Do not use claude_desktop_config.json for this remote connector.
   - ChatGPT: in an eligible Business, Enterprise, or Edu workspace, enable Developer mode, open Settings > Apps > Create, use name TrafficWins, endpoint https://api.trafficwins.com/api/mcp, authentication OAuth, then scan tools and test the draft app.
   - Any other MCP client: consult its installed help or official documentation, configure a remote Streamable HTTP server named trafficwins with the exact endpoint above, and use OAuth discovery. Do not guess unsupported config keys.
6. Respect client, workspace, and enterprise MCP policies. If policy blocks custom servers, stop and report the exact policy or admin action needed; do not bypass it. If configuration requires browser or UI work and you have browser-control capability, perform it. Otherwise give me only the exact remaining clicks after completing every file and CLI step you can perform.
7. During OAuth, review requested scopes. TrafficWins OAuth is user-bound, not organization-bound. After connection, use list_organizations to discover every organization available to me. Pass organizationId on every organization-scoped call and change it when switching context. Never guess an organization ID or use one absent from list_organizations.
8. If OAuth is unsupported by this client, stop and explain that fallback requires a scoped TrafficWins API key from https://app.trafficwins.com/settings. Ask me to create it there and store it in TRAFFICWINS_API_KEY locally. Do not request the key in chat, and do not put a literal key in config or source control. Only configure a Bearer header through the client's documented environment-variable mechanism.
9. Restart or reload the client when its documentation requires it. Validate the result using the client's native MCP list/status/get command. Confirm all of these before declaring success: trafficwins is enabled; endpoint matches exactly; authentication is connected; TrafficWins tools are visible; no existing server was removed.
10. After connection, run safe read-only smoke tests: list my TrafficWins organizations, then list campaigns for one organization using its organizationId. Do not claim success from configuration alone.

Full blog bootstrap
11. Treat my use of this prompt as authorization only for read-only discovery and preparation of the decision form in steps 12-14. It is not authorization to edit source, create files, install dependencies, generate or store a secret, mutate TrafficWins, run a migration, deploy, publish, or change an external system. Do not begin implementation until I submit the form and explicitly approve the resulting scope. My approval covers only the selected blog-bootstrap actions. It never authorizes billing changes, invitations, deletion, destructive commands, unapproved database migrations, unrelated credential changes, unrelated deployments, social publishing, or content-generation schedules.
12. Before changing source, find the workspace root and read its AGENTS.md, CLAUDE.md, README, package manifests, framework config, routes, content models, sitemap/feed code, localization, tests, and deployment docs. Check source-control status and preserve existing work. Ignore node_modules, build output, generated files, coverage, caches, and vendor directories. Never read or print .env values, private keys, tokens, cookies, database dumps, or customer data. If local files are unavailable, say so and use TrafficWins website crawling as the fallback; never claim a codebase scan happened.
13. Produce a short evidence-based setup brief from the codebase and public site: framework and package manager; current blog routes and content source; CMS or publishing adapter; site URL and likely blog URL; supported languages; brand/product/audience evidence; existing visual theme, default color mode, color-scheme behavior, design tokens, typography, spacing, layouts, and reusable components; existing SEO, sitemap, RSS, analytics, and structured-data support; validation commands; missing pieces. Prefer repository facts over guesses. Ask one concise question only when an unresolved choice would materially change implementation.
14. Present one mandatory "Blog architecture decision form" before implementation. Use the client's native form, structured-question, or choice UI when available; otherwise use one compact numbered form. Do not drip questions across turns. Preselect and clearly label one recommended answer for every field using the setup brief, while showing consequences for alternatives. Require answers for: (a) publishing behavior: runtime publication with no build/deploy, static rebuild on publication, or manual/draft-only; (b) durable content source: existing database/CMS/KV, a named new runtime store, or repository files; (c) full TrafficWins payload archive, which is mandatory: database JSON/JSONB or R2/object storage, with the recommendation based on payload size, existing infrastructure, retention, privacy, and cost; (d) rendering: server/edge SSR, on-demand ISR/revalidation, or static generation; (e) public routes and whether existing URLs must remain compatible; (f) publication freshness: webhook-triggered cache purge/revalidation or a selected maximum cache TTL; (g) SEO discovery surfaces: blog index, category archives, dynamic sitemap, RSS/Atom, per-article plain text, and optional site-wide llms.txt/llms-full.txt; (h) locales, author/category display, and existing-content migration; (i) persistence changes: reuse current schema, prepare a migration for separate review, or use an external store; and (j) delivery scope: build only, build plus deploy, or build plus deploy plus TrafficWins destination/autoPublish/live verification. Do not offer a "do not store the payload" choice. Explain that repository-file storage plus static generation requires rebuilds. Explain any hosting, request-size, storage, egress, retention, privacy, cost, migration, or provider implication found during discovery. Include a final scope summary and ask for one explicit approval. A submitted form never counts as permission to apply a migration: always request separate approval immediately before any migration command.
15. After approval, implement selected architecture with the project's native framework and design system. For the recommended no-rebuild path, store articles in durable runtime storage and treat publication as data mutation, never as a source commit, route-file creation, build, or deployment. Use one dynamic template for every article and one for every category. Server-render or otherwise return crawlable article content and metadata in the initial HTML. Reuse existing layouts, tokens, components, content models, and localization. Minimum complete surface: accessible responsive blog index; category navigation plus category archive/filter routes; article route; draft-safe content schema; title, description, canonical URL, Open Graph, and social metadata; Article and Breadcrumb JSON-LD; sitemap inclusion; RSS or the framework's equivalent feed; empty and not-found states; sample neutral draft fixture only when the project needs one for validation; focused tests. Make the blog a native visual extension of the existing website or app. Inspect the actual theme implementation before designing: CSS variables and design tokens, Tailwind or framework theme configuration, root classes or data attributes, color-scheme provider, persisted user preference, system preference, typography, spacing, borders, radii, shadows, layouts, and shared components. Inherit the existing site shell and semantic tokens instead of creating a separate palette. Respect the site's existing default theme and color-mode behavior. If the site supports light and dark modes, implement and test both using its existing toggle/provider and preserve its default, persisted, or system-selected mode. If the site supports only one mode, use that mode. Never force dark mode, add a dark root class or color-scheme override, default to a dark palette, hardcode black/near-black page surfaces, or replace the site's brand colors merely because the blog is editorial. Use only colors evidenced by existing tokens, components, logo, or repeated site styling. When no reliable theme evidence exists, keep the surrounding site shell unchanged and use a restrained neutral fallback with accessible contrast; do not assume dark. Use this layout direction for the blog index and category archives while adapting every visual token to the native theme: a generous full-width content canvas; a compact BLOG eyebrow; a strong "Latest articles" heading; an RSS link aligned opposite the heading only when RSS exists; one quiet divider; then a gapless editorial grid with three equal columns on wide screens. Cards must share single-pixel boundaries with no gutters, shadows, floating-card treatment, excessive rounding, or nested panels. Only the grid's outside corners may use the site's restrained radius. Each card is one full clickable region with a wide fixed-aspect-ratio hero image on top and an equal-height content panel below. Content uses a strong multi-line title, a muted two-to-three-line excerpt, generous breathing room, then a bottom-pinned metadata row separated by a subtle rule. That row contains a small clock icon plus reading time on the left and a compact diagonal directional arrow on the right. Repeated rows must form one continuous editorial wall rather than separate cards. At medium widths use two columns; at narrow widths use one column and preserve boundaries, readable type, and image aspect ratio. Let the site's typography, spacing scale, borders, radii, colors, and motion give this structure its identity; do not copy the reference's dark palette, purple illustration style, red accent, or fonts unless the customer site already uses them. Preserve any established category navigation without weakening this hierarchy. All public navigation, headings, states, links, accessible labels, and CTA copy must call the content "articles" or use the site's established "blog" label. Never call articles "field notes", "field note", or "journal". Card links must use "Read article" or an equivalent localized article label, not "Read field notes". Provide deliberate loading, empty, and failure states plus visible hover and keyboard-focus states. At narrow mobile widths, prevent horizontal overflow from cards, media, prose, controls, or code. When edge rendering is selected or already used, keep edge-rendered HTML synchronized with the visible blog content, crawlable links, metadata, and structured data so SEO does not drift after hydration. Preserve article.heroImageUrl and article.heroImageAlt from the publishing payload as first-class content fields. Every blog listing surface, including the main index, category archives, related-article lists, and reusable article cards, must visibly render each article's hero image when article.heroImageUrl is present. Every article page must visibly render the same hero image once in a prominent responsive position near the title and before the article body; do not rely on Open Graph metadata or an image embedded in Markdown as the visible hero. Use article.heroImageAlt for accessible alt text, preserve the image aspect ratio, prevent layout shift with dimensions or aspect-ratio styling, and use the framework's native optimized image component when it supports remote sources. Do not render a broken img element when no valid public hero URL exists; use the site's intentional image fallback only when its design system already defines one. Avoid duplicate heroes when article.content begins with the same image. Make every blog surface technically SEO-ready using all applicable, evidence-backed metadata: unique title and meta description, self-referencing canonical URL, robots directives, Open Graph article fields, Twitter/X card fields, absolute social image URLs with useful alt text, semantic heading hierarchy, crawlable internal links, sitemap and RSS entries, and hreflang plus localized canonicals when the site has localized routes. Use the same article.heroImageUrl for the visible hero, Open Graph/Twitter image, feed image when supported, and BlogPosting or Article image so visual and metadata surfaces cannot drift. Every selected discovery surface must read the same runtime article source so it updates without a rebuild. Inspect the existing sitemap implementation before editing. Extend it when present; never create a competing second sitemap. If no sitemap exists, add the framework-native sitemap and reference it from robots.txt. Include absolute canonical URLs for the blog index, indexable category archives, and every published article, with accurate lastmod values when available. Exclude drafts, previews, noindex pages, API routes, and per-article plain-text companions. Add valid JSON-LD without duplicate or conflicting entities: Organization and WebSite at site scope when verified identity/search data exists; CollectionPage and BreadcrumbList on blog indexes and category archives; BlogPosting or Article plus BreadcrumbList on article pages. Populate applicable article properties including headline, description, image, author, publisher, datePublished, dateModified, mainEntityOfPage, inLanguage, keywords, articleSection, and isPartOf. Reuse stable @id values so page, author, publisher, breadcrumb, and website entities connect into one graph. Never invent identity, logo, author, rating, review, FAQ, or search-action data merely to produce more schema. Validate generated JSON-LD, canonical/OG URLs, indexability, sitemap coverage, social metadata, visible listing hero images, visible article-page hero images, alt text, missing-image behavior, duplicate-image prevention, loading/empty/failure states, hover/focus behavior, gapless-grid structure, equal card heights, bottom-pinned metadata, responsive grid behavior, mobile overflow, both existing color modes when supported, native theme inheritance, accessible contrast, article-only terminology, and edge-rendered HTML parity in focused tests or existing SEO quality gates. On article cards and article pages, show the human-readable category label, published date, updated date when meaningfully different, author byline prefixed with the localized equivalent of "By", and reading time. Resolve the verified company display name from existing site identity or TrafficWins website context and use exactly "<Company name> Team" as the writer name everywhere, including visible bylines, author sections, feeds when supported, and article JSON-LD. Do not use a campaign name, category, domain, individual person, generic "Editorial Team", or TrafficWins as the customer blog author. If the company name cannot be verified, ask instead of inventing it. Prefer article.category for the stable slug, article.campaign.name for its display label, article.frontmatterDate or article.createdAt for publication date, article.updatedAt for modification date, and article.readingTimeMinutes or a 200-words-per-minute fallback. Render article.content as sanitized Markdown through the framework's native Markdown pipeline and styled article components. Never display Markdown as one raw text node, escaped text, a preformatted block, or unsanitized HTML. Give prose a readable measure and clear spacing for H2/H3 headings, short paragraphs, lists, tables, blockquotes, code, links, and responsive images. Treat TrafficWins as invisible infrastructure: never render or expose its name, trafficwins.com, logo, badges, links, attribution, or "Powered by TrafficWins" anywhere on the customer's public blog, article content, metadata, schema, feeds, or plain-text companions. Use only the customer's supplied brand identity. Do not replace a working blog or invent a second content system.
16. When selected, add one production publishing/editing webhook using the repository's native server route or function conventions. Implement an idempotent upsert keyed by TrafficWins article.id. Require Authorization: Bearer <token> with constant-time comparison where the runtime supports it; return 401 without revealing why the credential failed. Validate the expected TrafficWins organization and destination identifiers when configured. After authentication and before normalization, durably store the complete received TrafficWins JSON payload in the selected database JSON/JSONB field or R2/object-storage object. Preserve the entire envelope and every nested value sent by TrafficWins, including event, orgId, timestamp, article, campaign, contentPlan, content, files, images, metadata, and publication fields, plus unknown future fields; never whitelist, truncate, summarize, or silently discard fields. Store exact request bytes when the runtime exposes them, otherwise store a lossless parsed JSON document. Never persist Authorization headers, publishing tokens, cookies, or unrelated request headers. Keep normalized, indexed article columns alongside the raw payload or its durable object key for efficient rendering and queries. For R2/object storage, use deterministic tenant/article/delivery keys, private access, content type application/json, integrity hash, byte size, and a durable latest-payload pointer; do not expose raw payload objects publicly. For database storage, use a native JSON/JSONB/document type where available and do not stringify into a length-limited text column. Record an immutable accepted-delivery snapshot or content-addressed equivalent for each distinct create/update while making retries idempotent. Do not acknowledge success until both raw payload persistence and normalized article upsert succeed, using a transaction or recoverable two-phase/idempotent workflow so neither can silently diverge. Accept publication.action (create or update), publication.externalId, and publication.externalUrl. On create, upsert by article.id so retries cannot duplicate the post. On update, replace the same remote article using externalId first, then article.id, then externalUrl; preserve its stable remote ID and never create a duplicate. Every successful published create or update must return { externalId, externalUrl }, where externalUrl is the full absolute public HTTP(S) article URL. TrafficWins stores both values and sends them on future edits. Add focused auth, tenant/destination, invalid-payload, create-retry, update, duplicate-prevention, stable-URL, full-payload round-trip, unknown-field preservation, no-truncation, large-payload, raw/normalized consistency, storage-failure, and secret-exclusion tests. When selected, add an accessible article-footer block titled "Reading this as an AI?" with one "Article as plain text" link. That link must serve only the current article as clean machine-readable Markdown over text/plain; include title, description, canonical URL, author, category, published/modified dates, source facts/citations, and full article body. Prefer article.files.llmTxt.content when present, augmenting destination-owned canonical metadata at render time; otherwise generate it from stored Markdown. Use a stable per-article URL such as /blog/<slug>.txt and set Content-Type: text/plain; charset=utf-8. Do not add or require a full-site llms.txt or llms-full.txt unless selected in the form.
17. When TrafficWins destination setup is selected, generate the shared secret with an operating-system cryptographic random source, at least 32 random bytes encoded as base64url or hex. Never invent it as model text, hardcode it, commit it, print it, paste it into chat, or expose it in logs or the final report. Store it as TRAFFICWINS_PUBLISH_TOKEN in the site's local and deployed secret stores using the project's documented environment workflow. Keep only the transient value needed to send the same token once as credentials.securityToken to TrafficWins. If secure secret storage or deployment access is unavailable, stop this setup before destination creation and autoPublish, then report the exact missing access without revealing any secret.
18. Run the repository's focused tests, typecheck, lint, and production build in the order its instructions require. Do not run migrations or destructive cleanup commands. Fix task-caused failures; report pre-existing failures separately with the shortest decisive error. Deploy only when selected, using the repository's existing deployment workflow, then verify the public blog route, HTTPS webhook route, and referenced CSS/JavaScript assets are reachable. Never claim a local-only endpoint is publishing-ready.
19. When TrafficWins configuration is selected, configure it idempotently. Re-read state before every write. Select an organization only when exactly one valid choice exists or I named it; otherwise ask once. Inspect get_website, get_website_context, list_campaigns, and list_publishing_destinations before creating anything. Reuse matching resources. Set or correct siteUrl and blogUrl, then call build_website_context and poll its job to a terminal state. Use the codebase brief to supplement only missing context through save_website_context; never overwrite stronger researched context with guesses. For publishing, reuse a destination only when its provider and absolute endpointUrl match this blog. Otherwise call upsert_publishing_destination with the framework-appropriate custom provider (astro, next, or webhook), settings.endpointUrl set to the deployed HTTPS webhook, credentials.securityToken set to the generated token, enabled=true, an accurate name, and confirm=true. Make it default only when no other intended default exists. The approved form is explicit approval for only the selected sensitive destination upsert. Never echo the token in tool commentary or results.
20. When destination testing is selected, call test_publishing_destination for the saved destination and require a successful authenticated round trip. Re-read list_publishing_destinations and verify the destination is enabled, healthy, and visible on the TrafficWins Publishing page. Do not enable autoPublish on a failed, unreachable, local-only, or untested endpoint. TrafficWins auto-publishes to every active owned destination; if unrelated active owned destinations exist, ask which destinations should remain active before enabling autoPublish rather than silently publishing to all or disabling any.
21. When campaign and live verification are selected, research keyword suggestions for the verified website. Create or update one SEO campaign using codebase and website evidence: correct language, audience-aligned tone, seed keywords, useful article structure, autoPublish=true, and scheduleEnabled=false. The campaign name is also its public category name. Use only the concise human-readable category label, with no prefix or suffix such as SEO, campaign, blog, content, or the company name. Set autoPublish=true only after step 20 passes. Use a stable idempotencyKey when creating it. Start topic-cluster research with useWebsite=true and replacePlan=false, poll every returned job, then review the resulting plan for duplicates, off-topic pages, wrong language, and overlap with existing site routes. For a no-rebuild architecture, record the current deployment identifier after application deployment, then generate and publish the strongest non-duplicate article without running another build or deployment. Require successful live publication within the selected freshness bound. Verify the deployment identifier stayed unchanged; publication.externalUrl is the full live article URL; initial server HTML contains the article and metadata; blog index, category, selected sitemap/feed/AI surfaces include it; page assets load; and destination recorded the same stable article identity. Publish an approved edit through publication.action=update and verify externalId stays stable, the existing page changes, and no duplicate appears, again without a build or deployment. Do not fabricate a successful destination test, crawl, generation, cache refresh, or publication. Keep content-generation schedules disabled unless I separately request scheduling.

Finish with a compact report containing: detected client; MCP authentication and tool discovery; selected organization; codebase evidence scanned or explicit fallback; approved form decisions; full-payload storage location and verified round-trip result without payload contents; files changed; blog and webhook routes built; validation and deployment results; TrafficWins website/context/campaign/plan/article/destination IDs and terminal states; destination test result; autoPublish state; first publication URL and update identity; no-rebuild verification and unchanged deployment identifier when selected; exact remaining manual actions. State only that the token was generated and stored; never expose its value, fingerprints, prefixes, or suffixes. Never claim unverified readiness.

Featured article layout
- Before the listing header, render one featured article when a published article with a valid hero image exists.
- Select it deterministically: use an explicit featured flag or configured featured ID first; otherwise use the newest published article with a valid hero. Exclude that article from the following grid so it never appears twice.
- Make it one full-width clickable split story card, not a carousel, generic promo hero, or separate invented content block.
- On wide screens, give the hero image roughly three-fifths of the width and the story panel the remainder, with equal height, one outer border, restrained outer radius, and one clean internal seam.
- The story panel uses a compact uppercase "FEATURED ARTICLE" eyebrow, a large multi-line article title, a muted two-to-three-line excerpt, generous space, then a bottom divider and metadata row containing publication date plus reading time on the left and a diagonal arrow on the right.
- Use only actual article data. Never fabricate a label such as "Featured research" unless that is a real site taxonomy.
- At narrow widths stack the image above the story panel, preserve image aspect ratio and content order, and keep the whole card keyboard accessible.
- If no published article has a valid hero and the site has no intentional image fallback, omit the featured block cleanly.