MCP in Practice

Lazy Connect: Don't Connect Until Needed

You registered 10 MCP services and connect them all on startup? If 3 of them go down, your startup will hang. The lazy connect philosophy is simple: registration ≠ connection — connect only when actually needed.

Startup Method Comparison

Connect All on Startup

All 10 services connect simultaneously; 3 time out → stuck for 30 seconds
Startup Time

Lazy Connect

Instant startup — declare capabilities only. Connect a service only when it is used
Startup Time
Three Principles of Lazy Connect

Registration ≠ Connection

On startup, only register "what tools I have available" — no actual network connections are made. The system starts immediately.

Connect on First Use

A connection is established only when the AI actually needs a tool for the first time. Most tools may never be used in an entire day.

Fault Isolation

If a service goes down, only that one tool is affected. All other tools continue to work normally, and the system as a whole is unaffected.

Real-world difference: Alice has registered 10+ MCP services including Calendar, Email, WPS Notes, Browser, and Database. Connecting all on startup means any unavailable service slows down launch. With lazy connect, startup dropped from 30 seconds to 0.2 seconds — users experience an instant open.
Registration ≠ Connection: declare capabilities first, connect when needed, failure affects only one tool without impacting the whole system. This is not just a technical optimization — it is a fundamental design principle for product stability.