# A Practical MCP Server Health Check: 6 Signals Before You Install > Source: > Published: 2026-08-01 12:56:23+00:00 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. 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: Popularity is useful context, but provenance comes first. 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 ``` 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: If the permission surface is wider than the feature, stop and ask why. 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 ``` 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. After initialization, invoke a read-only tool against non-sensitive data. You are looking for predictable behavior: For a remote server, also check authentication, data retention, and where requests are processed. 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. Directories can save time by surfacing candidates and maintenance signals. They cannot guarantee that a server is appropriate for your threat model. [MCP Radar](https://www.mcpradars.com/en) 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. ``` [ ] 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 ``` 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.”