MCP

A slate can expose tools to clients that support the Model Context Protocol (MCP). A client discovers the tools, calls them with structured arguments, and receives their results through the slate’s hosted endpoint:

https://<name>.contextlayer.xyz/mcp

A tool can also provide a View: an interactive interface displayed inside an MCP Apps-compatible client. Tools perform the work; Views let people interact with that work inside the client.

MCP tools currently cannot use ContextLayer connections, databases, or secrets. Keep all three resource collections empty in an MCP declaration; declaring a resource fails the build. Apps and agents support these resources.

Tools

An MCP tool lives in mcp/<name>/index.ts, with its own declaration in mcp/<name>/slate.json. The module exports two things:

tool: the definition clients discover, including a name, description, Zod inputSchema, and optional Zod outputSchema.
handler: the function that receives validated arguments and returns an MCP tool result.

For example, this tool returns a supplied string as text. It does not need a View:

mcp/echo/index.ts

import { z } from "zod"

export const tool = {
  name: "echo",
  description: "Echo a value back.",
  inputSchema: z.object({ value: z.string() }),
}

export function handler(args: unknown) {
  const { value } = args as z.infer<typeof tool.inputSchema>
  return { content: [{ type: "text" as const, text: value }] }
}

mcp/echo/slate.json

{
  "connections": {},
  "databases": {},
  "secrets": {}
}

ContextLayer validates a call against inputSchema before invoking the handler. The type assertion in this example describes that already-validated value to TypeScript. MCP tools and app routes are separate entry points. Defining an app route does not create an MCP tool. Both can import shared modules from the slate when they need the same logic, but importing a module does not give an MCP tool access to the app’s resources.

Views

A View is an HTML page that a compatible MCP client renders for a tool using MCP Apps. Put its entry point at mcp-ui/<name>/index.html; a React entry uses the MCP Apps host bridge to communicate with the client. Once a View exists, associate it with a tool through the tool definition’s metadata:

_meta: { ui: { resourceUri: "ui://echo/index.html" } }

This URI identifies mcp-ui/echo/index.html. It is an MCP resource URI, not a browser URL. Several tools can reference the same View. The View receives tool inputs and results and requests further tool calls through the client’s bridge. It receives no ContextLayer credentials. Use that bridge for interaction rather than relying on access to the slate’s browser pages; the View is displayed in the MCP client, outside the app’s browser session.

Build and serving

When the slate is built, the SDK evaluates each tool definition, writes the tool list into the deployment, and compiles each View into one HTML file with its scripts and styles inlined. On the hosted slate, each tool call runs the tool’s handler in the slate’s Worker. The development server does not serve /mcp. Build and deploy the slate to use its MCP endpoint. Expose MCP tools walks through a tool, an optional View, and deployment.

Connect a client

Add the hosted /mcp URL to your MCP client’s server configuration. The client signs in with OAuth: a person approves access with their ContextLayer account, and the client receives a token scoped to that slate’s MCP endpoint. Every MCP request requires this token, including requests to public slates. The slate’s viewing rule also applies. For a private slate, the signed-in person must be allowed to view it; making a slate public does not remove MCP authentication. After authorization, the client can discover and call the slate’s tools. See Owners and viewers.

Getting started

Core concepts

How-to

Reference

Tools

Views

Build and serving

Connect a client

​Tools

​Views

​Build and serving

​Connect a client

Tools

Views

Build and serving

Connect a client