Deploying an MCP-I Server

Overview

Checkpoint provides two deployment models for MCP-I servers:

Both models register with Checkpoint for delegation verification, proof auditing, and dashboard monitoring.

Dashboard Deploy

The fastest path to a running MCP-I server. Checkpoint scaffolds a complete project, creates a GitHub repository, and configures deployment.

Prerequisites

• A Checkpoint account with a GitHub App connection
• A Cloudflare account (for Workers deployment)

Deployment Flow

1. Start Deployment

Navigate to your project in the dashboard and select Deploy MCP-I Server. Fill in:

2. Watch Deployment Progress

After submitting, Checkpoint executes a 9-step pipeline with real-time progress:

1. Verify GitHub — Confirms GitHub App installation and repo name availability
2. Create Project — Creates a Checkpoint project for monitoring
3. Generate API Key — Creates an encrypted API key for the worker
4. Register Identity — Registers the agent DID with Know That AI for reputation tracking
5. Scaffold Files — Generates the MCP-I server source code
6. Create Repository — Creates a private GitHub repository
7. Commit Files — Pushes the scaffolded code to the repository
8. Add Secrets — Configures GitHub Secrets for deployment
9. Configure Gateway — Sets up routing (if applicable)

3. Deploy to Cloudflare

After the pipeline completes, you'll see:

• GitHub Repository URL — Link to your new repo with the full MCP-I server source
• Agent DID — Your agent's decentralized identifier
• Deploy to Cloudflare button — One-click Cloudflare Workers deployment
• KTA Claim URL — Claim your agent's profile on Know That AI (if reputation was enabled)

Click Deploy to Cloudflare to deploy the worker, or push changes to the repo to trigger the auto-deploy GitHub Actions workflow.

What Gets Created

GitHub Repository:

my-mcp-server/
├── src/
│   └── index.ts          # MCP-I server entry point
├── wrangler.toml          # Cloudflare Workers configuration
├── package.json
├── tsconfig.json
└── .github/
    └── workflows/
        └── deploy.yml    # Auto-deploy on push to main

GitHub Secrets (encrypted):

Checkpoint Dashboard:

• A project entry for monitoring delegations, proofs, and sessions
• An API key linked to the project

Know That AI (optional):

• Agent DID registered for reputation tracking
• Public profile page at knowthat.ai/agents/{slug}

Auto-Deploy with GitHub Actions

The generated repository includes a GitHub Actions workflow that deploys to Cloudflare Workers on every push to main:

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm install
      - run: npx wrangler deploy
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

If you didn't provide Cloudflare credentials during setup, add CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID to your repository's Settings → Secrets and variables → Actions.

Self-Host (BYOK)

For full control over your MCP-I server infrastructure, use the MCP-I packages directly.

Option 1: Cloudflare Workers

npx @kya-os/create-mcpi-app my-server

This scaffolds a Cloudflare Workers project with MCP-I built in. Configure and deploy with wrangler:

import { MCPICloudflareServer } from '@kya-os/mcp-i-cloudflare';
import { defineConfig } from '@kya-os/mcp-i-cloudflare';

export function getRuntimeConfig(env: CloudflareEnv) {
  return defineConfig({
    vars: {
      ENVIRONMENT: env.ENVIRONMENT || 'production',
      AGENTSHIELD_API_KEY: env.AGENTSHIELD_API_KEY,
    },
    admin: {
      enabled: true,
      apiKey: env.ADMIN_API_KEY,
    },
  });
}

export default {
  async fetch(request: Request, env: CloudflareEnv, ctx: ExecutionContext) {
    const server = new MCPICloudflareServer({
      env,
      config: getRuntimeConfig(env),
    });
    return server.handleRequest(request, ctx);
  },
};

Required Environment Variables:

Required KV Namespaces (Cloudflare):

Option 2: Node.js / Express

Add MCP-I verification to any Node.js server using the middleware:

npm install @kya-os/bouncer-middleware

See Migrating MCP to MCP-I for the full Express integration guide.

Option 3: Node.js Runtime

For advanced use cases, use the core MCP-I runtime directly:

npm install @kya-os/mcp-i

import { createMCPIRuntime } from '@kya-os/mcp-i';

const runtime = await createMCPIRuntime({
  environment: 'production',
  identityPath: '.mcpi/identity.json',
  wellKnown: {
    environment: 'production',
    baseUrl: 'https://my-server.example.com',
  },
});

// Get agent identity
const identity = await runtime.getIdentity();
console.log(`Agent DID: ${identity.did}`);

// Create a proof for a tool response
const proof = await runtime.generateProof(toolResponse, sessionContext);

Package Hierarchy

@kya-os/contracts              → Shared types and schemas
    ↓
@kya-os/mcp-i-core             → Platform-agnostic runtime (providers)
    ↓
@kya-os/mcp-i                  → Node.js runtime
@kya-os/mcp-i-cloudflare       → Cloudflare Workers adapter
    ↓
@kya-os/bouncer-middleware      → Express middleware (verification only)

Identity Management

Every MCP-I server has an agent identity — an Ed25519 key pair that produces a DID.

DID Format

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

The DID is derived from the agent's public key and serves as its persistent identifier across sessions and services.

Identity Storage

• Dashboard Deploy: Identity is generated during deployment and stored as a GitHub Secret (MCP_IDENTITY_PRIVATE_KEY)
• Self-Host: Identity is stored locally in .mcpi/identity.json (add to .gitignore)

Well-Known Endpoints

MCP-I servers expose discovery endpoints:

Reputation (Know That AI)

Agents deployed via the dashboard can optionally register with Know That AI for reputation tracking. Reputation scores (0–100) reflect an agent's trustworthiness based on its history of verified interactions.

Servers can enforce minimum reputation thresholds:

createBouncerMiddleware({
  apiKey: process.env.CHECKPOINT_API_KEY!,
  projectId: process.env.CHECKPOINT_PROJECT_ID!,
  reputationThreshold: 60, // Reject agents below 60
});

Next Steps

• Migrating MCP to MCP-I — Add MCP-I to an existing server
• Authentication Methods — Choose how users authorize agents
• Tool Protection — Define per-tool scope requirements
• Consent Flows — Customize the consent experience