How OpsMCP scores MCP server safety

OpsMCP scores each MCP server from 0 to 100 across four factors: tool capability 35, access 25, maintenance 20, and publisher 20. An input that could not be measured earns no points, and the grade is marked Provisional and cannot be an A.

Rubric version 2026-10-16.3.

How the score works

Every server gets a score from 0 to 100. It is the sum of four factors:

A script builds the score from public data: the official MCP Registry, GitHub, and npm or PyPI when a package is named. Nobody types the numbers in by hand.

Tool capability (35 points)

This factor asks what the tools can do to your systems.

Each tool is classified by the verb in its name, or in its description if the name has none.

• Read: get, list, search.
• Write: create, update, set, add.
• Destructive: delete, remove, exec, execute, run, reset.

If a tool matches more than one class, the most severe one wins. A server where every tool only reads gets the full ratio. A server where every tool is destructive gets none. Write tools count halfway.

A documented read-only mode earns back half of the points lost to write and destructive tools.

Tools that match no listed verb are marked unknown. They are not guessed into a class. Instead, they lower the points this factor can earn. If a server reports more than 150 tools and nobody has checked that count by hand, this factor stays partial and cannot earn its full points.

Access required (25 points)

This factor asks how much trust the server needs.

• Scope, up to 10 points. Wording that asks for admin, root, or global access scores 2. Least-privilege or scoped-token wording scores 10.
• Exposure, up to 8 points. A local process from a registry package scores 6. A remote MCP URL scores 3. This is where the MCP process runs, not every API it calls.
• Credentials, up to 7 points. No key required scores 7. Secrets marked as secret in the registry score 6. A secret with no secret flag scores 3. A secret explicitly marked as not secret scores 1.

A variable counts as a secret when its name contains TOKEN, SECRET, PASSWORD, API_KEY, APIKEY, or CREDENTIAL.

Maintenance (20 points)

This factor asks whether anyone is still looking after the code.

• Last commit on the default branch, up to 8 points. Within 30 days scores 8, then 6 within 90 days, 4 within 180, 2 within a year, and 0 after that.
• Newest GitHub release, up to 6 points. Within 90 days scores 6, then 4 within 180 days, 2 within a year, and 1 if older. A repository with no releases scores 0.
• Issue handling, up to 6 points. If 75 percent or more of issues are closed, it scores 6. At 50 percent or more it scores 4. Below that it scores 2. A repository with no issues scores 3. Pull requests are not counted.

An archived repository scores 0 for the whole factor. The raw dates and counts are still shown.

Publisher (20 points)

This factor asks who stands behind the server.

• Owner, up to 8 points. A server counts as from the official vendor only when its GitHub owner is on the published allowlist. That scores 8. Other organizations score 5. Individual accounts score 3.
• Registry listing, up to 5 points. A listing in the official MCP Registry scores 5. A confirmed absence scores 2.
• License, up to 4 points. A license GitHub can identify scores 4. No license scores 0. If GitHub finds a license file it cannot identify, the points stay unknown.
• Stars, up to 2 points. 100 or more scores 2. 10 or more scores 1. This is a weak signal.
• Age, 1 point if the repository is more than 180 days old. Also a weak signal.

The vendor allowlist is printed on this page. Being on GitHub as an organization does not make a publisher the official vendor.

Grades

The letter comes straight from the score.

Provisional grades

A grade is complete only when all four factors are fully scored. If any part of any factor could not be measured, the grade is provisional, and the grade pill says so.

The rules keep a gap from helping a server:

• An unknown factor counts as 0 of its full weight.
• A partly scored factor keeps only the points that were measured, still out of its full weight.
• A provisional grade cannot be an A. If the number would be an A, the letter is capped at B.
• A zero is stored only when the source actually reported one. Otherwise the field says unknown.

A grade stops being provisional when every input for all four factors is measured. That happens in one of two ways. A later data run measures the missing inputs, or the OpsMCP editor adds recorded evidence for the missing factor. That evidence is shown on the server's page.

How scores get updated

Data is refreshed when the ingest script runs; each page shows its fetch date. Manual reviews are planned; none have been done yet. Nobody can pay to change a score.

Reporting a wrong listing

If a listing looks wrong, use the Report a listing link in the footer. It opens an issue in the public opsmcp-listings repository on GitHub. You can also suggest a server that is not listed yet.

A report does not change a score by itself. The score changes only after the reported fact is verified, and the change is tracked in the public opsmcp-listings GitHub issue for that report.

Hands-on testing

Hands-on testing is a separate record with a date, notes, and what the write tools actually did. It does not change the score. A server shows a Hands-on tested badge only when that record exists. No server has been hands-on tested yet.

What we leave out

SCADA, OT, and industrial-control servers are filtered out. Offensive-security projects, such as exploit and red-team tools, are also left out. The directory is for running IT systems, not attacking them.

What a score does not mean

A score is not a security audit. Nobody has read the code line by line, and nobody has checked what each tool does in practice unless a Hands-on tested badge says so.

A high score is not a guarantee that a server is safe to connect. A low score does not mean a server is malicious. The score reflects public signals on the date the data was fetched, run through the rules on this page. Check the tools, the permissions, and the code yourself before you grant access.

Official-vendor allowlist

• grafana · Grafana Labs
• hashicorp · HashiCorp
• pagerduty · PagerDuty
• netboxlabs · NetBox Labs
• microsoft · Microsoft
• paloaltonetworks · Palo Alto Networks
• prometheus · Prometheus
• ansible · Ansible
• zabbix · Zabbix

Rubric version 2026-10-16.3.