MCP Shark: Secure and inspect MCP tools locally with static scans and proxy monitoring

[rpgeeganage]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Hi everyone,
I wanted to share MCP Shark, a local-first security scanner and traffic inspection tool for MCP setups.

MCP Shark has two main parts:

1. Static security scanning

It scans MCP configs and tool metadata locally on your machine and flags risky findings, including toxic-flow style capability pairings between servers.

2. Local proxy + monitoring UI

It can aggregate IDE traffic across multiple MCP servers and lets you inspect requests and responses in one place.

A few things I focused on while building it:

• Local by default — no hosted scan backend required
• Privacy-first — static scans send no telemetry
• CI-friendly outputs — terminal, JSON, SARIF, and HTML
• Useful workflows — CLI, watch mode, TUI, and web UI
• Extensible rules — rule packs.

MCP setups can quickly combine secrets, broad tool access, and multiple servers in a single agent context, which makes the overall risk harder to understand.

Some examples of what it tries to help with:

• risky MCP config patterns
• suspicious server combinations
• reviewing tool exposure
• monitoring cross-server traffic in one place
• integrating scans into local workflows or CI

Quick start

npx @mcp-shark/mcp-shark --open

Relevant Links

• GitHub repository: https://github.com/mcp-shark/mcp-shark
• Documentation: here
• Website: https://mcpshark.sh/

[armorer-labs]

Local scanning + proxy monitoring is a strong combination because static analysis and runtime observation catch different classes of failure.\n\nIf you are looking for the most useful validation set, I would definitely include both:\n- obvious dangerous tool calls\n- near-miss benign cases that mention risky concepts but should not trigger enforcement\n\nThat second bucket matters a lot for adoption. A tool can look great on dramatic demos and still become painful in real workflows if it over-flags security docs, test fixtures, policy files, or admin notes that contain scary strings without actually being actionable.\n\nThe other useful split is by boundary: user input, retrieved docs, tool results, generated tool args, outbound content. False positives and false negatives often vary a lot across those surfaces.