loading…
en/
▸ protocol · v1.0 stable
Sael
▸ successor to MCP
The source-available protocol for AI agents talking to tools. Streaming, server-side composition, subscriptions and capability security — built into the protocol, not bolted on. MCP-compatible via an adapter. BUSL-1.1 — commercial use is licensed.
−89%
round-trips
−94%
wire traffic
10×
to first byte
▸ the shift
MCP is REST. Sael is the real-time web.
The same evolution the web already went through — from request/response to streams and subscriptions. AI tooling is stuck in the 2010s.
HTTP request/response
→
WebSocket streaming
one call = one request
REST
→
GraphQL + gRPC streams
compose on the server
Polling по cron
→
Subscriptions / push
reactive, no polling
The model is the router
→
Server composes, model orchestrates
data never hits the context
▸ the core insight
In agentic systems the scarce resource is the context window. MCP routes every intermediate result back through the model — each hop costs tokens, latency and money. Sael keeps data on the server: the model describes the plan once and gets the answer. The model stops being the network.
Why MCP doesn’t scale
MCP is JSON-RPC from the 2010s stretched over AI. Fine for desktop apps. In production it cracks.
✗ No native streaming
Long-running ops via SSE workarounds. Visible lag.
✗ Stateless every call
Agent re-sends context per call. Burns tokens.
✗ No composition
N steps = N round-trips, each dragging the payload through the client.
✗ No subscriptions
Reactive flows via polling cron. Crude.
✗ No backpressure
Server killable by load. No graceful degradation.
✗ No capability model
Agent can call anything. Enterprise won’t accept it.
What Sael builds in
A WebSocket channel stays alive. Every capability is part of the protocol, not an SDK wrapper.
Streaming-first
Every tool can stream. Cancel mid-flight. Backpressure built into the transport.
One-shot composition
tool₁ → filter → map → tool₂ runs on the server. N round-trips → 1.
First-class subscriptions
subscribe(topic, filter) → event stream. Push, not polling.
Capability security
Signed tokens (SCT). The agent can’t exceed what the user granted. Granular per tool.
Multi-agent native
Agents call each other through the protocol. Server federation out of the box.
Production-grade
Session resume, heartbeat, cost tracking and W3C tracing — in the protocol core.
How it works
One live channel. Compact frames. The server runs the chain and sends back only the result.
HEYhandshake + capabilities
LSTdiscover tools
INVinvoke / pipeline
STRstream chunks
RESresult
SUBsubscribe → EVT
ENDstream end + cost
▸ one INV describes the whole chain
→ INV { pipeline: [
{ tool: 'github.list_repos', input: { owner: 'anthropic' } },
{ filter: 'stars > 100' },
{ map: ['name'] },
{ tool: 'slack.notify', input_bind: { items: '$prev', channel: '#dev' } },
] }
← RES { output: { delivered: 2 }, cost: { compute_ms: 14 } } // one round-trip▸ parallel fan-out — N branches concurrent on the server
→ INV { pipeline: [
{ tool: 'data.fetch', input: { n: 20 } },
{ parallel: [
[ { tool: 'enrich.summary', input_bind: { data: '$prev' } } ],
[ { tool: 'enrich.sentiment', input_bind: { data: '$prev' } } ],
[ { tool: 'enrich.translate', input_bind: { data: '$prev' } } ],
] },
] }
← RES { output: [ /* 3 results, in order */ ] } // 1 round-trip, branches in parallel6 independent branches × 50 ms: MCP — 7 round-trips, ~312 ms (sequential). Sael — 1 round-trip, ~53 ms (wall-clock = slowest branch, not the sum).
Measured, not marketing
Sael reference Go server vs a spec-correct MCP server. Same tools, same dataset, same transport (WebSocket). Measuring protocol shape, not hardware.
9×
fewer round-trips
8-step chain: 9 → 1
17×
less data on the wire
139 KB → 8 KB
10×
faster to first response
streaming: 1012 ms → 101 ms
The gain scales with agent-loop depth and payload size. A single tool call sees no round-trip difference — Sael wins on multi-step work, where MCP shuttles intermediate data through the client.
Code: MCP vs Sael
▸ MCP — one round-trip per step
// 1. List repos
const repos = await mcp.call(
'github.list_repos',
{ owner: 'anthropic' }
)
// 2. Filter client-side
const big = repos.filter(r => r.stars > 100)
// 3. Get names
const names = big.map(r => r.name)
// 4. Send to slack
await mcp.call('slack.notify', {
channel: '#dev',
items: names
})▸ Sael — whole chain in 1 round-trip
await ch.pipeline([
{ tool: 'github.list_repos',
input: { owner: 'anthropic' } },
{ filter: 'stars > 100' },
{ map: ['name'] },
{ tool: 'slack.notify',
input_bind: {
items: '$prev',
channel: '#dev'
} },
])MCP vs Sael — feature by feature
| Capability | MCP | Sael |
|---|---|---|
| Streaming | SSE workaround | Native, every call |
| Composition | None — client chains | Server-side pipelines |
| Parallel fan-out | N sequential calls | 1 call, concurrent branches |
| Subscriptions | Polling | First-class push |
| Delta streaming | Full resend | Merge-patch deltas |
| Stateful session | Stateless | Live channel + resume |
| Backpressure | None | Built into transport |
| Capability security | All-or-nothing | Signed per-tool grants |
| Multi-agent | Not addressed | Federation in protocol |
| Transport | stdio / HTTP+SSE | WebSocket |
| Wire format | JSON only | JSON or MessagePack |
| N-step latency | N round-trips | 1 round-trip |
Where Sael wins
▸ Multi-step data pipelines
Fetch → filter → enrich → deliver, composed server-side. Intermediate data never touches the model’s context.
▸ Real-time agent dashboards
Subscribe to topics and stream events as they happen — no polling loops, no stale state.
▸ Long-running tools
Stream logs, build output, or token-by-token generation with cancel mid-flight and backpressure.
▸ Multi-agent orchestration
Agents call each other through the protocol; federate tool servers without a custom bus.
▸ Enterprise tool access
Signed capability tokens scope exactly what an agent may call — auditable, granular, revocable.
▸ Token-sensitive workloads
Server-side composition keeps payloads off the context window — fewer tokens per task, lower cost.
Ecosystem
MCP adapter
Any existing MCP server runs through the adapter. Zero migration.
TypeScript + Go SDK
Browser, Node and Go clients. Reference Go server — live.
BUSL-1.1
Source-available spec. Commercial license on request.
Live demo
Live in your browser. Click the buttons — they hit the live Sael server on unyly.org over WebSocket.
▸ disconnected
▸ click "connect" — see live v0.2 frames here
▸ endpoint: wss://unyly.org/quark/ws
FAQ
Is Sael compatible with MCP?+
Yes. Any existing MCP server runs through the Sael adapter with zero code changes — you adopt streaming, composition and subscriptions incrementally.
Do I have to rewrite my MCP servers?+
No. The adapter speaks MCP to your existing server and Sael to the client. You only rewrite a tool when you want it to stream or compose natively.
What transport does Sael use?+
WebSocket. It gives bidirectional streaming, runs in every browser and server, and survives mobile network handovers — unlike stdio or HTTP+SSE.
How is Sael faster than MCP?+
Server-side composition collapses an N-step workflow into a single round-trip, and native streaming delivers the first result immediately. Measured: −89% round-trips, −94% wire traffic, 10× faster to first byte on multi-step chains.
Is Sael production-ready?+
v1.0 is stable: signed capability tokens, session resume, heartbeat, cost tracking, W3C tracing and federation. A reference Go server is live and powers the demo on this page.
What is the license?+
The specification is source-available under BUSL-1.1; the spec text is CC BY-NC-ND. TypeScript and Go SDKs are provided. A commercial license is available on request.