Reliability
Whether the server starts consistently, completes the MCP handshake, and behaves as its tool declarations claim.
FOLLOWMCP REVIEW SCORE
FMRS scoring method
FollowMCP automatically evaluates servers across five explainable dimensions from source material. Scores total 100 and cannot be bought.
Security and permissions
Whether permissions, credentials, data boundaries, and side effects are clear and follow least privilege.
Maintenance
Whether releases, commits, issue responses, and dependency updates remain active.
Documentation
Whether setup, auth, tool parameters, limits, and troubleshooting are documented with verifiable detail.
Setup experience
The number and complexity of steps from obtaining dependencies to a working connection in major clients.
Scoring rules
- Each dimension is scored independently from 0–20 with a written rationale.
- Missing evidence lowers a score; brand recognition never fills the gap.
- Material security findings, permission boundaries, and side effects must remain visible.
- Upstream metadata and revisions refresh automatically, and scores can be regenerated from current evidence.
Why this scoring exists
The most common failure of directory sites is that every entry looks the same — a paraphrased README with a star count pasted next to it. FMRS exists to force a checkable, disputable rationale instead of just restating a repo's own pitch.
Scores only read objective, verifiable evidence: the source repository itself, its release and commit history, its README, and its install manifest. They ignore star counts, ignore adjectives from a vendor's own description, and are never adjustable for payment — that's scoring rule 2.
Where the evidence comes from
All five dimensions draw on public information from the source repository. No user votes, no paid reviews, no third-party rating aggregation.
- Repository structure and install manifest
- Commit / release timeline, to judge whether maintenance is ongoing
- README statements about tools, permissions, and transport
- Known security advisories or issue discussion, where the repo makes them public
How the letter grades work
85 and above is an A, 70–84 a B, 55–69 a C, and anything under 55 is a D.
A D isn't a penalty — it's the default result of missing evidence. Plenty of D-graded projects work fine; their README just doesn't spell out install steps, permission scope, or a tool list. The rule is no evidence, no score, not no evidence, pass by default.
Frequently asked
- Does the score depend on GitHub star count? — No. Star count is shown separately on list and detail pages as a popularity signal; none of the five dimensions read it, and a well-known project gets no bonus for being well-known.
- Why do some popular projects score low? — Popularity reflects community attention, not evidence we score against. If a project's README doesn't list its actual tools, permission scope, or install steps, that dimension is scored as evidence-missing regardless of star count. Expand the scoring rationale on any detail page to see the specific reasoning.
- How often do scores update? — Whenever the upstream revision (a release or commit) changes, the score is regenerated from current evidence — it isn't computed once at publish time and then frozen.
- What if a score or a detail looks wrong? — Email [email protected] with the server name and what you think is wrong. Corrections from the repository's own maintainer are handled first.