stotyMan

An MCP server can give an AI assistant access to a filesystem, browser, database, API, or internal service. That makes installation less like adding a bookmark and more like approving a new integration.

Before I install one, I run a short health check. It does not replace a security audit, but it catches the most common problems: stale packages, unclear ownership, excessive permissions, and instructions that no longer match the code.

1. Confirm the canonical source

Start by establishing who owns the project.

Check that the repository, package registry, documentation domain, and maintainer identity point to the same source. If an npm or PyPI package links to a different repository than the one in the documentation, investigate before continuing.

Quick questions:

  • Is the repository under an official organization or a known maintainer?
  • Does the README link to an official product or project page?
  • Does the package metadata point back to the same repository?
  • Is there a clear license and security contact?

Popularity is useful context, but provenance comes first.

2. Look for maintenance evidence

Stars are cumulative; maintenance is current.

Review the latest release, recent meaningful commits, and open issues about authentication or protocol compatibility. A stable project may be quiet, so the date alone is not enough. Look for evidence that maintainers respond when dependencies or upstream APIs change.

Useful signals include:

latest release date
install command matches the current package
recent dependency updates
responses to reproducible bug reports
no archive or deprecation notice

Enter fullscreen mode Exit fullscreen mode

3. Map tools to permissions

List the tools exposed by the server and write down what each one can touch.

A search-only server should not need broad filesystem write access. A GitHub issue assistant may need repository permissions, but it usually should not receive an unrestricted account token. Use read-only credentials and isolated test data whenever possible.

For local servers, pay special attention to:

  • shell execution;
  • unrestricted paths;
  • environment-variable access;
  • outbound network requests;
  • logs that may contain prompts or secrets.

If the permission surface is wider than the feature, stop and ask why.

4. Reproduce the documented install

Do not assume the first command in a README is current. Compare it with the package registry and latest release.

A basic disposable test can be as small as:

mkdir mcp-server-review
cd mcp-server-review
# install with the project's documented package manager
# use a test credential with minimum permissions
# start the server and inspect the advertised tools

Enter fullscreen mode Exit fullscreen mode

Confirm the executable name, required environment variables, transport, and supported client configuration. Missing credentials should produce a clear error instead of a crash or silent fallback.

5. Run one harmless call

After initialization, invoke a read-only tool against non-sensitive data.

You are looking for predictable behavior:

  1. The server initializes cleanly.
  2. The tool list matches the documentation.
  3. A read-only request returns the expected shape.
  4. Logs do not expose secrets.
  5. The process shuts down cleanly.

For a remote server, also check authentication, data retention, and where requests are processed.

6. Plan removal before adoption

Know how to revoke the token, remove the client configuration, delete local caches, and stop background processes. A reversible trial is safer than an integration that quietly becomes permanent.

Use directories for discovery, not blind trust

Directories can save time by surfacing candidates and maintenance signals. They cannot guarantee that a server is appropriate for your threat model.

MCP Radar is a public directory I built to expose maintenance status, TrustScore, rankings, and practical guides. I use it to narrow the candidate list, then verify the source and permissions before installation.

The mental model is simple: discovery gets a project onto the shortlist; verification earns it a place in your environment.

Copyable checklist 

[ ] Canonical repository and maintainer confirmed
[ ] Package metadata matches the repository
[ ] Not archived or clearly abandoned
[ ] Current install instructions reproduced
[ ] Tools and permissions mapped
[ ] Test credential uses least privilege
[ ] Network destinations understood
[ ] Harmless read-only call succeeds
[ ] Logs contain no sensitive data
[ ] Removal and token revocation steps documented

Enter fullscreen mode Exit fullscreen mode

MCP is powerful because it turns model output into action. That is also why a small, repeatable health check belongs between “this looks useful” and “install.”