> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scomp.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> A minimal protocol for projecting an LLM agent into a sandboxed, stateful, programmable environment.

Scomp is a protocol — plus a reference SDK and runtime — for connecting an LLM agent to a sandboxed execution environment it can drive with code.

The agent connects to a **scomp port**, which exposes a **runtime** that holds persistent state. The agent submits code; the runtime evaluates it against a set of **bindings** — application-defined capabilities — and returns the result. Bindings can flow in both directions: the runtime can call the agent's host, and the host can call the runtime.

That's the entire model. Everything else — agent loops, prompt construction, multi-agent orchestration — lives above the protocol.

## What scomp does

<CardGroup cols={2}>
  <Card title="Negotiates sessions" icon="handshake">
    A client (the agent's harness) and a server (the runtime host) exchange protocol version, capabilities, and a session id. Sessions outlive connections.
  </Card>

  <Card title="Carries eval and invoke" icon="arrow-left-right">
    The client sends code to evaluate. Either peer can invoke the other's bindings or function references, at any time, bidirectionally.
  </Card>
</CardGroup>

## Scomp vs MCP

The two protocols solve adjacent problems. They compose; they don't compete.

<CardGroup cols={2}>
  <Card title="MCP" icon="wrench">
    Exposes **individually-callable tools** to a *stateless* agent loop. Each tool call is an isolated round-trip; the agent reasons about which tool to call next from the outside.
  </Card>

  <Card title="Scomp" icon="terminal">
    Projects an agent into a **stateful, programmable** environment where tool calls compose. The agent writes code that calls bindings, captures results, branches, retries — all inside a single eval.
  </Card>
</CardGroup>

Both are useful. You can wrap MCP tools as scomp bindings (and vice versa). Picking one over the other is about whether the agent is best served by *picking the next tool* or by *writing a small program*.

## What ships today

<CardGroup cols={3}>
  <Card title="Protocol spec" icon="file-text" href="https://github.com/scomp-protocol/scomp/blob/master/PROTOCOL.md">
    `PROTOCOL.md` — JSON-RPC 2.0 over any bidirectional transport. Open spec, implementable in any language.
  </Card>

  <Card title="Rust SDK" icon="package" href="https://github.com/scomp-protocol/scomp#rust-sdk">
    Client + server, ergonomic macros (`#[binding]`), QuickJS reference runtime, WebSocket transport. All optional via feature flags.
  </Card>

  <Card title="TypeScript SDK" icon="hourglass">
    Planned. Same protocol; the spec is intentionally language-neutral.
  </Card>
</CardGroup>

## Where to next

<CardGroup cols={2}>
  <Card title="Build something" icon="rocket" href="https://github.com/scomp-protocol/scomp#quickstart">
    Quickstart: a server + client in \~5 minutes using the Rust SDK.
  </Card>

  <Card title="Read the model" icon="map" href="/concepts">
    Concepts: the mental model — peers, bindings, sessions — without any code.
  </Card>

  <Card title="Implement scomp" icon="cog" href="/protocol/overview">
    Protocol overview: what the wire looks like and how to write a conformant implementation.
  </Card>

  <Card title="See examples" icon="boxes" href="https://github.com/scomp-protocol/scomp/tree/master/demos">
    Demos: working examples in the repo that show common patterns end-to-end.
  </Card>
</CardGroup>

<Note>
  Scomp is pre-1.0 and the protocol is at version **0.1**. Breaking changes may land at minor-version boundaries until 1.0.
</Note>