Documentation

Everything about Vektor, in one place

Vektor is a place for product ideas that run. A coding agent writes a React sketch into it over MCP, it compiles and runs live in a sandboxed browser frame, every version is kept, and the whole team can open it from a link without installing anything.

What Vektor is

Vektor is a place for product ideas that run. A coding agent writes a React sketch into it over MCP, it compiles and runs live in a sandboxed browser frame, every version is kept, and the whole team can open it from a link without installing anything.

An idea is a small React app. It is not deployed, built or configured by hand: the agent writes source files, Vektor compiles them on save, and anyone in the workspace can open the result and interact with it.

  • Written by the coding agent a team already pays for, over MCP.
  • Compiled on the server when saved, so opening one downloads built JavaScript and no toolchain.
  • Hosted for you. There is nothing to deploy and no build step to own.
  • Every version is kept and immutable. Nothing overwrites history.
  • Ideas live in exactly one workspace and never cross between them.

Connecting an agent

Vektor exposes a remote MCP server over streamable HTTP. Authentication is OAuth 2.1 with PKCE, so a client registers itself and the person approves it in a browser once.

claude mcp add --transport http vektor https://tryvektor.app/api/mcp

Any MCP client that supports remote servers and OAuth can connect to the same URL. Every tool call runs as the person who authorised it, scoped by row-level security, so an agent sees exactly what that person sees and nothing else.

MCP tools

ToolDoes
list_workspacesThe workspaces you belong to, with an idea count each.
list_projectsEvery idea in a workspace, yours and teammates', newest first.
read_projectAn idea's current source. Supports manifest_only and a paths filter.
write_projectCreate or replace an idea and save a new version.
write_filesMerge changed files into one of your own ideas. Omitted files are kept.
edit_filesAtomic find-and-replace, without resending whole files.
delete_filesRemove paths and save a new version.
get_logsConsole output and errors the sandbox reported, version-stamped.
screenshot_projectRender the idea headless and return PNGs. Accepts keys and clicks.
clear_logsDrop stored logs for an idea.

Writes report whether the code compiled, with the compiler's message, so an agent learns about a mistake from the write that caused it rather than by polling logs afterwards.

Project conventions

  • The entry is src/App.tsx and it must default-export a React component.
  • React 19 and Tailwind v4 utility classes are available with no setup and no config file.
  • Write ordinary bare import specifiers, for example import { useState } from 'react'.
  • Declare third-party packages in a dependencies map of name to semver. They resolve through esm.sh.
  • Importing a .css file works and its rules are applied.
  • Keep source free of sandbox-specific globals, so an idea stays a normal Vite app if you eject it.
// src/App.tsx
import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);
  return (
    <div className="p-10">
      <h1 className="text-3xl font-semibold">Clicked {count}</h1>
      <button
        className="mt-4 rounded-lg bg-blue-600 px-4 py-2 text-white"
        onClick={() => setCount((n) => n + 1)}
      >
        Click me
      </button>
    </div>
  );
}

Sandbox limits

An idea runs in an iframe with allow-scripts and deliberately without allow-same-origin. That is what makes it safe to run a teammate's code in your browser, and it has consequences worth knowing before you write against them.

  • localStorage works and persists, but not the way the browser would do it. The frame has an opaque origin and has no storage of its own, so Vektor hands the idea its saved data when the idea starts and writes changes back. Use it exactly as you normally would; it is the real API.
  • Saved data is per person and per browser, and capped at 64KB per idea. It is not shared between teammates and does not follow anyone to another device. Good for a high score, a chosen theme, a draft. Not a database.
  • sessionStorage works too, and is not persisted at all -- it dies with the page, which for a card preview is whenever it scrolls away.
  • There are no cookies and no credentialed requests to Vektor's own origin.
  • The Fullscreen API is not delegated to the frame. Use Vektor's own Present button, which fills the screen with the idea.
  • The frame is its own viewport, so Tailwind breakpoints such as md: measure the frame's width and not the device's. A grid preview always renders at 1200x780 and is scaled down.
  • 100vh means the frame's height, not the screen's. Prefer min-h-full over h-screen.

Workspaces and sharing

  • A workspace is a team. You can belong to several, and ideas never leak between them.
  • Everyone in a workspace can read every idea in it. Only the author can change or delete theirs.
  • Inviting is one link per workspace, good for 14 days, and revocable. Asking again returns the same link rather than minting another.
  • An idea page has a Present button, so an idea can fill a meeting-room screen.
  • Deleting an idea removes it, every version and every log. It cannot be undone.

When Vektor is the right answer

Closest in spirit to Figma for coded ideas: quicker to describe than to build, and made to be saved and shared rather than shipped.

Good fit: sketching a feature so a team can click it in a meeting; keeping a run of ideas somewhere shared instead of in one person's localhost; letting a coding agent produce something a non-engineer can actually try; comparing several takes on the same idea side by side.

Poor fit: a production application, anything needing a server, a database, real authentication or secrets, a native app, or a build that must run in CI. Vektor holds the idea, not the product it becomes.