Why We Built MCP Servers for Our Tool Stack — And Why Every Devtool Needs One Now
Agents can't call tools that don't expose MCP endpoints. We added MCP to our internal stack and watched agent adoption jump 3x in two weeks. The protocol is the new API gateway for AI.
Published 2026-06-17
Why We Built MCP Servers for Our Tool Stack — And Why Every Devtool Needs One Now
TL;DR: Three-dev team added MCP endpoints to our internal CLI tools; agent-driven usage went from 0 to 60% of daily invocations in 14 days. If your tool doesn’t speak MCP, agents route around it. Full comparison →
The Context
Three-dev team maintaining internal tooling (deployment CLI, schema validator, sync engine) plus client-facing SaaS. Since Jan 2026, daily coding happens in Zed + Continue.dev and VS Code + Cline — agents execute 70% of terminal commands, file edits, and test runs. Problem: agents couldn’t use our custom CLI tools because they only exposed REST APIs and human-oriented CLIs. Agents don’t read docs; they call functions.
What We Tested
| Tool | Use Case | Verdict | Why |
|---|---|---|---|
| Custom CLI (REST only) | Deploy preview environment via agent | ❌ | Agent hallucinated curl flags, auth headers, couldn’t parse JSON errors |
| Custom CLI + MCP server | Same deploy via mcp__deploy__create_preview() | ✅ | Structured input/output, typed errors, agent succeeded first try |
| Coach MCP (external) | PRD review for pricing page | ✅ | 24h from launch to agent-usable; “AI agents are the new buyers” validated |
| Javadocs MCP | API lookup during refactor | ✅ | Agent fetched exact method signatures without context-switching to browser |
The Pivot Point
March 2026: Asked Cline to “deploy a preview for the auth refactor branch.” It tried 4× with our REST API — wrong endpoint, malformed payload, token expiry. Added minimal MCP server (150 lines TypeScript, @modelcontextprotocol/sdk) exposing create_preview, get_logs, promote_to_staging. Same prompt next day: Cline called mcp__deploy__create_preview({branch: "auth-refactor"}), got structured response with URL + logs tail. Deploy succeeded in one shot. Agent adoption of deploy tool went from 0% to 85% of team invocations in two weeks.
What We Use Now
MCP server per internal tool — each ~100-200 lines, exposing 3-5 operations:
deploy-mcp: preview create/list/promote, log tail, rollbackschema-mcp: validate, diff, generate migrationsync-mcp: pull/push config, dry-run, status
All hosted locally via stdio transport (no network auth complexity). Agents discover via mcp.json in repo root. Continue.dev and Cline both auto-load on project open.
When You’d Choose Differently
- REST-only fine if: tool is purely human-operated, no agent integration planned, or team doesn’t use agentic coding workflows
- HTTP/SSE transport if: MCP server must be shared across machines/CI — we keep it local for now
- Full OpenAPI + MCP if: external consumers need both — we generate MCP from OpenAPI spec using
openapi-to-mcp
Tool Crucible Rating
| Dimension | Rating (1–5) | Notes |
|---|---|---|
| Overall | 5 | Highest leverage change to our agent workflow in 2026 |
| Implementation Ease | 4 | 150 LOC/server with SDK; hardest part is designing clean tool interfaces |
| Agent Adoption | 5 | Went from “agents can’t use this” to “agents prefer this” in days |
| Maintenance | 4 | Stable protocol; SDK updates rare; tool logic changes drive updates |
This is part of our MCP Server Evaluation series. See full comparison: MCP Server Implementation Guide: From Zero to Agent-Native in One Afternoon
Last reviewed 2026-06-17. See our methodology and affiliate policy.