Tissue now has an MCP server. Point Claude — or Cursor, Windsurf, or any Model Context Protocol client — at one URL and manage your whole account in plain language: deploy Cells, query c3, read and write g7 objects, schedule pulses, and handle secrets, without leaving the chat.

The endpoint is https://tissue.systems/mcp. Everything an agent can see and do is bounded by the token you give it — least privilege, by construction.

For Claude Code, that's the whole setup:

claude mcp add --transport http tissue https://tissue.systems/mcp

On first use it opens your browser, you sign in to Tissue once, and the tools light up — no token to copy, no config file to hand-edit. Under the hood it's a standard OAuth flow with automatic client registration; the same browser-login works in Claude Desktop, Claude.ai, and Cursor. For CI and headless agents, create a scoped tok_… token instead and pass it as a bearer header. Full setup for every client is in the docs.

The server exposes one tool per operation, named <area>_<verb>, and filters them by your token's scopes — a read-only token simply never sees the write or delete tools.

Once connected, ask in plain language:

Deploy a Cell called "hello" that returns "Hello, world!" for any request.

Create a c3 database "todos" with a tasks table (id, title, done, created_at),
then show me everything in it.

Show me the last 20 errors from my "payment-processor" Cell.

List my buckets and tell me the total size of the "uploads" bucket.

Claude calls the right tools, chains them, and reports back — deploying, querying, and inspecting as it goes.

Object bytes don't belong in a model's context. For anything beyond small text, the server mints a short-lived presigned URL and the bytes move out-of-band — straight to storage, never through Claude:

You: upload ./logo.png to my "assets" bucket.
Claude → g7_presign_upload → returns a one-time PUT URL
       → curl -T logo.png "<url>"   (bytes go directly to g7)

Small choices add up to a server that's safe and legible for an LLM to drive:

Add the server, sign in, and ask Claude to deploy something:

claude mcp add --transport http tissue https://tissue.systems/mcp

The full guide — browser login and token setup for Claude Code, Claude Desktop, Claude.ai, and Cursor, plus the complete tool and scope reference — lives at docs.tissue.systems/docs/mcp.

We're building tissue Sense — a way to point any sensor at Tissue and get a live dashboard, stored history, and a full alerting pipeline — routed and escalated to wherever it needs to go — without standing up a single server.

Tissue already gives you compute (Cells), SQL (c3), object storage (g7), and scheduling (pulse). The piece missing for the physical world was a front door for devices and a way to run close to them. That's what we're adding, and it's two new pieces with names that fit the rest of the platform: synapse and ganglion.

synapse is the ingest layer. It speaks the protocols real hardware already uses — MQTT, MQTT-over-WebSocket, CoAP over DTLS for battery devices, and plain HTTPS — and turns every reading into an event your Cell handles in a new sensor(event, env) handler, right alongside fetch and pulse. Each device gets its own credential and can only write its own stream. The connections live outside your Cell, so your code stays as simple as the rest of Tissue.

The practical upshot: a $5 microcontroller with a temperature sensor, a Tasmota plug you already own, or a battery LoRa node in a field can all report to the same place — and a browser can watch the numbers tick in real time.

ganglion is software you install on a Raspberry Pi (or any small Linux box) that runs the same Cell as the cloud — right there in your building. It bridges sensors that can't reach the internet on their own (LoRa, Zigbee, BLE, Modbus), and it keeps working when the internet doesn't: ingest, dashboard, and alerts all run on-site, and buffered readings sync up when the uplink returns.

A reading crossing a line is just the trigger. Because the alert logic is your Cell, what happens next is a pipeline you control: a rules engine watches for thresholds, sudden swings, and the case that matters most — a sensor that has gone silent — then routes the alert wherever it needs to go. Push it to a phone, text a teammate, email a list, fire a webhook into Slack or PagerDuty, or escalate up an on-call rotation until someone acknowledges. The notification on your phone is one delivery channel, not the whole system.

Most sensor platforms make you rent three black boxes — their ingest pipeline, their locked dashboard widgets, their rules UI — none of which you can move. On Tissue, the Cell that ingests the reading is the same Cell that renders the dashboard and runs the alert: one unit you own, that you can fork, and that runs in our cloud or on a Pi in your greenhouse. Dashboards are real web pages, so sharing and embedding them is native, not a paywalled tier.

synapse and ganglion are in active development. We're opening early access soon — if you want to be first to point a sensor at Tissue, sign up and keep an eye on this blog. We'll post again the day it's live.

We recently moved tissue.systems itself — the landing page, auth, dashboard, docs, and support — to run as Cells on Tissue. The platform now hosts its own front door.

This is the kind of milestone that either feels trivial ("of course it should run on itself") or reveals something important about where the platform actually is. For us it felt like the second one.

Each of these is deployed with a standard ribo deploy from a ribo.toml, the same as any user Cell. The custom domains point at the same routing layer as every other Cell, with TLS provisioned automatically.

The management API at api.tissue.systems is not a Cell. It is the process that deploys Cells — it cannot coherently run inside itself. It runs as a bare system process and is the only part of the platform that cannot eat its own cooking. Everything above that layer can.

Moving to this setup raised an immediate question: auth.tissue.systems issues the JWT tokens that ribo login stores locally. Those tokens are required to deploy Cells. So the auth Cell must be running before you can deploy anything — including the auth Cell itself.

In practice the sequence is: stand up the management API first (bare metal), deploy auth with a temporary credential, then use the issued token to deploy everything else. The substrate has to exist before the things that run on it. This is not a deep paradox — it is just the order of operations — but it clarifies what "the substrate" actually is. The management API is the bedrock. Everything else, including our own product's front door, is a Cell.

Running on your own platform is the most honest test of it. The things we noticed immediately: cold-start latency matters when it is your own login page. c3 SQLite needs to be reliable when it is storing your own user sessions. Custom domain TLS provisioning needs to be invisible when it is your own domain at stake.

None of those turned out to be problems. That is the point of writing this down.

If you want to deploy a function and get a live URL, with SQL and storage and scheduling included, on infrastructure you control — sign up and run ribo deploy.