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 six mycop tools.

The Six Tools

The MCP server exposes six tools that cover mycop's full capability set:

There are also two MCP resources: mycop://rules/catalog gives the full JSON catalog of all 100 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 calls the fix tool with {"file": "src/auth.py", "severity": "critical"}. By default, dry_run is true, so it gets back a diff preview and the fixed file content. The agent shows you the diff and asks for confirmation before writing.

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

Claude Code calls the review tool with {"file": "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. Safety by default. The fix tool defaults to dry_run=true, so agents cannot accidentally overwrite files without showing you the diff first. The tool schema enforces this at the protocol level.
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.