1. What Eternity is

Eternity is an open protocol for human-AI collaboration. It defines a single artifact — the .ety intent file — that captures what a piece of software should do, including its boundaries, invariants, and verification rules, in a language a human and a model can both read.

The protocol is intentionally narrow. It is not a framework, a runtime, or a vendor lock-in. The grammar, the .ety syntax, the verifier blueprint, the MCP tool contract, and the Eternity reference are open and free to copy, fork, and train on. The hosted MCP gateway is the only paid surface — it runs the inference for you. Everything else, including the full pipeline, is free to self-host.

2. Why it exists

Today, "vibe coding" with LLMs produces apps that look right but quietly violate the rules the user actually cared about. There is no shared artifact between the human's intent and the model's output that you can review, sign, or re-verify.

Eternity fixes that by making the intent itself the source of truth. The model writes code against the .ety, and a separate verifier derives runtime predicates from the same .ety. If the code drifts from the intent, the verifier flags it. The .ety file is the contract.

3. The pipeline

Every Eternity build follows the same five stages. Each stage is a pure function: same input → same output, no hidden state.

Intent  →  Verify  →  Plan  →  Code  →  Live preview
prose     .ety       per-project    impl   React + TS
              ↑           ↑            ↑       ↑
       1 credit    1 credit     1 credit   5 credits
                 (hosted Builder · sign-in required)

On our hosted Builder every stage costs credits (a full build = 8 credits, ≈ 3 builds on the free tier of 30 credits / month). If you'd rather not pay or sign in, the entire pipeline is yours to self-host — see the self-host guide.

4. Writing .ety

A .ety file declares an intent — a named unit of work — with a purpose, the invariants it must respect, and the boundaries it is allowed to cross. Anything not declared is implicitly forbidden.

01intent habit_tracker
02  purpose: 'log daily habits and warn before breaking a streak'
03 
04  requires:
05    storage
06    time
07 
08  boundary:
09    cannot access network
10    can write files
11 
12  must always:
13    show current streak length
14    persist habits locally
15  must never:
16    sync to a server
17    reset a streak without confirmation
18 
19  verify:
20    streak is at least 0
21    habits is not empty after first add
22  on failure:
23    say 'state corrupted — restoring from last snapshot'
24end

Use plain phrases, not symbols. must always, must never, on failure, and purpose are the only phrases you really need. The full template lives on the Self-host page.

5. Dynamic verification

Verification is per-project, not a fixed checklist. The verifier reads your .ety and emits runtime predicates with severity levels: blocking, warning, info. The same tool is available over MCP as verify_intent.

Each predicate is phrased so it can be checked by inspection or by a test. The verifier output is JSON, not prose, so an agent can consume it directly.

6. Connecting via MCP

Eternity exposes the protocol as an MCP (Model Context Protocol) endpoint. Any MCP-aware client — Claude Desktop, Cursor, custom agents, vibe-coding hosts — can discover and call the four tools (compile_intent, verify_intent, generate_plan, generate_project) over JSON-RPC.

Endpoint: /api/mcp
Transport: Streamable HTTP, JSON-RPC 2.0. POST only.
Auth: Authorization: Bearer <your-token> — see /mcp for access.

# tools/call -> compile_intent
curl -X POST https://your-host/api/mcp \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{
    "jsonrpc":"2.0","id":2,
    "method":"tools/call",
    "params":{
      "name":"compile_intent",
      "arguments":{"description":"A Pomodoro timer with a streak counter."}
    }
  }'

Configure it in a Claude Desktop / Cursor config:

{
  "mcpServers": {
    "eternity": {
      "transport": "http",
      "url": "https://your-host/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

Prefer no hosted dependency at all? Stand up your own MCP server using the open tool contract — see the self-host guide.

7. Remixing intents

Any published project at /p/<slug> shows the live preview and the original .ety and plan. Fork it, edit the intent, re-verify, and generate a fresh implementation.

This is what "open protocol" actually means: every artifact is portable, readable, and forkable.

8. FAQ