The dependency model

Overview

Three ideas carry the whole model, and each one shows up in your scan report:

• Order. Discovery comes before judgment. A check can only run once the facts it relies on have been established.
• Applicability. A check that does not fit your server’s shape is set aside on purpose — not failed. OAuth checks do not run on a static-key server.
• Foundations. A handful of checks everything else rests on. When one of them cannot complete, the report tells you which, and why, rather than burying it.

The dependency graph

A scan begins by establishing facts about the target: whether it is reachable, what transport it speaks, whether it completes an MCP handshake, which tools, prompts, and resources it exposes, and what authentication it requires. Each of those facts is the output of a check, and other checks depend on them.

Because of that, checks run in dependency order, not catalog order. A check that inspects a tool’s input schema cannot run until the tool list has been retrieved; a check on your TLS certificate cannot run until the handshake has succeeded. The graph has a single root — reachability and transport — that every other check descends from. When the root cannot be established, nothing downstream has anything to run against.

What a check can see

Every check declares exactly which facts it needs and receives only those. A check that examines tool schemas asks for the tool list and nothing else; a check on certificate validity asks for the handshake result. It drills down to its specific inputs rather than reading from a shared pool of everything the scan discovered.

This scoping is deliberate, and it changes how a missing fact is handled. If the input a check needs was never established, the check is held back— it does not run against missing data. That matters because a check run against nothing tends to do one of two things: error, or silently report “no problem found” when the truth is “we never looked.” Gated treats a silent pass on data it never saw as a defect. A check with no inputs does not pass. It does not run.

Gates and applicability

Many checks only make sense for a particular kind of server. OAuth hardening checks are meaningless on a server that authenticates with a static API key. TLS certificate checks are meaningless on a plaintext endpoint. Resource-subscription checks are meaningless on a server that exposes no resources.

Rather than run these and report a misleading pass or fail, Gated gates them: the check activates only when its precondition holds. When it does not, the check is marked not applicable. In your report you will see Not applicable — gated by …, naming the precondition that did not match. This is not a failure and it does not count against your scan grade. It is an honest record that the check did not apply to your server.

Hidden detection steps

Some of the work a scan does is classification, not assessment: deciding the transport kind, the authentication style, whether the endpoint is HTTPS-only. These steps exist only to route the right checks to your server — they produce no finding of their own.

So they do not appear as rows in your report. You see their effect — the relevant checks ran, the irrelevant ones were set aside — but not the step itself. That keeps the report free of noise like “authentication-method detection: passed,” a line that attests to nothing you can act on. The catalog you browse here lists the checks that produce findings; the internal detection steps stay out of it by design.

Outcomes in your report

Beyond a plain pass or fail, every check resolves to one of these states. The distinction between the last two is the one worth internalising.

Irrelevant is the scan working as intended; Failedis the scan telling you something could not be measured — the check itself errored, or a foundational check it depends on did. They can read similarly in a list, which is why Gated labels them distinctly.

In practice you will see Irrelevant far more often than a blocked failure. Irrelevant is routine — most checks do not apply to most servers. A check fails as blocked only when a foundational check errors outright, which is uncommon. When coverage is lost for a more ordinary reason — the surface could not be loaded, credentials were missing — the foundational check still completes and reports that fact, so its dependants are marked not applicable and the loss surfaces as the partial-scan banner below.

Foundational checks and partial scans

A small number of checks are foundational — whole branches of the catalog depend on them. Reaching the server and classifying its transport. Completing the MCP handshake. Listing the tools, prompts, and resources. When one of these cannot complete, an entire branch has nothing to run against, so the report says so directly instead of leaving you to count failed rows.

This takes one of two shapes:

Each case carries a plain-language reason, so a partial or failed scan tells you whether to act — add an identity, fix reachability — or accept it. From here, browse the check catalog to see every check and the family it belongs to.