MCP Is Everywhere Now — Why Your CLI Tools Need It

May 17, 2026 · 6 min read · By DevForge

85K+
GitHub stars on official MCP servers
23K+
Python SDK stars
1,000+
MCP directories & registries
5+
AI agents that speak MCP

Six months ago, MCP (Model Context Protocol) was a niche protocol for wiring tools into AI agents. Today it's the default integration layer for every major AI coding agent — Claude Code, Cursor, Codex, Windsurf, and Zed all speak MCP natively.

Here's the problem: most developer CLI tools still aren't MCP-servable. That means when an AI agent goes looking for tools to automate API contract testing, infrastructure diffs, or config drift detection, your tools simply don't show up.

The Numbers Don't Lie

The official modelcontextprotocol/servers repo has 85,000+ GitHub stars. The Python SDK sits at 23,000+. FastMCP has been downloaded over 66 million times from PyPI. Directories like Stork.ai now catalog 1,000+ MCP servers.

This isn't a trend anymore — it's infrastructure.

What Happens When Your CLI Isn't MCP-Servable

Imagine running api-contract-guardian check in CI for years. It catches breaking changes before they ship. Your team trusts it.

Now a developer asks Claude Code: "Check my API for breaking changes." Claude doesn't know about your tool. It can't call it. It falls back to generic advice or suggests writing tests from scratch.

The gap is real: AI agents can only use tools they can discover through MCP. If your CLI isn't exposed as an MCP server, it's invisible to every AI coding agent your team uses.

Three Ways to Make Your CLI MCP-Servable

1. Write MCP Handlers by Hand

Use the MCP Python SDK or FastMCP to write a server from scratch. You define tools, handle parameters, and wire up responses.

# Manual approach: ~100 lines per tool
from mcp.server import Server

server = Server("my-tool")

@server.tool("check_api_contracts")
async def check_api_contracts(spec_path: str) -> str:
    # Implement parameter parsing, execution, response formatting
    ...

Pros: Full control over the interface.
Cons: Boilerplate for every tool. You're maintaining two codebases — the CLI and the MCP server. Changes to the CLI require manual updates to the MCP handlers.

2. Use an SDK Wrapper

Libraries like FastMCP reduce the boilerplate, but you still need to write tool definitions that mirror your CLI commands.

from fastmcp import FastMCP

mcp = FastMCP("my-tool")

@mcp.tool()
def check_api_contracts(spec_path: str) -> str:
    """Check API contracts for breaking changes."""
    # Still manual — you define each tool
    ...

Pros: Less boilerplate than raw SDK.
Cons: Still requires code changes and a separate deployment. Every new CLI command needs a matching MCP tool definition.

3. Auto-Wrap with click-to-mcp

Install click-to-mcp, point it at any Click or typer CLI, and it automatically introspects every command, option, and argument — then exposes them as MCP tools.

# Install
pip install git+https://github.com/Coding-Dev-Tools/click-to-mcp.git

# Discover available CLIs
click-to-mcp discover

# Serve any CLI as MCP
click-to-mcp serve api-contract-guardian

Then add it to your Claude Code config:

{
  "mcpServers": {
    "api-contract-guardian": {
      "command": "click-to-mcp",
      "args": ["serve", "api-contract-guardian"]
    }
  }
}

Pros: Zero code changes. One install. Works with any Click/typer CLI. Automatically picks up new commands.
Cons: Only works with Click/typer CLIs (argparse support is planned).

Real Example: Wrapping 7 DevOps Tools at Once

At DevForge, we ship 7 DevOps CLI tools — api-contract-guardian, deploydiff, json2sql, configdrift, and more. Each has multiple subcommands.

Wrapping them manually would mean 30+ tool definitions, parameter mappings, and two codebases to maintain. With click-to-mcp, it's one command per tool:

# All 7 tools, MCP-servable in under 2 minutes
click-to-mcp serve api-contract-guardian  # 4 subcommands → 4 MCP tools
click-to-mcp serve deploydiff             # 3 subcommands → 3 MCP tools
click-to-mcp serve json2sql                # 5 subcommands → 5 MCP tools
click-to-mcp serve configdrift            # 3 subcommands → 3 MCP tools
click-to-mcp serve envault                # 4 subcommands → 4 MCP tools
click-to-mcp serve schemaforge            # 6 subcommands → 6 MCP tools
click-to-mcp serve datamorph              # 3 subcommands → 3 MCP tools

Now Claude Code, Cursor, and every MCP-speaking agent can call any of our 28 tool endpoints without us writing a single MCP handler.

The Bigger Picture: MCP as the New API Surface

MCP is becoming what REST was for web services — the standard way for tools to expose functionality. The difference is the consumer: instead of frontend apps, it's AI agents.

Here's what that means in practice:

If your CLI tool isn't in MCP directories, AI agents can't find it. Submitting to directories like Stork.ai, mcpservers.org, and awesome-mcp-servers is the new SEO for AI.

Getting Started

  1. Install click-to-mcp: pip install git+https://github.com/Coding-Dev-Tools/click-to-mcp.git
  2. Discover your CLIs: click-to-mcp discover
  3. Serve one: click-to-mcp serve your-cli-name
  4. Add to your AI agent config (Claude Code, Cursor, etc.)
  5. Submit to MCP directories for discoverability

That's it. No SDK code, no separate deployments, no maintenance burden. Your existing CLI tools just became AI-accessible.

View click-to-mcp on GitHub →

Further Reading