Driving it from outside: API and MCP
One key
The “API keys” screen in your account settings issues a key. It starts with vx_ and is shown once only — all we keep is a hash of it, so there is no screen to go back to and read the key from.
The key travels in the x-api-key header and identifies you as the user. Every ownership check that exists in the interface still applies to it: a key is a way in, not a way around.
Revoking a key stops everything using it immediately. A revoked key and a key that never existed get exactly the same answer, so that neither teaches anybody anything.
The MCP server
The project ships an MCP server that lets an agent — Claude Code, Cursor, anything that speaks the protocol — drive the system. It is a thin client over the same API the browser works against, not a second route into the database: a second route is how two paths drift apart until one of them is missing a check the other has.
It speaks JSON‑RPC 2.0 over stdio, one message per line, and takes the address and the key from environment variables.
The tools
list_appsThe projects this key owns, with the live address and code of each.
create_appA new, empty project. The build itself comes afterwards.
build_appA build or a change, from a free-text description. It costs credits; a build that fails the check is not charged.
get_appEverything about one project: the files, the tables with their access rules, the versions and the build conversation.
read_recordsReading records stored in the project, as the owner. Newest first.
list_templatesBrowsing the template catalogue.
use_templateCopying a template into a new project. The code and the table definitions are copied; data is not.
search_skillsSearching the Israeli knowledge library, with the licence and source of every result.
What this is not
This is not a public interface to your site's data. Reading and writing records from the built site go through a separate door, where each table's permissions are enforced for every visitor. The key here is the owner's, not your users'.