Define it once. Ship every surface.
The developer-surface primitive of the estate: one API definition in — shared types, a typed client, a CLI binary, and an MCP server out, publishable to npm as a unit. Live on npm today, with every gate to the rest stated in the open.
An API that answers is not yet an API that gets called well. Its human callers in code want a typed client; its human callers in a terminal want a CLI; and its newest callers — agents — want an MCP server, or they cannot call it at all. The default stack assembles those separately: a codegen for the client, a CLI framework to hand-wire, an MCP SDK to integrate. Separate packages on separate release trains — that many places to drift from the API and from each other. In practice the drift resolves the cheap way: the client ships, the CLI is skipped, and the MCP server stays on the roadmap — so the service exists to fewer and fewer of its callers exactly as the caller population diversifies.
The philosophical stake is the estate's own: if the machine economy runs on services calling services, the handle is as load-bearing as the door. A service without generated surfaces has hand-kept ones or none — and in the agent era, "none" includes being invisible to every caller that speaks MCP.
The estate's machine door has two sides, and they file as two records in the same batch. apis.do is the gateway: the server side, where a service is exposed, named, and routed — it answers calls. sdk.do is the caller side: it manufactures the things callers hold — the typed client, the CLI, the MCP server. One seam, two primitives, distinct by rule: if the work is exposing or routing a service, it belongs to the gateway's record; if the work is generating or publishing a calling surface, it belongs here. Neither record claims the other's side.
In the estate's own registry the coordinate is exact: noun SDK, verb develop, category primitives, subcategory development, priority P1, tier free. Three things in this estate are the substrate itself — the studio, the platform, the runtime. This is deliberately not a fourth: it is a primitive with one job, wearing its own door because the owner of an API that already answers is a different ICP from the builder holding a function that needs to run.
// sdk.config.ts — the entire input
import { defineSDK } from '@dotdo/sdk'
export default defineSDK({
name: 'my-api',
baseUrl: 'https://api.example.com',
api: {
users: {
list: { input: { limit: 'number?' }, output: 'User[]' },
get: { input: { id: 'string' }, output: 'User' },
},
},
types: {
User: { id: 'string', name: 'string', email: 'string' },
},
})
npx sdk.do generate emits four packages from that file: types
(shared TypeScript definitions), client (a typed SDK —
client.users.list({ limit: 10 })), cli (a binary with subcommands —
my-api users list --limit 10), and mcp (a server exposing the same
API as tools — users_list, users_get). sdk.do build, version, and
publish take the set to npm as a unit. Auth is declared once — api-key,
bearer, or oauth2 — and every surface inherits it. The definition is the
artifact: the four surfaces can never drift from it or from each other,
so of the hand-assembled stack's many places to drift, one remains — the
definition, the one file to keep true to the running API.
This is the published loop, not a design sketch: @dotdo/sdk is live on
npm at 0.1.1 under the MIT license, bin sdk.do, and its posted
description is exactly this contract — "Define your API once, get a
typed client, CLI binary, and MCP server."
Concreteness over adjectives: each surface below was checked cold on 2026-07-31 and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts adoption, download volume, or external usage. Those publish behind their own gates.
The package serves. npm install @dotdo/sdk works today: the registry
lists @dotdo/sdk with dist-tag latest 0.1.1, MIT, bin sdk.do.
The repository is public and serves at github.com/dot-do/sdk — source,
tests, and the README documenting the define → generate → publish loop.
(The published package's repository field still points at a
dotdo-ai/sdk URL that does not resolve — a root-artifact fix queued for
the next publish; the URL in evidence here is the one that serves.)
A live worker answers at the apex: https://sdk.do/ returns HTTP 308,
and a machine caller asking for JSON receives a structured redirect
envelope. What it serves is a redirect — where it points is the first
amber below, stated there in full rather than rounded up here.
The gateway companion serves: GET https://apis.do, retrieved cold with
no authentication, returns the machine-readable gateway envelope naming
itself the managed API gateway for the .do ecosystem (the envelope posts
its own login and signup doors; none is required to read it). The server
side of the seam this primitive is the caller side of; its own record
files in the same batch.
Three product ambers, worn in the open — each the exact distance between what serves and what this door intends to be. (The figures gate on the economics slide is the estate's standing stack#1 §A5 disclosure rule, carried by every record in the portfolio — an estate gate, not a fourth product amber.)
The apex answers — with a redirect to itself. The 308's Location is
https://sdk.do/, and every https path redirects back to the same path:
a live worker with no destination configured. A developer who resolves
the name today finds a door that answers and points at its own address.
This claim flips when the apex serves the product surface — docs,
quickstart, and the machine-readable record of the primitive.
The unscoped npm name sdk.do is held by the estate's own legacy
package — an earlier Drivly-era artifact at 0.0.1 whose bin is sdk —
while the current library publishes scoped as @dotdo/sdk and names its
bin sdk.do. Both are the estate's; the name still needs one owner. The
record states the live geometry rather than pretending the unscoped name
already points here.
The estate's own registry files this coordinate at status planned, priority P1 — while the library already publishes on npm. The books lag the artifact, and the estate does not round up its own registry: the filing is declared here at its filed state, and this claim flips when the registry does.
Primary motion is B2D: the buyer is a developer who evaluates on npm and in the repo and converts at the first successful generate — no sales motion, no demo call, no procurement. Today the evaluation surface is the package page and the README, which is why the apex gate on the seams slide is the deck's most important amber: the front door should be where the README already is. Secondary is B2A, and here it is structural rather than aspirational in one precise sense: every API defined through this primitive ships an MCP server by default, so the primitive is the on-ramp by which the estate's — and its tenants' — services become agent-callable at all. Nothing about sdk.do's own machine surface is claimed in present tense while the apex serves a redirect to itself.
Distribution economics, not take-rate economics: the primitive is MIT and free by filing; margin lives on the metered doors the generated surfaces call. Every API defined here adds callers to the gateway and the runtimes at zero acquisition cost — the handle is given away so the doors get knocked on.
The registry files tier free, and the record matches it: MIT license, free install, no commercial term anywhere in this file. The primitive's economic job is upstream of revenue — every definition it processes emits surfaces whose calls terminate on the estate's metered doors, so the funnel compounds with each API defined. Any future commercial term for this name binds when it posts at a contract surface, not before, and never as prose in a deck.
Download counts, definition counts, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
the input is one TypeScript definition — sdk.config.ts, authored first-class in the language the codebase already speaks, not a parallel spec format — and types, client, CLI, and MCP server are all emitted from it: four surfaces on one release train that can never drift from the definition or from each other, so the hand-assembled stack’s many places to drift collapse to one — the definition, the one file to keep true to the running API
the output is publishable npm packages the builder owns — built, versioned, and published to npm as a set with one command each, nothing between the packages and the registry — and the MCP server is one of the four standard outputs of every generate, so an API defined here exists to agent callers the day it publishes, with no separate integration to schedule
the estate’s gateway routes services server-side while this primitive manufactures their handles caller-side — adopting both closes the loop from definition to discovery, and unbundling re-creates the wiring the builder came here to delete
the library’s declared peers are the estate’s own contracts — the rpc.do transport and the @dotdo/api and @dotdo/types packages — so the primitive deepens with the stack it ships handles for, rather than chasing an external spec
The claim ledger lives on the "What serves today" and seams slides — one posted chip per live surface, one amber per gate, each stated once. This slide is the evidence in kind: what a machine actually receives when it resolves this primitive, retrieved cold on 2026-07-31 with no login and no signup.
The apex, asked for JSON. GET https://sdk.do/ with
accept: application/json returns:
{ "redirect": "https://sdk.do/", "status": "308" }
A live worker, answering in a machine's language, redirecting the caller to the address it is already at — the deck's most important amber, shown here as bytes rather than restated as a chip. The gate on the seams slide flips when a product surface replaces the loop.
The registry, asked for the package. GET https://registry.npmjs.org/@dotdo/sdk returns (abridged):
{
"name": "@dotdo/sdk",
"dist-tags": { "latest": "0.1.1" },
"description": "Define your API once, get a typed client, CLI binary, and MCP server",
"bin": { "sdk.do": "dist/bin/sdk-do.js" },
"license": "MIT"
}
The artifact is ahead of the apex: the library a developer would install is live and posted, while the door a developer would resolve still points at itself. This record files both facts instead of averaging them.
The package is @dotdo/sdk — npm install @dotdo/sdk works today.
If this was forwarded to you: sdk.do is the developer-surface primitive of the startups.studio estate's infrastructure layer — the caller side of the machine door whose server side is the gateway at apis.do. One API definition in; shared types, a typed client, a CLI binary, and an MCP server out, publishable to npm as a unit. What is live is posted with a URL checked cold — the npm package, the public repo, the gateway — and what is not is pending with the gate that flips it, including the three ambers it wears openly: the apex that answers with a redirect to itself, the unscoped npm name still held by the estate's own legacy package, and the registry row that files the coordinate planned while the library ships. Judge it by what is posted, and by how plainly it labels what is not.