Remote MCP server security best practices

To score well on VerifyMCP, a remote MCP server has to get the fundamentals of a trustworthy connection right: answer on a supported MCP transport, serve a valid CA-trusted TLS certificate, and redirect plaintext HTTP to HTTPS. On top of that solid base you add HSTS, DNSSEC, OAuth (where the server handles sensitive actions), a current protocol version, complete and well-typed tool schemas, and a stable tool surface. The transport and TLS checks come first. Every signal below links to a focused guide that tells you exactly what we checked and how to make it pass on the next crawl.

What is a remote MCP server?

A remote MCP server is a live HTTP endpoint that clients connect to over the network, rather than a package you download and run locally. That difference is the whole point of scoring remote servers on their own rubric, separately from packages. A packaged server is scored on supply-chain and provenance signals that sit still in a registry. A remote server is a running service, so its security surface is everything an attacker on the network path, or a client that trusts the wrong endpoint, could exploit right now.

Remote servers answer over a network transport, which the MCP specification defines as Streamable HTTP (the older HTTP+SSE transport is now deprecated). Because the endpoint is reachable, we can inspect it directly. We open the transport, complete the TLS handshake, read the response headers, resolve the DNS chain, negotiate the MCP protocol, and enumerate the tools it exposes. Each of those checks maps to a signal in the remote rubric, and every signal contributes to the trust score.

If you are building a remote server rather than hardening an existing one, the per-language build guides cover TypeScript, Python, .NET, Go, Java, Kotlin and Rust from scratch.

What VerifyMCP checks

These are the properties the remote rubric scores, ordered roughly by how foundational they are. The transport and TLS signals gate everything else: if we cannot reach the endpoint or cannot trust the certificate, the connection itself is untrustworthy and the score is capped regardless of how good the rest of the server is.

Serve a reachable MCP transport: the endpoint must answer on a supported MCP transport before anything else can be assessed.
TLS certificate: serve a CA-trusted, hostname-matching certificate with a strong key over TLS 1.2+.
Enforce HTTPS: redirect plaintext HTTP to HTTPS so credentials and tool traffic are never sent in the clear.
HSTS header: tell browsers and clients to refuse plaintext connections to your host in future.
DNSSEC: sign your DNS zone so the address clients resolve cannot be forged.
OAuth / RFC 9728: advertise protected-resource metadata and authorise access with OAuth where the server handles sensitive actions.
Current protocol version: negotiate a supported, up-to-date MCP protocol version.
Capabilities: declare the capabilities your server actually implements so clients can rely on them.
Tool schema quality: give every tool a complete, well-typed input schema with descriptions.
Tool coverage: describe every tool and parameter, and declare output schemas.
Tool-surface stability: keep the exposed tool set stable so clients are not surprised by silent changes.

How is the remote score calculated?

The remote rubric explains exactly how these signals combine, which ones cap the score, and what happens when a signal is inconclusive. For the wider picture of how VerifyMCP grades both remote servers and packages, see the how we score overview.

Work through the guides above in order. The transport and TLS fixes unblock the rest, and each guide tells you what we checked, why it matters, and what a passing signal looks like.