MCP Server Inspector

What is MCP and why audit it?

The Model Context Protocol (MCP) is the open standard, introduced by Anthropic, for connecting Large Language Models to external tools and data sources. By 2026, MCP marketplaces list thousands of community-built servers — calendar, GitHub, Slack, Postgres, Stripe, browser automation, file systems, internal company APIs, you name it. Installing an MCP server gives an LLM the ability to take real actions on your behalf, which means a malicious or sloppy server is functionally equivalent to running an unaudited binary with your credentials.

The MCP threat model in one paragraph

An MCP server is just a process you run that exposes tools to a client like Claude Desktop, Cursor, or Continue. Most servers are written in TypeScript or Python, fetch things over HTTP, and read/write files or hit your APIs with credentials you provide. The four most common security issues we find when auditing them are: (1) SSRF — the server fetches user-controlled URLs without restricting localhost/internal addresses; (2) command injection — user input is passed to exec or spawn without escaping; (3) missing auth — anyone who can reach the server can use it; (4) abandonment — the server hasn't been touched in months, dependencies are vulnerable, and nobody is going to fix it. This inspector flags all four plus a dozen more.

How the MCP Server Inspector works

The tool calls the public GitHub API directly from your browser. It fetches: repo metadata (stars, last push, archived status, license, default branch, open issues), the file tree, and the contents of likely-suspect files (package.json, pyproject.toml, README.md, the main entrypoint, mcp.json, smithery.yaml). It then runs a battery of regex-based checks against those files plus reasoning over the metadata. Every signal is shown in the breakdown so you can verify the finding yourself.

The 20+ checks, by category

Security: code patterns

• SSRF risk. Code that calls fetch, axios, requests.get, or urllib using a parameter the LLM controls — without validating that the URL is not 127.0.0.1, 169.254.169.254 (AWS metadata), or an internal IP range.
• Command injection. Use of exec, spawn, execSync, os.system, or shell-string interpolation with model-controlled arguments. The classic backdoor in agentic systems.
• Dynamic code execution. Any use of eval, Function(), vm.runInNewContext, or Python's exec(). Almost always a bad pattern in an MCP.
• Path traversal. File-reading code that takes a path from the LLM without restricting to a base directory.
• Hardcoded secrets. Strings that look like API keys, JWTs, or AWS credentials baked into source.

Security: configuration

• Missing authentication. Servers that expose HTTP transports without an API-key or token check.
• Permissive CORS. Wildcard Access-Control-Allow-Origin on a server that handles credentials.
• Network reach. Mention of 0.0.0.0 binds — the server is listening on all interfaces, not just localhost.

Health and trust

• Last commit age. Anything older than 6 months on an MCP server is a yellow flag; older than a year is red.
• Archived status. Archived repos receive no security fixes.
• License. No license = nobody can legally use it; some licenses (AGPL) carry obligations.
• Open issues. Hundreds of stale issues with no responses signal abandonment.
• Stars and watchers. A heuristic-only signal, but extreme outliers (1 star, 0 watchers, 50,000 lines of code) deserve a closer look.
• Dependencies. If package.json exists, we count direct deps and flag suspicious ones (binary loaders, network-heavy libraries, deprecated packages).

What this inspector cannot do

• Detect runtime-only vulnerabilities. Static-pattern scanners miss issues that depend on how a function is called at runtime.
• Audit private repos without your token. Anonymous public-API access only sees public repos.
• Replace a real security review. For high-stakes deployments — anything touching production credentials — pay a security firm or run the server in a sandbox.
• Audit non-GitHub sources. Code on GitLab, Bitbucket, or self-hosted Git is out of scope for v1.

Why a browser-only tool?

Sending other people's repository contents to a SaaS scanner feels backwards when the scanner needs no special privileges. The browser already has a network stack and a regex engine — that's all you need. Your audits stay private, the GitHub API quota is yours (and you can lift it from 60/hour to 5,000/hour with a personal access token that never leaves the page), and the source of every check is auditable in this file.

FAQ

Will this audit any GitHub repo or only MCP servers? It works on any repo, but the heuristics are tuned for the MCP threat model. A general-purpose web app might get false positives on signals that are normal for a web framework but suspicious in a tool an LLM controls.

Where does my token go? Only to api.github.com, sent over HTTPS as the Authorization header. It never reaches our servers — there are no servers. View the network tab to verify.

Why does anonymous mode hit the rate limit so fast? GitHub allows 60 unauthenticated requests per hour per IP. Each audit makes 8–12 calls. Add a token (read:public_repo scope is enough) and you get 5,000/hour.

Can I trust an MCP that scores well here? A good score means no obvious red flags — not that the server is safe. A determined attacker can hide intent in subtle ways. Treat this as a first filter.

How is this different from Glama or other MCP marketplaces? Marketplaces curate. Inspectors audit. Use both: pick a server from a curated marketplace, then run it through the inspector before installing.