rule_id from a report or a CI comment, or to
turn one off or re-rank it in a mcpscore.toml. It is
regenerated from the rule registry on every change (make docs-rules), so the
tables below always match the code.
Catalog, server-metadata, protocol, probe and package findings include concise repair
guidance and field or response evidence; see the failure guidance contract.
Optional quality advice is labeled in report messages. A rule’s severity is its
score weight, not a statement that an optional field is required by the protocol.
- Rule ID is the stable machine contract used in JSON reports and CI.
- Severity carries its weight in parentheses: the points the rule adds to the score when it passes.
- Applies to is the range of spec revisions the rule judges, by the revision your server negotiated. “2025-11-25 and later” means the requirement was introduced in that revision; “up to” means a later revision removed it. Outside the range the rule is skipped and excluded from the maximum score (see the methodology).
Packaging rules
These rules apply only tomcpscore --package <coordinate>, which reads a
published package’s registry metadata and never downloads or runs it. They are
the only rules a package audit runs, and no server audit runs any of them — the
two judge different targets, so their scores share no denominator. A package
audit says how well a server is published; run the server with --stdio to
score whether it speaks MCP.
package_resolves repair example
Check the registry and identifier, including npm scope. For example, correct npm:scope/server to npm:@scope/server when that is the published name.
package_version_resolves repair example
Correct an unresolvable version pin to an existing supported release. A missing version does not mean the package itself is absent.
package_not_withdrawn repair example
Read the publisher notice before choosing a replacement. npm deprecation warns installers; PyPI yanking changes release selection. Neither means the release was deleted.
package_repository_declared repair example
Publish a repository URL in npm package.json repository or Python [project.urls]. A missing metadata link does not prove that source code is unavailable.
package_license_declared repair example
Declare the actual license in package.json license or pyproject.toml project.license using supported build tooling. For example, use MIT only if the project is actually MIT licensed. This rule does not decide legal permissions.
package_description_present repair example
Publish a concise summary in package.json description or pyproject.toml project.description, for example: Read-only search of the team’s documentation.
Publishers change registry metadata; consumers choose coordinates or ask the publisher to correct it. These are packaging recommendations, not MCP wire-protocol requirements.
Sources: npm package metadata, npm deprecation, Python project metadata, Python file yanking.
Protocol Version
Server Info
Capabilities
Security
The Security & Auth category. OWASP MCP Top 10 coverage maps these rules to the OWASP risks and lists what an audit from outside cannot see.Tools
Transport
Resources
Resource Templates
Prompts
Pagination
Readiness rules
These rules assess readiness for MCP 2026-07-28 on the independent readiness axis. For modern-lifecycle servers in full audits, they are also counted in the main score; legacy and partial audits keep them separate. See the methodology for the normative citations behind each rule.Retired rules
Theserule_ids no longer run. They are listed because a rule ID is a public
contract: it appears in JSON reports you may have stored and in CI
configuration that may still reference it. Retired IDs are never reused.
A rule is retired only when it was wrong. A rule that was correct but applies
only to certain spec revisions is not retired — it keeps its ID and gains a
version range in the Applies to column above.
If a report of yours shows one of these, its result was accurate for the
mcpscore version that produced it; the check simply no longer exists.