Building a 100-Tool Azure DevOps MCP Server: One Session on the Couch, One While I Slept

Watching Dune 2 and shipping production code aren't mutually exclusive anymore.

When I set out to build an MCP server for Azure DevOps, I wanted to test a hypothesis: could Claude Code handle a substantial project from specification to production-ready code, complete with comprehensive tests, without constant hand-holding?

Featured Book

Loading Book...

Loading description...

Get the Kindle Edition

The answer: yes. In about 6 hours of active work spread across two sessions, I ended up with 100+ tools covering the entire Azure DevOps API surface and 258 passing tests.

Here's what that process looked like—and what it means for how we build developer tools.

Start with the Spec, Not the Code

Before Claude Code wrote a single line of implementation, I had it generate a complete specification. I gave it:

• Microsoft's Azure DevOps REST API documentation
• Requirements for PAT authentication
• A target of 80%+ test coverage
• The goal to support all major Azure DevOps features

The resulting spec outlined 100 tools organized into logical categories—work items, git operations, pull requests, pipelines, builds, releases, boards, wikis, test plans, artifacts, and more.

This specification-first approach meant Claude understood the full scope before implementation. No architectural pivots mid-project. No "oh, we need to refactor this because we didn't think about X" moments.

The lesson: AI-assisted development benefits from upfront design just like any other engineering project. Maybe more so.

Session One: Friday Night on the Couch

I started the first session on a Friday evening while watching Dune. Claude Code doesn't require constant attention—I could review and approve changes between scenes.

The architecture emerged clean and logical:

src/
├── index.ts              # MCP server entry point
├── ado-client.ts         # Azure DevOps API wrapper
├── types.ts              # Shared TypeScript types
└── tools/
    ├── work-items/       # Work item operations
    ├── git/              # Repository operations
    ├── pull-requests/    # PR management
    ├── pipelines/        # Pipeline operations
    └── ...               # 15+ more categories

The ado-client.ts wrapper handles authentication and provides typed access to all Azure DevOps APIs:

export class AdoClient {
  private connection: WebApi;
  private defaultProject?: string;

  constructor(orgUrl: string, pat: string, defaultProject?: string) {
    const authHandler = getPersonalAccessTokenHandler(pat);
    this.connection = new WebApi(orgUrl, authHandler);
    this.defaultProject = defaultProject;
  }

  async getWorkItemTrackingApi() {
    return this.connection.getWorkItemTrackingApi();
  }

  // ... additional API getters
}

By the time Paul Atreides was riding his first sandworm, I had 20 critical tools implemented and manually tested against my own Azure DevOps organization:

• Creating and querying work items
• Listing repositories and branches
• Creating pull requests
• Triggering pipeline runs

They worked. Real API calls. Real authentication. Real data flowing.

Session Two: The Overnight Build

It was late. Only 20% of the tools were complete. I switched to my phone, connected to Claude Code's cloud session, and gave straightforward instructions:

"Implement the remaining tools from the spec. Then write comprehensive unit tests. Target 80% coverage."

Then I went to sleep.

What I Woke Up To

• ✅ 258 tests passing
• ✅ 77.5% statement coverage
• ✅ 86% function coverage
• ✅ All 100+ tools implemented

Claude had created a comprehensive mock infrastructure for testing:

// tests/mocks/api-fixtures.ts
export function createMockGitApi() {
  return {
    getRepositories: jest.fn(),
    getPullRequests: jest.fn(),
    createPullRequest: jest.fn(),
    // ... 20+ mocked methods
  };
}

The tests covered happy paths, validation errors, and API failure scenarios:

describe("createWorkItem", () => {
  it("should create a work item with required fields", async () => {
    mockWitApi.createWorkItem.mockResolvedValue(mockWorkItem);

    const result = await createWorkItem(mockClient, {
      type: "Task",
      title: "Test Task",
    });

    expect(result.id).toBeDefined();
    expect(mockWitApi.createWorkItem).toHaveBeenCalled();
  });

  it("should throw error when title is missing", async () => {
    await expect(
      createWorkItem(mockClient, { type: "Task" } as any)
    ).rejects.toThrow();
  });
});

Using the Server

Configuration is simple. Add this to your MCP client configuration:

{
  "mcpServers": {
    "azure-devops": {
      "command": "node",
      "args": ["/path/to/ado-mcp/dist/index.js"],
      "env": {
        "ADO_PAT": "your-personal-access-token",
        "ADO_ORG_URL": "https://dev.azure.com/yourorg",
        "ADO_PROJECT": "DefaultProject"
      }
    }
  }
}

Then interact naturally with your Azure DevOps environment:

• "Show me all active bugs assigned to me"
• "Create a work item for the login page redesign and link it to epic 1234"
• "What's the status of the main pipeline?"

What This Means for Developer Tooling

1. Specifications still matter. Having Claude write a detailed spec first resulted in consistent architecture across 100+ tools. AI doesn't eliminate design—it amplifies the value of good design.

2. Test the critical path early. Manually verifying the first 20 tools gave me confidence in the API integration before scaling up. Trust, but verify.

3. Autonomous sessions work—with constraints. Clear scope (implement what's in the spec) and established patterns made the overnight session successful. The key word is "established patterns." Claude wasn't inventing new paradigms at 3 AM—it was following the blueprint from session one.

4. MCP enables powerful integrations. With this server, any MCP-compatible AI assistant can now interact with Azure DevOps programmatically. That's a force multiplier for developer productivity.

The Reality Check

The server currently supports Claude and other MCP clients. For ChatGPT or Copilot for M365, you'd need to repackage as an OpenAPI-based REST API or use Microsoft's Graph connectors—different protocols, different architectures.

But for Claude Code users working with Azure DevOps? This turns your entire DevOps platform into a conversational interface.

And it took two sessions to build. One of them while watching a movie about giant sandworms.

The source code is available on GitHub: github.com/grizzlypeaksoftware/ado_mcp

Shane Larson builds AI development tools and writes about practical software engineering at GrizzlyPeakSoftware.com. He's the author of 25 technical books and runs an AI development agency at CortexAgent.com.