mycop Now Speaks MCP: Security Scanning Inside Your AI Coding Assistant

Starting with mycop 0.3.0, you can run mycop mcp to start a Model Context Protocol server. Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, and any other MCP-compatible tool can then call mycop's scanning, fixing, and review capabilities directly — without you leaving the conversation.

This means your AI coding assistant can check for SQL injection, XSS, hardcoded secrets, and 97 other vulnerability patterns in real time, as you write code together.

What Is MCP?

MCP (Model Context Protocol) is a standard for connecting AI assistants to external tools. Instead of copy-pasting terminal output back into your chat, MCP lets the assistant call tools directly and get structured results. Think of it as a USB port for AI — one protocol, many tools.

mycop's MCP server communicates over STDIO (stdin/stdout), so it starts instantly and works with any client that supports the protocol.

Setup

First, install mycop if you have not already:

cargo install mycop

Then configure your tool:

Claude Code

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "mycop": {
      "command": "mycop",
      "args": ["mcp"]
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "mycop": {
      "command": "mycop",
      "args": ["mcp"],
      "type": "stdio"
    }
  }
}

Windsurf

Add to .windsurf/mcp.json:

{
  "mcpServers": {
    "mycop": {
      "command": "mycop",
      "args": ["mcp"]
    }
  }
}

That is it. The next time your AI assistant starts, it will have access to all five mycop tools.

The Five Tools

The MCP server exposes five tools that cover mycop's scanning and analysis capabilities:

Why no fix tool? In MCP mode, the agentic tool (Claude Code, Cursor, etc.) is the AI. Having a fix tool that calls another AI underneath is redundant and wasteful. Instead, the agent reads scan findings — each includes a fix_hint — and applies fixes directly using its own code editing capabilities. The CLI mycop fix command remains available for standalone use.

There are also two MCP resources: mycop://rules/catalog gives the full JSON catalog of all 200 rules, and mycop://config/schema provides the default .scanrc.yml configuration template.

What This Looks Like in Practice

Here is a typical workflow with Claude Code:

You: "Scan src/ for security issues."

Claude Code calls the scan tool with {"paths": ["src/"]} and gets back structured JSON with every finding, including rule ID, severity, line number, CWE mapping, and fix hint. No terminal output to parse — the agent works with clean data.

You: "Fix the critical ones."

Claude Code reads the scan findings, sees the fix_hint for each vulnerability (e.g., "Use parameterized queries instead of string formatting"), and edits your code directly. No extra AI call needed — the agent already understands the code and the fix.

You: "Is the login handler in server.ts secure?"

Claude Code calls the review tool with {"path": "src/server.ts"}. mycop sends the file to its AI backend for a deep security review, returning findings about logic flaws, auth patterns, and architectural issues that rule-based scanning alone would miss.

Why MCP Instead of Just Calling the CLI?

AI agents can shell out to mycop scan and parse the terminal output. But MCP is better for three reasons:

1. Structured data. The agent gets JSON with typed fields (severity as an enum, CWE IDs as strings, line numbers as integers), not colored terminal text it has to regex apart. This means fewer misinterpretations and more reliable follow-up actions.
2. Agent-native fixing. Instead of calling a separate AI to generate fixes, the agent reads the fix_hint from each scan finding and applies fixes itself. This is faster, cheaper, and produces better results because the agent has full project context.
3. Discoverability. MCP clients can list available tools and their parameter schemas. Your AI assistant knows what mycop can do, what parameters each tool accepts, and what the response shape looks like — without reading docs.

Architecture Notes

If you are curious about the implementation:

• Built with rmcp. The server uses the official rmcp Rust SDK for MCP. Tools are defined with the #[tool] proc macro and registered via a static ToolBox.
• Sync-to-async bridge. mycop's core scanning uses Rayon for parallelism, which is synchronous. The MCP server runs on tokio. We bridge the two with tokio::task::spawn_blocking — the standard pattern for running CPU-bound work inside an async runtime.
• No stdout leakage. In MCP mode, all diagnostic output goes to stderr. stdout is exclusively for JSON-RPC messages. This prevents scanning progress bars or warnings from corrupting the protocol stream.
• Separate MCP types. We use dedicated FindingOutput and RuleOutput structs for MCP responses rather than adding serialization concerns to the core Finding and Rule types. This keeps the MCP layer isolated from the scanner internals.

Coming Next

This is the first release of the MCP server. A few things on the near-term roadmap:

• MCP prompts. Pre-built prompt templates for common security review workflows (e.g., "review this PR for auth issues").
• Streaming scan results. For large codebases, stream findings as they are discovered rather than waiting for the full scan to complete.
• Remote transport. SSE and WebSocket transports for running mycop as a shared security service that multiple developers connect to.

mycop is MIT licensed and open source. The MCP server ships with the same binary — no additional installation required. See the full changelog for everything in v0.3.0.