main to build and deploy a revision of the slate.
What a slate contains
The repository can contain three ways to interact with the slate:- App: a React Router app that people open in a browser.
- Agents: named sets of standing instructions that run as jobs, on demand or on a schedule.
- MCP tools and Views: tools and interfaces that clients supporting the Model Context Protocol (MCP) discover and use through the slate’s
/mcpendpoint.
slate.json file. A declaration says what code needs; it does not contain credentials or database contents.
Declarations share one namespace per resource kind within the slate. If the app and an agent both declare notes, those declarations refer to the same logical database and must agree on its mode. The mode selects its Owner: two consumers using the same slug and Owner reach the same stored data, while different viewers’ viewer-mode databases remain separate.
MCP tools have their own
slate.json files, but connections, databases, and secrets are currently supported for apps and agents only. An MCP tool’s resource declarations must be empty.Find your way around the repository
The starter contains the app and one database,
notes. Add directories for the agents, MCP tools, and Views you want to build.
For example, a checkout with an added digest agent and echo MCP tool has this structure. Configuration and dependency files are omitted here so you can see where the authored behavior lives:
public/slate.json declares an owner-mode notes database:
public/slate.json
notes is the database slug used in code and in databases/notes/. In the hosted slate, "mode": "owner" selects a database belonging to the slate’s Owner. See Databases for migrations, queries, and the distinction between local and hosted data.
Create a slate
The CLI’sinit command creates a slate in ContextLayer and writes a checkout from the starter bundled with the CLI. It sets the Git remote and commits the starter on main. Sign in with login before creating a slate; the Quickstart walks through the sequence. Run npx @usecontextlayer/cli init --help for creation options.
A slate belongs to one Owner: you, or an organization you belong to. Its name is its hostname label, generated at creation from an adjective, a color and an animal.
Deploy with a Git push
Pushingmain to the slate’s ContextLayer remote starts its deployment lifecycle:
- Build the pushed commit.
- Apply that commit’s database migrations.
- Deploy the built app and MCP tools.
- Install the agent schedules from that commit.
The hosted URL and the dashboard
init prints two links:
- The hosted URL,
https://<name>.contextlayer.xyz/, where people open the slate. It works once the first deployment succeeds. - The slate’s page in the dashboard at
platform.usecontextlayer.com. The dashboard lists the slates you can manage, under Personal and under each of your organizations, with each slate’s latest commit.
Private by default
A new slate is private. A private slate with a personal Owner opens only for that user; a private organization slate opens only for members of that organization. A public slate opens for anybody. Visibility governs viewing only: Git access and management stay with the owning user or the members of the owning organization either way. Visibility is changed through the API: Update who can view a slate. Owners and viewers covers who can see and do what.The chrome
The chrome is ContextLayer’s header and configuration tray around a hosted app. It shows who you are signed in as and whether the slate’s setup is complete. The tray lists declared connections and viewer-mode secrets, so you can connect an account, assign it to a connection, and supply required secret values. These changes configure the hosted slate; see Connections and assignments. The chrome is served from a ContextLayer origin in an iframe, separate from your app. The app cannot read it, and the chrome passes no credentials or profile data to the app. The starter’sapp/root.tsx mounts it through the SDK’s Layout. Local development does not show the chrome.