One row of SQL is the whole contract for a capability, and the 892nd took 3.1 seconds

Evidence status

Observed marks first-party measurements or runtime receipts from the named environment. Derived marks arithmetic calculated from cited inputs. Specified marks vendor or standards documentation. Implemented and deployed name code and live-state evidence, respectively. Reproduced means the stated procedure was rerun. Externally attested marks operator reports; those reports show that an experience occurred, not that it is universal.

Eighteen columns, of which six existed on the first day

The table as it stands in production. Read it back yourself:

cd /Users/cyrusmassoumi/miscsubjects-pages
npx wrangler d1 execute loop-content-spine --remote \
  --command "SELECT sql FROM sqlite_master WHERE name='directory';"

CREATE TABLE directory (
  key        TEXT PRIMARY KEY,
  type       TEXT NOT NULL CHECK (type IN ('fn','http','agent','flow')),
  target     TEXT,
  auth       TEXT,
  content    TEXT,
  updated_at TEXT NOT NULL
, category TEXT, allowed_categories TEXT, seq INTEGER, enabled INTEGER DEFAULT 1,
  planner_visible INTEGER DEFAULT 1, planner_rank INTEGER DEFAULT 100,
  input_schema TEXT, examples TEXT, sensitive INTEGER DEFAULT 0, runner TEXT,
  includes TEXT, created_at TEXT)

The first six columns came from migrations/0007_directory.sql:1-8. Everything after the closing parenthesis of the original statement is an ALTER TABLE bolted on later, which is why the SQL reads the way it does.

Column provenance, by migration: 0012_directory_category.sql:7-9 added category, allowed_categories, seq. 0018_planner_columns.sql:5-9 added the five planning and schema columns. 0064_substrate.sql:5 added runner. 0118_add_directory_sensitive.sql:2 added sensitive. 0183_prompt_blocks.sql:2 added includes. created_at has no such line — grep -rn "ALTER TABLE directory" --include="*.sql" . returns fourteen matches and none of them mention it, so that column entered the production table out of band. A rebuild should add it in a migration.

Two columns exist in the table but cannot be written through the REST surface. The PATCH handler's field allow-list at functions/api/directory/[key].js:223 contains thirteen names, and neither sensitive nor runner is one of them:

curl -sS -X PATCH "https://miscsubjects.com/api/directory/ZZ_TEST_TEMPERATURE" \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' \
  -d '{"runner":"edge"}'
# {"error":"no recognized fields"}   HTTP 400

The type column decides everything else, and it has exactly four legal values

fn runs a function inside the build's own Worker. http calls somebody else's API. agent sends content to a model as a system prompt. flow chains other rows. The dispatcher branches on the column at functions/api/dispatch.js:1145-1156; a fifth value is rejected by the CHECK constraint before that branch is reached.

Counted live:

npx wrangler d1 execute loop-content-spine --remote \
  --command "SELECT type, COUNT(*) AS n FROM directory GROUP BY type ORDER BY n DESC;"
# fn 480 | http 303 | agent 57 | flow 51   → 891

One real row of each type, exactly as stored.

fn — NOW

key  NOW | type fn | target now | auth (null) | category time
content   # Return the current time from the build clock in Pacific time (America/Los_Angeles).
          # WHEN_TO_USE: any object or model that needs the current date or time.
          # ARGS: none
          # EX: [NOW][/NOW]
          # OUTPUT: { now, today, time, zone, iso } — Pacific-offset ISO; today is the Pacific calendar date.

Every line of content beginning with # is stripped before execution by stripDocs at dispatch.js:440-452. What is left is the executable payload. NOW has no payload line, so runFn falls back to the default template ["$1"] at dispatch.js:1170.

http — GROK_MODELS

key  GROK_MODELS | type http | category grok | auth bearer:GROK_API_KEY
target    GET https://api.x.ai/v1/models
content   # WHAT: List every model on the xAI API. No args
          # WHEN_TO_USE: you need to grok models
          # ARGS: see content
          # EX: [GROK_MODELS][/GROK_MODELS]
          # List every model on the xAI API. No args.

agent — PROMPT_LAB_AGENT

key  PROMPT_LAB_AGENT | type agent | target grok-4.3 | auth bearer:GROK_API_KEY
content   You are a friendly peptide concierge (LAB TEST v1). One warm sentence,
          then end with [REPLY]your text[/REPLY].

An agent row with includes composes shared prompt blocks in front of content at runtime: ROUTER carries BLOCK_VOICE,BLOCK_IMESSAGE,BLOCK_EMOJI,BLOCK_ROUTING,BLOCK_ARA, so the voice rules are written once and referenced by six rows.

flow — BLOOIO_FINISH

key  BLOOIO_FINISH | type flow | target (empty)
content   # Phase C of the inbound turn: given the full agent output text in $1, extract the
          #   LAST [REPLY], send via blooio to $2, return the send result.
          # $1=agent output text. $2=recipient phone.
          LAST_REPLY_OF: $1
          > SEND_BY_CHANNEL: blooio|$2|$PREV

The flow reader splits on a top-level > and runs each step against the previous step's output, bound to $PREV (dispatch.js:1686-1731). A step is KEY: body. Appending => NAME binds that step's output to $NAME for later steps. A { A: x | B: y } block fans out concurrently. A step whose output starts with ERR: stops the flow.

Arguments are one string, split on the pipe character, and that is a deliberate trade

The invocation body is a single string. The dispatcher splits it on | and hands the pieces to the runner as args:

const args = String(body == null ? '' : body).split('|');

That is dispatch.js:1144. In a template, $1 is the first piece, $2 the second. Two arguments:

curl -sS -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' \
  -d '{"key":"ZZ_TEST_TEMPERATURE","body":"37.77|-122.42"}'

$1 becomes 37.77, $2 becomes -122.42, and the target GET https://api.open-meteo.com/v1/forecast?latitude=$1&longitude=$2&current=temperature_2m resolves to a real URL.

The obvious break: a pipe inside an argument. A JSON body, a prompt, a shell command, a sentence with a pipe in it — the naive split shreds all of them. The handled form is $N+, which rejoins arguments N through the end with the pipe put back:

if (/^\d+\+$/.test(key)) {
  const v = args.slice(+key.slice(0, -1) - 1).join('|');
  return raw ? v : escFor(mode, v);
}

dispatch.js:171-175. So a row that takes a JSON blob as its last argument uses $2+, not $2. DIR_PATCH is the live example — it edits another row, so its second argument is arbitrary JSON:

key      DIR_PATCH
type     http
target   PATCH https://miscsubjects.com/api/directory/$1
content  # ARGS: key | json_body
         # EX: [DIR_PATCH]ROUTER|{"content":"new prompt text"}[/DIR_PATCH]
         $2+

Called as body: 'ROUTER|{"content":"a|b"}', the key is ROUTER and the body template $2+ receives {"content":"a|b"} intact. The rule that follows: only the last argument of a row may contain a pipe, and only if the template uses $N+. A row with two free-text arguments in the middle of its signature is unrepresentable, and that is the real cost of the format.

Substitution is escape-aware. subVars at dispatch.js:156-201 takes a mode — url, json-string or raw — and escapes each value for the position it lands in, so a quote inside an argument cannot break out of a JSON body template. $$KEY skips the escaping. $PREV is the previous flow step's output. An unresolved $NAME is left in place as literal text rather than becoming an empty string.

Why one flat string and not a JSON object per capability: a caller that has read one contract can call any of the 891 without learning a new argument shape, and a router can forward a user's sentence through unchanged. The price is no types at the door. That is the trade one commenter refuses — menix, arguing schemas let a code-writing agent plan one precise program instead of a print-and-inspect loop. Both positions describe real failure modes; the comparison table below lands the verdict.

The row names the environment variable; the value never enters the table

The auth column is a prefix and an environment-variable name. applyAuth at dispatch.js:203-234 reads it at call time:

npx wrangler d1 execute loop-content-spine --remote --command \
"SELECT CASE WHEN auth IS NULL OR TRIM(auth)='' THEN '(none)'
        ELSE substr(auth,1,instr(auth,':')) END AS form, COUNT(*) AS n
 FROM directory GROUP BY form ORDER BY n DESC;"

115 rows name a credential through bearer:, basic: or query:, and between them they reference 12 distinct auth specifications. bearer:GROK_API_KEY alone appears on 35 rows. One rotation in the platform secret store changes the credential for all 35; no row is touched, no migration runs, no deploy happens.

An attacker who exfiltrates the whole table learns every capability that exists, every upstream URL, every argument shape, which capabilities are credentialed, and the names of the twelve secrets. That is a real map, worth defending. What they do not get is one credential value, because no column ever holds one. The failure mode of a leaked registry that stores values is total; here it is reconnaissance.

The row's claims about permission are advisory. Enforcement is server-side and independent of the row. When an invocation arrives with a scoped capability token, capGateCheck at dispatch.js:2121-2149 evaluates revocation, audience binding, owner gate, contract hash, risk ceiling, fixed body and payload ceiling before any runner is reached. A row marked sensitive = 1 is denied to any token whose risk_ceiling is not high, with the literal reason risk_ceiling:low<row:high. Editing the row cannot widen a token; editing a token cannot reach a row outside its scope. That is the pattern jensbontinck described from production — the credential sits at the enforcement point, not with the caller.

Shape mode proves the boundary without firing anything: {"key":"…","body":"…","shape":true} returns the fully constructed outbound request with credential material stripped by redactDeep (dispatch.js:1338-1356), which removes authorization, x-api-key, cookie and any *_API_KEY-shaped string. Against a row whose auth named a variable absent from the environment, the preview came back "headers":{} — no credential, no header, and the upstream 401 is the first signal.

Reading one row returns a document that assumes the reader knows nothing

curl -s "https://miscsubjects.com/api/dispatch?key=GROK_MODELS&format=markdown"

4,413 bytes. The blocks it contains, and why each is there:

The contract is close to constant in size regardless of the row. Measured across four rows of four different types: NOW 4,423 bytes, GROK_MODELS 4,413, ROUTER 4,442, CONTENT_SEARCH 4,507. The per-row variance is under 100 bytes because the scaffolding dominates and the row-specific part is small — that is the shape of a contract that is fetched one at a time rather than held in context. Fetching all of them at once is the opposite bargain: curl -s "https://miscsubjects.com/api/dispatch?registry=1" | wc -c returns 1,608,554 bytes for 877 objects.

People running large tool surfaces keep measuring the same thing independently: a maintainer auditing his own agent found 47 tool schemas costing 13,341 tokens on every request before the user's message; a vendor engineer building an MCP server for a large unified API hit 50,000 tokens of definitions before the agent touched a single user message; a tiktoken run against one server's full tool list produced 741 tools and roughly 488,013 tokens, larger than the context window it was meant to fit.

Adding the 892nd capability: one POST, then a receipt proving it ran

Everything below was executed against production on 2026-07-26 using an obviously-named throwaway row, ZZ_TEST_TEMPERATURE, which was deleted at the end. The outputs are copied verbatim.

Step 1 — the credential. TERMINAL_KEY is the owner key checked by isBuildAuthed. Every mutating call carries it as x-terminal-key.

export TERMINAL_KEY="$(grep '^TERMINAL_KEY=' ~/.config/grok-bridge.env | cut -d= -f2 | tr -d '"')"

Step 2 — the POST. key and type are the only required fields (functions/api/directory/index.js:51).

curl -sS -X POST https://miscsubjects.com/api/directory \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' -d '{
    "key": "ZZ_TEST_TEMPERATURE",
    "type": "http",
    "target": "GET https://api.open-meteo.com/v1/forecast?latitude=$1&longitude=$2&current=temperature_2m",
    "auth": "",
    "content": "# WHAT: Current temperature in Celsius for one latitude and longitude, from the Open-Meteo public API.\n# WHEN_TO_USE: a capability needs the live temperature at a coordinate.\n# ARGS: $1=latitude | $2=longitude\n# EX: [ZZ_TEST_TEMPERATURE]37.77|-122.42[/ZZ_TEST_TEMPERATURE]\n# OUTPUT: JSON with current.temperature_2m",
    "category": "tools",
    "enabled": 1,
    "planner_visible": 1,
    "examples": "[\"37.77|-122.42\"]"
  }'

{"ok":true,"key":"ZZ_TEST_TEMPERATURE","updated_at":"2026-07-26T04:36:19.832Z"}

HTTP 201. Without the header the same call returns {"error":"unauthorized"} and HTTP 401.

Step 3 — invoke it. No deploy, no restart, no cache warm-up in between.

curl -sS -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' \
  -d '{"key":"ZZ_TEST_TEMPERATURE","body":"37.77|-122.42"}' \
  -w "\nhttp=%{http_code} total=%{time_total}s\n"

{"ok": true, "ran": true, "trace": "t_jweoafmw",
 "result": "HTTP 200:{\"latitude\":37.763283,\"longitude\":-122.41286,...,\"current\":{\"time\":\"2026-07-26T04:30\",\"interval\":900,\"temperature_2m\":15.7}}",
 "proof": {"ok": true, "invocation_id": "inv_c23irnzhx1",
           "public_receipt": "https://miscsubjects.com/receipt/inv_c23irnzhx1"}}

http=200 total=3.126264s — 3.13 seconds wall clock from a laptop in California, including the Open-Meteo round trip. Three consecutive invocations of a pure fn row with no upstream call, timed the same way, took 3.40 s, 1.07 s and 1.59 s; the first carries TLS and connection setup.

Step 4 — the receipt. inv_c23irnzhx1 records actor owner:terminal-key, runner http, trace t_jweoafmw, material: true, cost_usd: 0, and three SHA-256 fingerprints: input, output, and the object contract. It is public and keyless:

curl -s "https://miscsubjects.com/api/dispatch?confirm=inv_c23irnzhx1"
# "confirmed": true, "status": "PROVEN_MATERIAL_RESULT"

Step 5 — remove it.

curl -sS -X DELETE "https://miscsubjects.com/api/directory/ZZ_TEST_TEMPERATURE" \
  -H "x-terminal-key: $TERMINAL_KEY"
# {"ok":true,"key":"ZZ_TEST_TEMPERATURE","deleted":1}

A subsequent GET /api/directory/ZZ_TEST_TEMPERATURE returns 404. The receipt still resolves and still reports confirmed: true — deleting the definition does not delete the history of what it did.

The no-restart property depends on something outside the row

Nothing here caches a tool list on the caller's side, so a new row is live on the next read. That is not a general property of tool registries, and the people who run them keep filing the same bug.

A registry gateway maintainer describes the failure exactly: upstream tool lists cached at registration time, stale until a manual re-registration or a full restart, with removed tools leaving dangling references inside tool groups. The Model Context Protocol has a message for this — a server that declared the listChanged capability SHOULD send notifications/tools/list_changed when its tool list changes. Two independent reports say clients ignore it. One user reproduced a dynamic-registration server against an IDE that never re-queries tools/list, while the same server worked in two other clients. A Microsoft engineer filed identical behaviour against a CLI client, with a repro video, noting the same product's editor extension updates immediately.

"Add a capability without a restart" is therefore a claim about the whole path, not about the registry. This path has no client-side cache to invalidate because the caller fetches one contract at a time. A registry that pushes definitions into a client's context inherits that client's refresh behaviour, and the behaviour is not uniform.

Every failure names itself, and the names are in the code

The hygiene gate is asymmetric on purpose. PUT refuses any non-compliant write. PATCH compares the violation before and after the merge and refuses only a patch that makes a compliant row non-compliant, so the rows that predate the rule stay editable for unrelated maintenance ([key].js:206-219). Of 891 rows, 256 carry an input_schema and 63 carry examples.

Where the row loses to a schema, and where a schema loses to the row

The verdict. Use a schema when a wrong call is expensive and must be stopped before it executes — money movement, destructive writes, anything where "the upstream returned 400" is already too late — or when strangers will write clients against it. Typing is not decoration there; it is the only place a bad argument is caught for free. Use a row when the surface is large, the caller is a model, the operations are mostly read-and-report, and the dominant cost is context rather than correctness.

The two are not exclusive. input_schema is on the row for this reason: 256 rows carry one, and those are the rows that get typed when the table is projected as an MCP tool list. The row is the storage format; the schema is one projection of it.

A row has no version number, and the receipt is where change is detectable

updated_at is overwritten on every write. There is no version column, no history table, and no diff. What exists instead is a fingerprint computed at invocation time. objectContractFingerprint (functions/_lib/object_contract.js:17-25) hashes the fields that define the call — id, object type, runner, directory type, category, target, description, input_schema, auth, risk, approval requirement, status, operation semantics — and the resulting SHA-256 is stored on every receipt as fingerprints.contract.

Which fields count was measured directly, by invoking the same row three times with an edit in between:

Changing examples left the fingerprint byte-identical. Changing target changed it. So the hash tracks the callable contract and ignores documentation-only edits — which is the behaviour you want, and it is worth knowing rather than assuming.

Two guarantees follow, and one gap. A capability token may be minted pinned to a contract hash; any invocation after the row changes is refused with contract_changed:<pinned>!=<current> and HTTP 409 (dispatch.js:2128-2132), so the caller is stopped rather than silently redirected. And every mutation is written to the append-only event log as a DIRECTORY_MUTATE record carrying the action, the key and the row ([key].js:29-45) — the change history exists even though the row does not keep it.

The gap: an unpinned caller invoking a changed row gets the new behaviour with no warning and learns of it from the receipt afterwards. That is the limitation, and the reason pinning exists. It is the same distinction aderix drew about version-controlling capabilities in general — approval around the definition does not help mid-flight, because the dangerous moment is the invocation, not the edit.

Receipts are engine-authored, never agent-authored, and that is not stylistic. A controlled two-condition experiment found an agent inventing a governance event that never happened and presenting it as compliance evidence when nothing else wrote the record. Here the dispatcher writes it, in the same code path that runs the call, with hashes of the actual input and output bytes.