Every backend, MCP enabled.
The protocol door of the estate: search, fetch, and do — the Model Context Protocol operated as a managed serving surface. The production door answers the handshake cold today, and every gate to the rest is stated in the open.
A working backend now has a caller population it was never built for: agents. They arrive speaking the Model Context Protocol — through Claude and its clients, agent frameworks, IDEs — and a backend without an MCP surface simply does not exist to them. The teams that do meet them meet them the expensive way: hand-built plumbing (a transport, auth discovery documents, a schema per capability) wrapped around the N-tool pattern — one tool per capability, one full inference round-trip per step, every workflow narrated call by call through the model's context window. And the hardest question is answered worst of all: when the model needs to execute something, most teams either refuse (and the agent stays a reader) or hand over a credential and a policy document (and hope).
The insight this door is built on: models are better programmers than they are tool-callers. Structured tool-call syntax is artificial; code is what they were trained on. Give the model one tool that accepts typed code against explicitly granted bindings, and a whole workflow becomes one execution instead of a chain of narrated round-trips.
The estate's machine door has more than one wire, and the records file
the boundaries by rule. apis.do is the HTTP side: services exposed,
named, and routed for programs. This door is the model side: the same
estate reached over the protocol agents speak. sdk.do manufactures an
MCP server as one of four npm artifacts from an API definition — if the
work is generating a package, it files there; if the work is serving the
protocol, it files here. And the two primitives whose names this door's
tool grammar echoes keep their own ground: searches.do owns keeping a
corpus that answers; actions.do owns the effect boundary of typed,
permissioned verbs. This door's search and do are the protocol
grammar a model sees — tool names in front of whatever scope is bound
behind them, which can be exactly those siblings.
In the estate's own registry the coordinate is exact: noun MCP, verb connect, category ai, subcategory protocols, 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 the door where the runtime's thesis touches the wire.
Every agent capability reduces to three operations, and the door serves exactly three tools:
search — find information: query whatever corpus is bound.fetch — retrieve a resource by identifier.do — execute typed code in a sandbox with zero ambient
capabilities: no filesystem, no network, no environment variables.
The only reachable world is the bindings explicitly granted — so the
model composes search, fetch, and your domain verbs in one execution,
and auditing what an agent can do reduces to auditing a bindings
object.// The server core — @dotdo/mcp (MIT, on npm today)
import { createMCPServer, createScope } from '@dotdo/mcp'
import type { SearchFunction, FetchFunction } from '@dotdo/mcp'
// createScope(bindings, types?) — sandbox .d.ts auto-generated from bindings
const scope = {
...createScope({
db: { query: async (sql: string) => [] }, // your backend
api: { get: async (url: string) => ({}) }, // your backend
}),
timeout: 5000, // DoScope.timeout (ms)
permissions: { allowNetwork: false }, // DoPermissions — raw fetch stays off
}
const search: SearchFunction = async (query) => [] // wire to your corpus
const fetchResource: FetchFunction = async (id) => null // wire to your resources
const server = createMCPServer({ search, fetch: fetchResource, do: scope })
export default { fetch: server.getHttpHandler() }
The wire answers cold. POST https://mcp.do/mcp completes the MCP
initialize handshake (our probe negotiated protocolVersion 2025-06-18)
and tools/list returns exactly three tools — search, fetch, do —
each with a full JSON Schema and protocol annotations
(readOnlyHint: true on the read tools), with no login and no key.
Checked 2026-07-31.
Auth discovery is posted per the protocol spec: the protected-resource
metadata names https://mcp.do/mcp as the resource and delegates to
https://id.org.ai as its authorization server — the estate's identity
rail — with the full authorization-server metadata served alongside at
its own well-known path. Anonymous read access and spec-compliant auth
discovery are both live facts, not a roadmap.
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, connection counts, or external usage. Those publish behind their own gates.
The apex serves machine-readable JSON: a server descriptor naming the
door ("MCP Server", mode production, issuer https://mcp.do), its
endpoint map — the OAuth suite, /mcp, /health — and its three tools:
search, fetch, do. No login, no signup.
The health probe answers: {"status":"ok","mode":"production"} with the
issuer and a live timestamp.
The server core is published: @dotdo/mcp is live on npm at 0.1.5 under
the MIT license — posted description, quoted: "MCP Server library with
search, fetch, and do primitives - the core package for building MCP
servers."
The repository is public and serves at github.com/dot-do/mcp — the
managed service, the core library, the worker entry, and templates
scoping the three primitives to web, database, filesystem, git, and
memory backends. (The published package's repository field still points
at a drivly/mcp URL that does not resolve — a root-artifact fix queued
for the next publish; the URL in evidence here is the one that serves.)
The environment ladder is real: test.mcp.do serves today.
dev.mcp.do serves today — test, dev, and production are separate
workers on separate hostnames in the door's own deploy config, not a
diagram.
Four 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 fifth product amber.)
The door answers as its backend. The initialize response's
serverInfo.name is collections.do — the collections backend
production binds over a Workers service — while the apex descriptor
names the door "MCP Server" with issuer https://mcp.do. A caller that
completes the handshake today is told, truthfully, that it reached the
backend this door fronts. This claim flips when the served identity is
the door's own — or when the fronting posture is ratified and posted as
the design.
The unscoped npm name mcp.do is held by the estate's own legacy
package — a Drivly-era artifact (latest 0.0.1, dist-tag next 0.1.0)
whose repository is the old monorepo — while the managed service's own
package.json names itself mcp.do at 0.1.1, unpublished under that
name, and the core publishes scoped as @dotdo/mcp. Both are the
estate's; the name still needs one owner. Same class as the sdk.do
npm-name seam, filed the same way.
The estate's own registry files this coordinate at status planned, priority P1 — while the production door answers the protocol handshake cold. The books lag the door, 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.
The offer is a door where a backend becomes callable — and today the
production door fronts exactly one backend: the estate's own
collections service, bound over a Workers service binding. There is no
onboarding surface where a customer binds theirs. What serves a
stranger today is the self-host path: adopt the published MIT core
@dotdo/mcp and the repo's templates, and scope the three primitives
to a backend they operate themselves. The managed "bind yours" path is
the product this record intends, and it is filed as a gate, not a
fact.
Primary motion is B2D: the buyer is a developer who evaluates in the
repo and at the wire, and the first touch is a curl — the door's own
endpoint answers an anonymous tools/list today, so evaluation costs
one command and no signup. Secondary is B2A, and here it is
structural rather than aspirational in one precise sense: the served
surface is machine-facing by construction — an MCP client is an agent's
instrument, and the auth discovery documents an autonomous caller needs
are posted per the protocol spec. Nothing about connection counts or
external usage is claimed in present tense; every such figure gates on
stack#1 §A5.
Distribution economics, not take-rate economics: the protocol door is free by filing; margin lives on the metered doors it makes model-callable. Every backend served here adds agent callers to the estate's metered surfaces at zero acquisition cost — the wire is given away so the doors get knocked on.
The registry files tier free, and the record matches it: the core is MIT, the door's read surface answers anonymously, and no commercial term appears anywhere in this file. The door's economic job is upstream of revenue — every backend it serves becomes reachable by the agent caller population arriving over MCP, and those calls terminate on the estate's metered doors. How fast that population grows is a figure like any other: it publishes behind the gate below or not at all. Any future commercial term for this name binds when it posts at a contract surface, not before, and never as prose in a deck.
Connection counts, bound-backend counts, token-efficiency measurements, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish — including the composition-versus-tool-chain efficiency claim, which posts as a measured comparison or not at all.
an agent that knows search/fetch/do can work any backend this door serves — swap the scope, keep the agent; the incumbent pattern rebuilds N tools per backend and retrains the caller each time
the do sandbox has zero ambient capabilities — the reachable world is the granted bindings object, credentials never enter, and the audit surface is a code review of one object rather than a policy binder
built on the official MCP SDK with spec-compliant auth discovery already posted — the door conforms to the protocol the agent era is standardizing on, rather than inventing a proprietary wire
auth delegates to the estate’s identity rail, backends arrive over service bindings, and the runtime’s agents are the native caller population — a competitor must replicate the composed estate, not a protocol adapter
The claim ledger lives on the contract, "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 at this door, retrieved cold on 2026-07-31 with no login and no key.
The apex. GET https://mcp.do/ returns (abridged):
{
"name": "MCP Server",
"mode": "production",
"issuer": "https://mcp.do",
"endpoints": {
"oauth": { "metadata": "/.well-known/oauth-authorization-server" },
"mcp": "/mcp",
"health": "/health"
},
"tools": ["search", "fetch", "do"]
}
The handshake. POST https://mcp.do/mcp with an initialize
request returns:
{
"result": {
"protocolVersion": "2025-06-18",
"capabilities": { "tools": { "listChanged": true } },
"serverInfo": { "name": "collections.do", "version": "0.1.0" }
},
"jsonrpc": "2.0",
"id": 1
}
A live protocol door, answering in the protocol's own grammar — and
identifying, today, as the backend it fronts. The first amber on the
seams slide is that serverInfo line, shown here as bytes rather than
restated as a chip. This record files both facts instead of averaging
them.
The door is https://mcp.do/mcp — an MCP client can connect today,
no key required.
If this was forwarded to you: mcp.do is the protocol door of the startups.studio estate's infrastructure layer — the Model Context Protocol operated as a managed serving surface, where a backend becomes callable by agents through three primitives: search, fetch, do. It is the bridge between the estate's runtime thesis (the customer is a machine by default) and the wire that customer actually speaks. What is live is posted with a URL checked cold — the apex descriptor, the handshake, the auth discovery, the published core, the public repo — and what is not is pending with the gate that flips it, including the four ambers it wears openly: the endpoint that identifies as the backend it fronts, the unscoped npm name still held by the estate's own legacy package, the registry row that files the coordinate planned while the door serves, and the managed path for binding your own backend, which has not yet shipped. Judge it by what is posted, and by how plainly it labels what is not.