Skip to content
ChuskyModel Context Protocol

Connect Chusky
to the agents you use.

Connect an MCP host that supports remote Streamable HTTP to Chusky’s project-scoped tools. Caller identity and server-side policy scope the work; background continuation depends on production persistence and scheduling configuration.

From setup to first run

A clean path from key to capability.

MCP is the connection layer. Your project key defines what the host may do, and the end-user identity defines whose work it can see.

01

Create a project key

In the Chusky app, open Developer API or your organization project and create a project-scoped key with only the permissions your host needs.

02

Connect your MCP host

Add the Chusky endpoint to Claude, Cursor, an IDE agent, or your own server. Store the key in that host’s secret manager, never in browser code.

03

Run with control

Give each caller a stable application identity. Chusky keeps runs, tools, files, approvals, and durable work scoped to that identity.

01 · Connect a host

Use the endpoint wherever your agent works.

For custom backends and hosts that support headers, use the configuration below. The environment variables are placeholders: keep their real values in the host’s server-side secret store.

Create an API key in Chusky
mcp.json
server-side config
{
  "mcpServers": {
    "chusky": {
      "url": "https://chusky-mcp.adesrnd.workers.dev/mcp",
      "headers": {
        "Authorization": "Bearer ${CHUSKY_API_KEY}",
        "X-Chusky-User-Id": "${CHUSKY_END_USER_ID}"
      }
    }
  }
}

Scoped by design

Project keys carry explicit scopes. Start read-only, then add run or management access only when the workflow requires it.

Human approval stays human

MCP hosts can inspect approval status, but they cannot approve their own external actions.

Built for durable work

A dropped connection does not erase a run. Reconnect with the returned thread and run IDs to inspect progress or continue safely.

What the server exposes

MCP is a doorway into the Chusky runtime, not a second workflow engine.

The adapter is stateless. Chusky remains responsible for identity, policy, budgets, idempotency, durable runs, missions, connected-app authentication, approvals, and provider evidence. Keep the returned identifiers so a host can inspect or resume the same work after a disconnected conversation.

Discover live tools

Use MCP discovery and Chusky’s live tool schemas as the source of truth. Tool names and inputs can evolve; clients should not rely on a copied static catalogue.

Run bounded work

A bounded run can research, call connected apps, create an artifact, request approval, or pause for a missing dependency. Missions are for longer work with checkpoints.

Verify the outcome

A successful response is not automatically proof of an email, CRM update, or publication. Inspect receipts and read the provider state again when the result matters.

02 · Identity and safety

The key opens the project. Identity scopes the work.

Send a stable, non-PII application identity in X-Chusky-User-Id. Chusky uses it to keep conversations, files, connected accounts, approvals, and usage separated between callers.

Never put a chsk_ key in browser code or a prompt.
Do not use an email address or display name as the stable identity.
Start with a read-only test before enabling external actions.

Ready when your host is

Give your agents a way to get real work done.

Create a scoped key, connect the endpoint, and let Chusky handle the governed execution behind the scenes.