Understand the checks

Before you connect an agent, know what was actually tested. We check connections and inspect published information. We never execute a server’s tools.

Start with the result

Passed: The check met its rule when measured. Open the rule to see exactly what passed.
Failed: The condition was not met. A paid or sign-in-only service can fail an access check by design.
Not measured: There is not enough evidence, or the check does not apply. This is not a failure.

Check the date, too. “Responded” describes the last measured handshake. After 24 hours, we label that observation “Outdated check”. This is a freshness warning, separate from pass or fail.

The measurement process

A connection check, not a test run of the tools

A probe is an automated visit to the server’s listed endpoint. Here is what it does.

01
Read the listing
Find the server’s declared address and publisher information.
Registry & listing
02
Start a connection
Ask the server to introduce itself and agree on an MCP version.
initialize
03
Ask for the tool list
Read advertised capabilities, input fields, and descriptions.
tools/list
04
Compare observations
Use stored attempts to measure response times and detect some tool changes.
Measured history

We do not call the tools, verify their answers, test their business logic, or audit their code. A passed connection check is not a security certification.

The check reference

Find the checks that matter to you

Each row explains why the check matters. Open it for the pass rule and its limits.

Evidence types

Connection test: a direct attempt to communicate. Repeated measurements: a summary of stored attempts. Published information: inspection of a listing, source page, or tool metadata.

Can my agent connect?

These checks establish a basic connection and ask what tools the server offers. Start here before comparing speed or publisher details.

Connection completes promptlyA server needs to respond before an agent can discover its tools.Connection test

Shown on server listings as Reachable

Passes when: The latest attempt succeeds, returns HTTP 200, and its recorded connection-and-discovery time is no more than 12 seconds. A successful attempt with no recorded duration also passes.
Keep in mind: One successful attempt is a dated observation. It does not establish continuous availability. An authentication-required response leaves the core connection checks unmeasured, rather than failed.

The server speaks MCPYour agent and the server need to agree on how to communicate.Connection test

Shown on server listings as Valid handshake

Passes when: The latest attempt succeeds, returns a protocol version we support, and provides a nonempty server name.
Keep in mind: A completed introduction does not prove the server’s tools work or that every MCP client is compatible.

At least one tool is discoverableAn agent needs to discover a capability before it can use it.Connection test

Shown on server listings as Lists tools

Passes when: The latest attempt succeeds and its tools/list response contains at least one tool.
Keep in mind: We read the tool list. We do not run the tools or check their output.

Meets our protocol baselineOlder protocol versions can limit which clients or features work.Connection test

Shown on server listings as Current protocol

Passes when: The negotiated protocol version is 2025-06-18 or newer. Without a negotiated version, this is not measured.
Keep in mind: This is our compatibility baseline. A pass does not mean the server uses the newest protocol or supports every feature.

The endpoint uses an HTTPS addressHTTPS is the expected address format for an encrypted connection.Published information

Shown on server listings as HTTPS

Passes when: The stored endpoint URL starts with https://.
Keep in mind: This rule inspects the address. It is not a security audit of the server or its data handling.

How does it respond over time?

A recent response is useful; repeated observations tell you more. These checks summarize sampled connection attempts, not the speed or correctness of executing a tool.

Typical connection speedThe median shows the middle response time, so a few unusually slow attempts have less influence.Repeated measurements

Shown on server listings as Fast (p50)

Passes when: Median successful connection-and-discovery time is at most 1 second, using at least 5 successful samples from the last 7 days.
Keep in mind: This includes initialization, tool-list pages, and any retries or crawl delays within the probe. It is not tool execution time. Failed attempts do not enter this latency calculation.

Slower connection speedThe 95th percentile shows the slower end: roughly 95% of sampled successful connections were this fast or faster.Repeated measurements

Shown on server listings as Consistent (p95)

Passes when: The 95th-percentile successful connection-and-discovery time is at most 3 seconds, using at least 20 successful samples from the last 7 days.
Keep in mind: For example, p95 of 2 seconds means most sampled connections took 2 seconds or less. The slowest few can still take longer. Failed attempts are excluded.

Sampled connection successThis tells you how often our attempts completed successfully, rather than relying on one recent result.Repeated measurements

Shown on server listings as Reliable (uptime)

Passes when: At least 99% of measured attempts, excluding skipped and authentication-required responses, in the last 30 days succeed, with at least 30 attempts. Success means the probe returned a tool list.
Keep in mind: 99 successful attempts out of 100 is 99% sampled success. This is not continuous uptime, a service guarantee, or proof of 30 days of coverage.

No recorded tool removals or new required inputsA removed tool or a newly required input can break an agent workflow that previously worked.Repeated measurements

Shown on server listings as Stable tool list

Passes when: At least 2 successful probes in the last 30 days, with no recorded tool removal or newly required top-level parameter.
Keep in mind: Adding a tool or changing a description does not fail this check. Other breaking changes may go undetected, and two observations are not continuous monitoring.

What access do I need?

These checks help you prepare credentials and understand pricing evidence. Requiring a login or a paid plan can be a deliberate product choice, not a fault.

Tool discovery works without signing inYou can see whether credentials were needed just to list the server’s tools.Connection test

Shown on server listings as Open access

Passes when: The listing declares no required credentials, and our latest attempt lists tools without supplying any. A declared credential requirement or authentication response fails this condition.
Keep in mind: Tool execution may still require credentials or payment. Open discovery does not mean the service is free.

Sign-in information is publishedAn authentication metadata document can help clients discover how a protected server expects them to sign in.Published information

Shown on server listings as Standard auth

Passes when: When authentication is required, the OAuth protected-resource metadata address returns HTTP 200 and a JSON object. When authentication is not required, this check does not apply.
Keep in mind: We do not complete a login, obtain a token, validate every metadata field, or establish full OAuth compliance.

A free tier has a dated sourceA publisher quote is stronger pricing evidence than assuming a public endpoint must be free.Published information

Shown on server listings as Free tier cited

Passes when: A checked publisher-page quote states free or freemium access and was verified within 90 days.
Keep in mind: Read the quoted limits and current pricing. Missing evidence means unknown; paid plans and expired pricing evidence can fail this condition without indicating a broken server.

Can my agent understand the tools?

We inspect the descriptions and input information returned in the tool list. These are checks of what the server declares, not tests of what its tools actually do.

Every tool has a descriptionAn agent uses tool descriptions to decide which capability fits your request.Published information

Shown on server listings as Tools described

Passes when: Every tool has at least 20 characters after trimming leading and trailing whitespace in its description.
Keep in mind: Length is a basic completeness check. It does not establish clarity, truthfulness, or usefulness.

Tools declare an input structureA defined input shape helps an agent supply the fields a tool expects.Published information

Shown on server listings as Valid input schemas

Passes when: Every tool’s input schema is an object with type set to "object".
Keep in mind: This only checks the top-level shape. We do not fully validate JSON Schema or prove the tool accepts those inputs.

Most input fields are explainedDescriptions give an agent more guidance about what values to supply.Published information

Shown on server listings as Parameters documented

Passes when: At least 80% of declared input properties have a nonempty description, including nested properties. This is measured across the stored tool list. If the tool list declares no input parameters, the check passes.
Keep in mind: Having descriptions does not prove those instructions are complete or correct.

Tool behavior hints are declaredA client can use hints about reading or changing data when deciding how to present a tool.Published information

Shown on server listings as Safety hints

Passes when: Every tool declares a boolean readOnlyHint or destructiveHint. Either true or false counts as a declared hint.
Keep in mind: These are unverified server declarations. A pass does not certify that a tool is read-only, non-destructive, or safe.

Who publishes it?

Listing and repository checks help you investigate the source. Consistent names and available links are evidence you can follow, not an endorsement of the publisher.

The listing comes from the Official MCP RegistryYou can distinguish an official-registry record from a manually added listing.Published information

Shown on server listings as Verified namespace

Passes when: The stored source is the Official MCP Registry. A manual seed does not pass this rule.
Keep in mind: MCP Heartbeat does not independently verify the publisher’s identity, code, or security.

The website matches the publisher nameMatching names can help you spot an unexpected website before following it.Published information

Shown on server listings as Website matches publisher

Passes when: For a reverse-domain namespace, the website host matches that domain after removing www. Other namespace types are not measured by this rule.
Keep in mind: This is a naming comparison, not proof of domain ownership or trustworthiness.

A source repository is linkedA repository link gives you a place to inspect the implementation and its history.Published information

Shown on server listings as Source repo linked

Passes when: A repository URL is present in the listing.
Keep in mind: The check does not establish that the link works, that the code is good, or that the hosted server runs that code.

The GitHub owner matches the publisher nameConsistent publisher and repository names make the link easier to investigate.Published information

Shown on server listings as Repo owner matches

Passes when: For io.github namespaces, the linked GitHub repository owner matches the namespace login, ignoring letter case. Other namespace types are not measured.
Keep in mind: A matching name is not an independent ownership or security investigation.

The registry listing was updated recentlyA recent listing update is one signal that the published information is being maintained.Published information

Shown on server listings as Recently updated

Passes when: The registry update timestamp is within 180 days. A missing update timestamp does not pass.
Keep in mind: This is the listing’s date. It does not prove recent code changes, maintenance quality, or active support.

GitHub reports an open-source licenceA recognized licence helps you investigate the terms for using or modifying linked source code.Published information

Shown on server listings as Open-source licence

Passes when: GitHub’s licence lookup reports a licence recognized by the Open Source Initiative (OSI). Without a completed applicable lookup, this is not measured.
Keep in mind: This is not a legal review or proof that the deployed service is open source.

Use the evidence to decide what to inspect next

Check connection results and their dates first. For an ongoing workflow, look for enough repeated measurements. Then review access requirements, the tool descriptions, and the publisher’s source information.

The default directory order puts more passed checks first, followed by core checks, sampled success rate, latency, and recency. Enough observations can make a sample-based check measurable; additional observations can also reveal failures. Compare relevant checks and sample sizes, not just totals.

Inspect server measurements

Technical details of the probe

Requests and time limits

We send initialize, notifications/initialized, and tools/list. We never send tools/call. We try supported protocol versions in this order: 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05. A rejected version can trigger another attempt.

The default timeout for each MCP POST request is 12 seconds. Metadata fetches have separate limits. A whole probe can take longer because it may contain retries, multiple tool-list pages, and crawl delays. Connection latency measures that whole sequence, not tool execution. The reachability rule separately requires recorded duration of no more than 12 seconds.

Sampling and ordering

Speed checks use successful attempts from a 7-day window. Sampled success and tool stability use a 30-day window. A window is not a guarantee of continuous coverage. Skipped probes and authentication-required responses (HTTP 401/403) are excluded from the sampled success rate.

Remote listings have 22 checks. Local-only packages use the six publisher checks because there is no remote endpoint to probe. Their raw totals should not be compared.

Request boundaries

Probes use the endpoint declared by a registry or manual listing. Redirects to a different hostname and legacy SSE message URLs to a different origin are refused. Up to two probes run per host and eight overall. We read robots.txt crawl delays and cap the applied delay at two seconds.

Probe requests identify themselves as MCPHeartbeat/0.2.0 (+https://mcpheartbeat.com; MCPTrustCheck; automated measurements; initialize and tools/list only; no tools/call). Listing headers cannot replace this identifier.