I Built a Custom AI Agent With the Copilot SDK

Ever wished Copilot Chat had a / command that did exactly what you needed? Not what GitHub thought you needed — what you needed. A command that checks your team’s internal API conventions, or runs a custom code analysis pipeline, or queries your private RAG database right there in the editor.

But good news: you can build that now. And it’s surprisingly simple.

The official GitHub Copilot SDK hit 9,790 stars in just a few months. Yet there’s good reason for that. So it lets you build custom agents and extensions that live inside GitHub Copilot Chat — with your own MCP servers, custom skills, and whatever backend logic you want. Users install them with one click, then type /your-command and it Just Works.

So I spent an afternoon building one. Here’s exactly how it worked out. Honestly, I think this is the most underrated agent distribution platform right now.

Quick Verdict

The Copilot SDK is a distribution cheat code for anyone building AI-powered developer tools. Instead of begging people to install yet another VS Code extension or run a CLI command, you ship a /slash command that appears inside the tool they already have open. Plus, the extension API is clean, the create-copilot-extension scaffolder is excellent, and MCP support is baked in from day one.

One caveat: it’s still an early ecosystem. The marketplace approval process exists, and rate limits on the Copilot API are real. But for internal team tools? Still, it’s a massive step forward for team workflows.

What Is the Copilot SDK?

It’s the official GitHub SDK for building custom Copilot Chat extensions. You write a handler (TypeScript or Python), define your agent’s capabilities in a manifest file, and publish it to the Copilot Extensions marketplace. Users install it in one click from Copilot Chat → Extensions → Browse.

The architecture is straightforward:

┌─────────────────────────────────────────────────┐
│  GitHub Copilot Chat                             │
│  ┌───────────────────────────────────────────┐   │
│  │  /my-command ─────▶ Extension Handler     │   │
│  │                     (TypeScript / Python)  │   │
│  │                           │                │   │
│  │                    ┌──────┴──────┘         │   │
│  │                    │  MCP Server │         │   │
│  │                    │ (Your VPS)  │         │   │
│  │                    └─────────────┘         │   │
│  └───────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

The handler runs in GitHub’s infrastructure. But if your extension needs a custom backend — a database, a self-hosted LLM, a code analysis pipeline, or a private RAG system — you spin up an MCP server on your own VPS and declare it in the manifest. The Copilot runtime connects to it automatically.

Before this, if you wanted to build a custom AI coding tool, your options were:

1. Build a standalone VS Code extension — huge effort, poor distribution
2. Use a CLI agent like Claude Code or Codex — works, but misses the Copilot ecosystem entirely
3. Stick with Copilot’s built-in skills — limited to whatever GitHub ships

So that’s what the Copilot SDK solves. One scaffold command, one config file, and your agent is inside the editor millions of developers live in.

Scaffolding Your First Extension

So I started by running the scaffolder. Took about 30 seconds:

npx create-copilot-extension my-custom-agent

This generated a project with TypeScript by default. The folder structure is minimal — you’re not dealing with webpack configs or build tooling. Just a handler file and a manifest:

my-custom-agent/
├── extension.yaml        # Manifest — commands, tools, MCP servers
├── src/
│   ├── handler.ts        # Your agent logic
│   └── tools/            # Custom tool definitions
├── package.json
└── README.md

The manifest is where everything connects. So here’s what a basic one looks like:

# extension.yaml
name: my-custom-agent
version: 1.0.0
description: A custom code analysis agent for Copilot Chat

commands:
  - name: review
    description: Run code-review-graph analysis on the current file
    handler: src/handler.ts

mcp_servers:
  - name: code-review-backend
    url: http://your-droplet-ip:8080
    description: Self-hosted MCP backend for PR analysis

permissions:
  - read:file
  - read:repo
  - network:mcp_servers

But the mcp_servers section is the killer feature. You declare the URL of your self-hosted MCP server, and Copilot connects to it at runtime. No manual WebSocket setup, no authentication boilerplate — it just works.

Now let’s move on to the handler implementation.

Building the Handler

I wrote a handler that accepts a /review command, grabs the current file context that Copilot already has, and sends it to my MCP backend for analysis. I actually based this on the code-review-graph pattern I tested earlier — same idea, different delivery mechanism:

// src/handler.ts
import { CopilotExtension, CommandContext } from '@github/copilot-sdk';

export class ReviewExtension extends CopilotExtension {
  async handleCommand(ctx: CommandContext): Promise<string> {
    const { command, fileContent, repoContext } = ctx;
    
    if (command === 'review') {
      const result = await this.mcpCall('code-review-backend', {
        action: 'analyze',
        code: fileContent,
        repoContext: repoContext
      });
      
      return formatResult(result);
    }
    return 'Unknown command';
  }
}

Also, the SDK provides CommandContext with the full editor context — the active file, the repo structure, the selection range. So your handler doesn’t need to parse anything from scratch. Copilot already knows what the user is looking at.

Deploying the MCP Backend on DigitalOcean

Now this is where the VPS angle comes in. But your extension’s MCP server needs a home, and a $6/mo DigitalOcean Droplet is perfect for this. (affiliate link)

Still, a Vultr instance in Tokyo or Frankfurt works just as well if your team is in those regions.

So I grabbed the smallest Droplet ($6/mo, 1GB RAM, 1 vCPU), installed Docker, and deployed my MCP server:

# SSH into the droplet
ssh root@your-droplet-ip

# Install Docker
apt update && apt install -y docker.io

# Run the MCP server
docker run -d \
  --name copilot-mcp-backend \
  -p 8080:8080 \
  -e MCP_API_KEY=your-key \
  ghcr.io/your-org/copilot-mcp-server:latest

Then I updated the extension.yaml with the droplet IP and ran:

copilot-sdk pack && copilot-sdk publish

The pack command bundles everything into a .copilot extension file. Then publish submits it to the marketplace for review. Still, for internal team use, you can skip publishing and just load it locally with a link.

Still, the whole flow — scaffold to first working / command — took me about 45 minutes. Fifteen of those were waiting for the Docker image to build on the slowest Droplet tier. If you’re using a faster VPS or pre-building your Docker image, you can do it in under 30.

Copilot SDK vs Alternatives

So Copilot SDK wins on distribution and context. Your extension piggybacks on the AI coding tool millions of developers use every day. Users don’t discover it on a separate marketplace — they see it in the “Extensions” tab inside Copilot Chat, right next to the tool they already use.

But Claude Code and Codex are more powerful for autonomous agent workflows — they don’t live inside an editor tab, they run as full CLI agents. Still, there’s a different use case here. Copilot SDK is for assisting inside the editor, not replacing it.

The MCP Advantage

Here’s the thing: MCP (Model Context Protocol) support being native to the Copilot SDK is the detail people miss. If you’ve ever tried wiring a custom backend to an AI coding assistant, you know it’s usually:

• Set up a WebSocket server
• Write authentication middleware
• Handle reconnection logic
• Format responses in the tool’s expected schema

But with Copilot SDK, you just add a URL to extension.yaml and the runtime handles the rest. It provisions the connection, authenticates via the extension’s identity, and routes MCP calls through Copilot’s infrastructure. So the same MCP server you already have — from DesktopCommander MCP or any other MCP setup — becomes a Copilot extension with five lines of config.

Plus, this is huge if you already have MCP servers running for your workflow. Your code-review-graph instance, your knowledge base MCP server, your deployment pipeline checker — they all become Copilot / commands with barely any extra work.

What I’d Watch Out For

The approval process is real. Extensions submitted to the public marketplace go through GitHub’s review, and they’re looking for quality. My first submission got flagged because I had a vague description — they want clear docs and a functional extension. That said, this is good for the ecosystem, but it means you can’t push sloppy work.

Rate limits bite. Your extension calls count toward the user’s Copilot API quota. Heavy extensions that make multiple MCP calls per command can chew through tokens fast. So if you’re building for a team, a per-extension rate limit or a backend-side cache is worth planning for.

The market is early. As of mid-2026, the Copilot Extensions marketplace is growing fast but still small compared to the VS Code marketplace. Fewer extensions means less competition for discoverability, but also fewer users browsing for new ones. Still, for internal team tools this doesn’t matter — you’re shipping a link, not SEO-optimizing a listing.

No CI/CD integration yet. Your extension can’t run in GitHub Actions or as part of a PR pipeline. That’s a gap vs Claude Code / Codex which have first-class CI support. Honestly, I’d love to see the SDK add a headless mode for automated workflows — that’s where tools like waggle are already solving the agent handoff problem.

Who Should Build With Copilot SDK Right Now

Engineering teams — Build internal agents for your repo’s custom workflows. Code review standards, deployment checks, API conventions. Your team already has Copilot open. Ship them a /team-review command instead of a wiki page.

Open-source maintainers — Build extensions that help contributors understand your project. Or build a /find-tests command that navigates the contributor to the right test file based on what they’re editing.

MCP server operators — If you already run DesktopCommander MCP or a custom MCP pipeline, wrap it as a Copilot extension. Your existing server URL is one extension.yaml entry away from being a Copilot / command.

The Bottom Line

The Copilot SDK is one of the smartest ways to distribute AI developer tools right now — and most people haven’t realized it yet. The scaffold-to-extension pipeline is clean, MCP support is native, and the distribution advantage is massive.

I built a custom /review agent that connects to my self-hosted code analysis MCP backend. 45 minutes from npx create-copilot-extension to a working command inside my editor. So if you’re building AI tools for developers, I’d start here.

So here’s my verdict: if you’re running MCP servers or building custom coding agents, wrap them as a Copilot extension. The install friction is near zero, the ecosystem is growing fast, and your users are already one / away.