A Knative cold start is a sum of terms: image pull or warm cache hit, container start, language runtime initialisation, and application bootstrap [3]. The first three are roughly the same whatever you wrote the service in. The fourth is where the Python adapters spent their five seconds, because the interpreter has to start, the import statements run, and the dependency tree gets walked before your handler exists [4].
What makes the before-and-after worth reading is the control. The Go adapter, clickup-mcp, was running on the same cluster under the same Knative configuration [8]. That holds the platform terms fixed and moves only the bootstrap term, which is the comparison you need before attributing five seconds to a language.
The figures also check against each other. The per-service measurements were 5.9, 4.9, 5.4 and 7.2 seconds [7], which sum to 23.4 and land inside the range reported for a cold draft chain [15]. Four Go hops at the slow end of that band, 400 milliseconds each, come to 1.6 seconds [16], so "roughly 2 seconds" after the port is the per-service number rounded up rather than a second, softer claim. The recovery is about 21 seconds per cold run [17].
The constraint that forces the design is upstream of the language. Warm replicas are ruled out because the cluster is paid for personally, so everything scales to zero [5], and an agent that reaches for these tools constantly hits an idle service almost every time [6]. That latency was purchasable two ways, continuously with a warm replica or once with weekends [10].
For the result to transfer, your chain has to be sequential. The draft phase calls four adapters one after another [9]; fan them out concurrently and the cold-start cost is the slowest hop, 7.2 seconds, not the sum [18]. You also need traffic thin enough that idle-then-invoke is the normal path [6]. A service with steady arrivals pays the bootstrap bill once and a rewrite buys it nothing.
The write-up skips profiling the Python imports, trimming the dependency tree, or timing how many hours the port itself took [19]. So the measurements support the claim that Go starts an order of magnitude faster on this cluster [8], but they don't establish that 5 to 7 seconds was the floor for these Python services; the first of those two findings was tested, the second was not.
The port was cheap for a reason specific to this class of service. An MCP adapter is a thin wrapper that lets an agent call something external [1], and two of the four APIs had no usable Go SDK, so the requests were hand-rolled and took less time than expected because modern APIs are mostly REST and JSON [12]. Two services held small in-memory caches, which Python gave away for free and Go made him decide about; the answer was sync.Map [13]. He settled on net/http plus slog, observing that the number of choices Go gives you for stdlib HTTP is zero, and that this is why the step is fast [11]. The final image is a static binary from a golang:1.25-alpine builder into FROM scratch [14].
Six seconds was also the good case; some services took longer, and an agent waiting on a cold start cannot tell the difference between a slow tool and a broken one [20]. That risk sits outside what any latency table measures.
