How I Find MCP Servers That Are Actually Maintained
The fastest way to choose an MCP server is not to start with the longest directory. Start with evidence that the project is still maintained, then check whether it fits your client and workflow. I use a short sequence: define the job, check lifecycle signals, inspect the repository, verify installation, and only then compare popularity. This reduces the chance of selecting an impressive-looking server that has quietly gone stale.
1. Define the job before searching
“I need an MCP server” is too broad. Write the job as an observable outcome:
- query a database without exposing write access;
- let an agent search current documentation;
- automate a browser with a specific client;
- connect a support workflow to a messaging tool.
This gives you concrete filters: required tools, authentication method, hosting model, operating system, client compatibility, and acceptable permissions.
2. Check lifecycle status, not just stars
Stars show interest, but they do not tell you whether a server is still maintained. I look for several signals together:
| Signal | What it can tell you | Warning sign |
|---|---|---|
| Recent commits | Whether maintenance is continuing | Long silence with unresolved breakage |
| Issue response | Whether maintainers are present | Repeated unanswered installation bugs |
| Release or package activity | Whether fixes reach users | Repository changes without usable releases |
| Archived state | Whether development has officially stopped | Repository is archived |
| Installation verification | Whether the documented setup still works | Missing package, broken command, or incompatible client |
No single signal is decisive. A stable server may not need weekly commits, while a busy repository can still have a broken installation path. The useful question is whether the evidence is consistent with the server's scope.
3. Use a directory that exposes health signals
I built MCP Radar for this part of the workflow. Instead of presenting every listing as equally current, it groups servers by lifecycle and exposes maintenance signals alongside discovery pages. On August 1, 2026, the public catalog showed this snapshot:
| Lifecycle state | Listed servers |
|---|---|
| Active | 1,080 |
| At risk | 95 |
| Abandoned | 9 |
| Not auditable | 1 |
These numbers will change as projects change. The point is not the exact total; it is that lifecycle status should be visible when you are choosing a dependency. The public scoring methodology describes the signals used for ranking, including repository activity, issue response, download trends, and archived state. The project also exposes an open-source repository, so the collection and update approach can be inspected rather than treated as a black box.
4. Verify the candidate at the source
After finding a candidate, open its official repository and documentation. Check:
- the package or executable named in the installation
Comments
No comments yet. Start the discussion.