How to Audit an MCP Server Before Install

Audit an MCP server by checking its scopes, maintenance signals, and sandbox behavior before granting it production access. Read the permissions it requests — GitHub MCP, for instance, runs on a fine-grained PAT that should stay scoped to read-only until a human approves write access. Check repo-health signals like last commit date, open issue count and license, the same signals a service like CheckMCP scores. Then run the server against disposable data before pointing it at anything real.

What should you check before installing an MCP server?

MCP is an open protocol that lets AI applications like Claude connect directly to external systems — data sources, tools and workflows — according to modelcontextprotocol.io. That directness is exactly why an audit matters before install: once a server is registered, an agent can call its tools without you reviewing every request line by line. The GitHub directory page describes the official server as "the most installed MCP server in the wild," which also means it's the server most agents point at real repositories, issues and pull requests by default.

Before installing, work through four checks in order: what scopes and permissions the server's tools actually request, whether the underlying project shows recent, active maintenance, whether you can safely test its behavior in a sandbox before pointing it at production data, and — if the directory page shows one — what an audit score like CheckMCP's is actually measuring. Each check catches a different failure mode, and skipping any one of them just moves the risk from install time to runtime.

What scopes and permissions does the server actually request?

Start with the credential the server asks you to create, not the tool list. The GitHub MCP server authenticates with a fine-grained personal access token, and its directory page is explicit that you should "set the smallest scope (read-only repo + issues for safety), upgrade to write only when you have explicit human approval in the loop." That's the audit habit worth copying for any server: grant the minimum a workflow needs today, not the scope you think you might need next month.

Read the pitfalls section on the directory page, if there is one — it often documents scope traps that aren't obvious from the token creation screen. For GitHub MCP specifically, the page warns that fine-grained tokens have a counterintuitive limit: the "all repositories" toggle does not include private repos by default, so list_pull_requests can silently return empty results against a private repo until you regenerate the token with that repo explicitly selected. That's the kind of detail you only catch by reading the documented pitfalls before, not after, wiring a server into an agent workflow. See How to Use GitHub MCP with Claude Code for the full setup.

How do you check whether an MCP server is still maintained?

A server you install today keeps running tool calls against your accounts for as long as it stays wired in — so maintenance signals matter as much as scopes. The Context7 directory page shows what that looks like in practice: a repo audit line reading "last commit 2 days ago · 61,120 stars · MIT licence · 47 open issues," scored on licence, adoption, maintenance and documentation of the upstash/context7 repository, with a link to "Read the full audit on CheckMCP."

Each of those numbers tells you something different. Recent commit activity signals the maintainer is still responding to the ecosystem; star count is a rough adoption proxy, not a safety signal on its own; the license determines whether you're even allowed to self-host or fork if the maintainer disappears; and open issue count, read alongside commit recency, tells you whether problems are being triaged or piling up. As of September 2026 the Context7 page reports that combination as a 100/100 audit, which the page states plainly shows the grade "whether it flatters the server or not" — worth checking directly rather than trusting a badge. See How to Use Context7 MCP for Up-to-Date Docs for how the server itself behaves once installed.

Why test in a sandbox before production?

Even a well-scoped, well-maintained server can behave in ways that surprise you the first time an agent actually drives it, so run it against disposable data before anything real. GitHub MCP's own pitfalls section is a good template for the kind of behavior to check: its create_or_update_file tool commits through the API, which means no GPG signing, no pre-commit hooks, and no CI run on that commit unless branch protection forces one. The documented recommendation is to have the agent push to a branch and open a pull request — never commit straight to main.

Sandbox testing also surfaces limits that only show up under real load. GitHub's search_code tool relies on an index that's "eventually consistent and lossy" — recently pushed code can take minutes to appear, and some file types like lock files aren't indexed at all, so an agent should fall back to cloning and grepping when a search returns fewer than three hits. The API itself is rate-limited to 5,000 requests per hour for an authenticated PAT — fine for triaging a couple hundred issues, but a repo-wide audit across dozens of repos can hit that wall unless the agent batches through GraphQL.

What does the CheckMCP audit score measure — and not measure?

On the Context7 page, the audit score is described as scored on "licence, adoption, maintenance and documentation" of the repository — in other words, it's a repo-health check, built from public signals like commit recency, star count, license type and issue volume. That's genuinely useful: it's the fastest way to see whether a project looks abandoned or actively developed without reading commit history yourself.

What it doesn't claim to do, based on what the page states, is evaluate what the server's tools actually do at runtime — whether a given tool call is scoped correctly, what data it sends where, or how it behaves under adversarial input. A 100/100 repo-health score is a maintenance signal, not a security clearance. Treat it as one input alongside the scope review and sandbox test above, not a replacement for either — the page frames the score as showing the truth "whether it flatters the server or not," a statement about honesty of reporting, not about runtime guarantees.

A 10-point checklist before you install

Pull the checks above into a single pass you can run against any server on the directory before installing it. None of it requires special tooling — most of the information is either on the server's own directory page or one click away on its GitHub repository, and the whole pass takes a few minutes once it's a habit.

1. Read the tool list on the directory page — GitHub MCP ships 9 tools covering repos, issues, PRs and file reads/writes.
2. Check the credential type the server needs (GitHub MCP uses a fine-grained PAT) and scope it to read-only first.
3. Read the pitfalls section if the page has one, not just the install command.
4. Check the last commit date and open issue count in any repo audit, like Context7's "last commit 2 days ago · 47 open issues."
5. Check the license — Context7's audit lists MIT.
6. Check the alternatives table for a narrower or self-hostable option if the primary server's scope feels too broad.
7. Confirm write-capable tools route through a branch/PR flow rather than committing directly, per GitHub MCP's own guidance.
8. Note documented rate limits (GitHub: 5,000 req/h) before wiring a server into a bulk workflow.
9. Test the server against disposable data or a throwaway repo first.
10. Re-run this list periodically — audit scores and pitfalls sections get updated as projects change.

Run through this list every time, even for servers you've used before — pitfalls sections and audit scores get updated as projects evolve, and a server that was safe to grant broad scopes to a few months ago may have changed maintainers, dropped a dependency, or added a new tool with wider reach since then. Treat the checklist as a five-minute habit, not a one-time gate.

FAQ

Does a high CheckMCP score mean a server is safe to use in production?

No — a repo-health score like the one shown on Context7's page evaluates licence, adoption, maintenance and documentation of the repository, not what happens when the server's tools actually run. A 100/100 score, as Context7 shows, tells you the project is actively maintained and openly licensed; it says nothing on its own about how a specific tool call handles your credentials at runtime. Use it alongside a scope review and a sandbox test, not instead of them.

What if a server's directory page doesn't list a price or a pitfalls section?

Some directory pages, like GitHub MCP's, state pricing directly — GitHub MCP is listed as free with 9 verified tools. When a page doesn't mention pitfalls, alternatives or pricing, treat the absence as an information gap rather than a clean bill of health: check the server's own repository documentation before installing, and lean more heavily on the scope and sandbox steps above since you have one less signal to go on.

Should I still scope down a server that looks well maintained?

Yes — maintenance and permission scope are separate risks. A server can show a recent commit, a healthy issue count and a permissive license, like Context7's audit, and still be handed a token with far more access than a given workflow needs. GitHub MCP's own guidance — start read-only, upgrade to write only with explicit human approval — applies regardless of how healthy the underlying repository looks, because scope controls the blast radius if something does go wrong.