It is commonly understood that a “standalone” MongoDB instance is one that does not have replica sets. For example:

Me: In MongoDB, is a standalone server just one with no replica sets?

Gemini: In MongoDB, a standalone server is indeed an instance of the mongod process that runs as a single, independent node and is not part of a replica set. 

Me: What is a MongoDB instance called if it has no replica sets?

ChatGPT: In MongoDB terminology, an instance that does not use replica sets is typically called a standalone server.

Me: What is a MongoDB Standalone instance?

Copilot: A MongoDB standalone instance is a single, independent mongod server that runs without replication, clustering, or high‑availability features. It is typically used for development, testing, or lightweight workloads—not production—because it has no failover or redundancy.

However, this has been really confusing to me because the C# Driver has been returning ClusterType.Standalone when connecting to an instance with a single replica set. I investigated this and found that the problem is that “directConnection=true” forces the ClusterType to Standalone, even if there is a replica set. This felt lik a bug to me, but Claude says it is not:

The ClusterType.Standalone you're seeing is NOT a bug in behavior — it's the C# driver's way of representing the SDAM spec's "Single" topology. But the naming is misleading.

The SDAM spec defines a "Single" topology type for directConnection=true that is distinct from "Standalone". The C# driver has no separate ClusterType.Single value — it reuses ClusterType.Standalone for both.  

You can see the explicit mapping in the SDAM test runner (ServerDiscoveryAndMonitoringTestRunner.cs:247):

  case "Single":                                            

      cluster.Description.Type.Should().Be(ClusterType.Standalone);

What actually matters is that the server type IS correctly reported. When you connect to Atlas Local with directConnection=true and the server is an RS primary, cluster.Description.Servers[0].Type will be ServerType.ReplicaSetPrimary, not ServerType.Standalone. The cluster type is just a misleading label.

There's no functional bug either because both ReadPreferenceServerSelector and WritableServerSelector check cluster.DirectConnection first (line 74-77 in both), and if it's true, they bypass all the cluster-type-based selection logic entirely and just return all servers. The ClusterType.Standalone value is never consulted for a direct connection.

The real issue is that ClusterType.Standalone is overloaded to mean two different things:

1. The server genuinely is a standalone mongod with no replica set
2. The client is in direct-connection "Single" topology mode, regardless of what the server actually is

If you're checking ClusterType to determine whether you can use transactions or replica-set features, you should instead check the server type (ServerDescription.Type), which accurately reflects RSPrimary, RSSecondary, etc. even with directConnection=true.