Incomplete MCP Inspection Evidence: NEED_REVIEW Is an Adoption Condition
NEED_REVIEW identifies unresolved facts to check before adoption. It proves neither safety nor a vulnerability; reviewers need evidence for the version, configuration, and permissions they intend to use.
Read in JapaneseReceiving an inspection result does not establish that the intended deployment meets its adoption requirements. NEED_REVIEW means a decision still depends on missing or unresolved evidence. It is neither proof of a vulnerability nor evidence that the server is safe.
Key findings
- A saved result alone does not establish readiness for adoption. Read the version, configuration, permissions, and observation date together.
- NEED_REVIEW is an evidence state. The next step is to name and obtain the missing fact.
- Unverified facts and confirmed problems need different responses. Deployment reviewers should address each on its own evidence.
- Incomplete evidence blocks unconditional adoption. It does not require treating every unresolved server as malicious.
Evidence gaps and adoption conditions
| Unresolved fact | What remains unknown | Minimum adoption condition |
|---|---|---|
| Publisher or artifact | Whether the reviewed source produced the deployed package | Bind publisher, exact package/version or image, and deployed artifact |
| Runtime configuration | Which command, arguments, environment, or endpoint actually runs | Capture the effective launch or endpoint configuration without secret values |
| Authorization | Which identity, audience, scopes, and user consent govern access | Test the real issuer, audience, scopes, and denial path |
| Permission boundary | Which files, repositories, records, or services are reachable | Enforce a narrow boundary outside the model and test an out-of-scope target |
| Network destination | Where prompts, tool inputs, files, or results may be sent | Allow only required destinations and verify blocked egress |
The status should drive a concrete branch. If the missing evidence can be obtained before connection, keep the server disconnected until the record is complete. If the fact cannot be observed but a technical control can remove the exposure, record that control and its test. For example, a process that cannot prove its own filesystem limit may still be usable when the operating system exposes only a dedicated directory. If neither evidence nor enforcement is available for access to host files, credentials, command execution, or outbound transfer, the server should not be connected in that environment.
Distinguish an unknown from a confirmed problem
Unverified dependency provenance and a confirmed write outside the approved repository are different adoption concerns. The former needs additional source evidence; the latter needs a patched artifact or effective access restrictions. An absence of confirmed problems is not, by itself, proof of safety.
Bounded acceptance operation
Choose one harmless authorized target and one harmless target outside the approved scope. Confirm the required operation succeeds for the first and fails before any side effect for the second. Record the deployed artifact/version, effective configuration, client identity, granted permissions, and destination controls. Re-run the affected checks after an artifact, permission, credential, or endpoint change.
Limits
This is MCP Guard's public status interpretation as reviewed on September 22, 2026. It does not claim that every current Registry entry has complete evidence or that every NEED_REVIEW row can be resolved with the same test. Official MCP authorization requirements address specific protocol boundaries such as token audience and passthrough; they do not establish artifact provenance, host isolation, or the behavior of every tool.