Machine-readable copies
The same specification as plain text, as JSON, and as a personalised markdown guide — so an agent does not have to crawl HTML for it.
Everything in this section exists in a form something other than a browser can read. All of it is generated from the packages that implement the engine, so a deployment's copies describe that deployment.
| URL | What it is | Key |
|---|---|---|
/llms.txt | An index: every documentation page with its description, and the endpoints below. | none |
/llms-full.txt | Every page above as one plain-text document, with each generated reference expanded inline. One request instead of a crawl. | none |
/api/vf/blocks | The Block vocabulary as JSON — every parameter as JSON Schema, plus the conventions no schema can carry. The same payload the vf_list_blocks tool returns, and the same one the editor's inspector renders its rows from. | none |
/api/agent-doc | The hosted MCP endpoint as one markdown guide, generated from the registry it serves. | optional |
/api/mcp | The endpoint itself: MCP over Streamable HTTP, stateless. | required |
Which one to read
Writing vf-HTML, or deciding whether to: /llms-full.txt. It is the whole
language in one pass, prose included.
Already holding a key and about to make a call: /api/agent-doc. It is the
only one of these that knows anything about you — send the key and it names
the Artifact that key reaches, its Channel, its frame ids and the owner's stated
intent, and it describes only the tools this deployment actually has wired up. A
wrong key gets the general copy rather than a 401: there is nothing behind it a
stranger could not read anyway.
Building tooling around the vocabulary: /api/vf/blocks. JSON Schema, in
input mode — which is to say, describing what you write (an HTML attribute,
always a string) rather than what the parser produces.
Why they cannot drift
A hand-written copy of a tool list is a copy, and a copy is how two surfaces
drift apart while both keep working. So none of these is written:
/api/vf/blocks and /api/agent-doc are rendered from the registries at
request time, and the reference sections on these pages — Blocks, commands,
tools, presets, Channel rules, rejection codes — are read from the same
packages as the page renders, in HTML and in plain text alike.
The prose around them is written by hand and could go stale. That half is held by a test rather than by care: it fails the build when a page names a Block, a command or a tool the engine does not have, and when a vf-HTML example on any page stops being a document the engine accepts.