Where we are
You now know why MCP exists (a1) and how a host, client, and server fit together (a2). This session zooms out to the market. A protocol lives or dies by its ecosystem: the vendors who speak it, the servers you can pick up instead of building, and the place you go to find them. We keep using Daybreak, the fictional coffee-subscription brand, to make the build-vs-buy call concrete. The single idea to hold onto: MCP already won the standards fight, so your decisions are no longer "should we?" - they are "which servers, from where, and in what order?"
The numbers that matter 7 min live
You do not adopt a standard on faith; you adopt it on evidence that it already won. Four numbers make the case. Roughly 97 million monthly SDK downloads - the toolkits developers use to build MCP into apps and servers. Around 10,000 active servers - capabilities already built and shareable. An official registry since September 2025 - a single public place to find them. And every major AI vendor on board - OpenAI, Google, and Microsoft all speak MCP. When the toolkit downloads, the server count, the discovery layer, and the vendor list all point the same way, "standard-won" stops being an opinion.
LiveWhat "the standard won" actually buys you4 min▶
A won standard changes the shape of your risk. Three consequences a leader should be able to name:
- Portability. Because every major host speaks MCP, a server your team builds today works with the AI apps you have not chosen yet. You are not betting on one vendor's roadmap - you are building to an interface they all implement.
- A supply of ready-made capability. Ten thousand servers means many of the connections you need already exist. The default question flips from "who can build this?" to "is there already one worth adopting?"
- Hiring and knowledge compound. A standard the whole industry uses is one your people can learn once and reuse everywhere. That is the same reason organizations standardized on HTTP and SQL.
Daybreak's calculus. Daybreak runs Claude in support and Copilot in ops. Because both are MCP hosts, the one sales server their data team builds serves both - and will serve whatever they adopt next year. That portability, not any single feature, is why they chose to build on MCP rather than a vendor-specific plugin format that could be deprecated (as a1's stalled-pilot story showed).
Self-studyHow to read fast-moving adoption numbers honestly3 min read▶
These figures move quickly, so treat them as direction, not decimals:
- Download counts include churn. SDK downloads measure developer activity and enthusiasm, not deployed servers in production. They are a momentum signal, a strong one, but not a headcount.
- "Around 10,000 servers" mixes quality levels. Some are production-grade and maintained; many are experiments. The registry (Part 2) is how you tell them apart.
- Re-check before you cite. The ecosystem reports new numbers often. Before a board deck, pull the current figure rather than reusing last quarter's.
The honest headline for a leadership audience is qualitative and durable: MCP has crossed from "promising" to "assumed." The exact number is this quarter's; the trend is the point.
The registry as your app store 8 min live
Ten thousand servers are only useful if you can find and trust them. Since September 2025 the official registry does for MCP servers roughly what an app store does for apps: discovery (search a public catalog instead of hunting across repos), versioning (know which release you are adopting and when it changed), and moderation (a listing process, not a free-for-all). It is the hub the whole ecosystem organizes around - your SDKs on one side, hosts and servers on the other, and your own organization plugging in.
LiveEvaluating a listed server before you trust it4 min▶
A listing in the registry is a starting point, not a seal of approval - the same way an app being in the store does not make it right for your company. Judge every candidate on five things:
- Maintainer. Who publishes it - the system's own vendor, a known company, or an anonymous individual? A first-party server (the vendor of the system it connects to) is usually the safest bet.
- Auth model. How does it authenticate to your system? Modern, standard authentication is table stakes; "paste your admin password" is a hard no. (a4 goes deep on this.)
- Update cadence. When was it last updated, and how regularly? A server abandoned six months ago is a liability the day your system changes.
- Capability scope. Apply a2's control triangle - how many tools, do any of them write or delete, and what do the resources expose?
- Local or remote. Is this something one person runs, or something you can host and govern centrally? Prefer remote for anything shared (a2).
Leadership takeaway: adopting a server is a supplier decision, not an install. The same diligence you apply to any vendor applies here - the registry just makes the candidates easy to find.
Self-studyAggregators and enterprise catalogs3 min read▶
Above the public registry, a layer of curation is emerging that larger organizations will care about:
- Aggregators collect, rank, and review servers - the "editor's picks" on top of the raw catalog. Useful for discovery, but their judgement is theirs, not yours; treat a rating as a lead, not a decision.
- Enterprise catalogs are the internal version: a curated, approved list of servers your organization allows, with governance baked in. This is where a mature company ends up - a private allow-list drawn from the public registry, vetted against your own security bar.
- Why it matters now: the choice is not "public registry vs nothing." Standing up an internal catalog early is how you get the benefits of the ecosystem without the sprawl a1 warned about. a5 covers how to run one.
Build vs buy vs wait 6 min live
With a real supply of servers, your job becomes portfolio strategy, not engineering. Two questions sort almost every candidate: how sensitive is the data the server touches, and how differentiating is the capability to your business. Plot those two and a clear policy falls out - buy commodity connections to standard systems, build the servers that sit on your proprietary data, and wait on categories that are still immature. The matrix below is the whole decision on one page.
LiveReading the matrix in Daybreak terms4 min▶
The quadrants are abstract until you drop real systems in. Here is how Daybreak sorts its candidates:
- Buy: the connection to their calendar and their help-desk tool. Standard systems, non-sensitive, plenty of maintained servers. Building these would be paying to reinvent a commodity.
- Build: the server over their subscription and sales data. That data is both sensitive and their competitive edge - exactly the quadrant where you own the server rather than hand it to a third party.
- Wait: a server that would let AI act on their fulfillment robotics. The category is young, the risk of an action tool going wrong is high, and there is no mature option. Revisit next quarter.
Leadership takeaway: the matrix is not a one-time exercise. Systems move between quadrants as categories mature - today's "wait" is next year's "buy." Re-run it each planning cycle.
Score three candidate servers ★ 8 min · pen and paper
The five-point evaluation from Part 2 is a muscle. Exercise it on three fictional-but-realistic listings and you will apply it to real ones without hesitation.
Three listings to score. (A) "OfficeCal Connector" - published by the calendar vendor itself, modern auth, updated last week, three read-only tools, remote. (B) "MegaCRM Bridge" - published by an unknown individual, "enter your API key," last updated 11 months ago, includes a delete-record tool, local only. (C) "SalesDB Server" - your own data team, modern auth, updated weekly, read-only query tools plus a catalog resource, remote.
Score each on the five points: maintainer, auth model, update cadence, capability scope, local vs remote. Give a simple green / amber / red per point.
Decide adopt / investigate / reject for each. Write one sentence of reasoning - the sentence you would say in an approval meeting.
Compare with the read below. If your instinct matched, you have the method. If not, note which point you under-weighted.
LiveThe scored answer3 min▶
A - OfficeCal: adopt. First-party maintainer, modern auth, fresh, read-only, remote. A textbook "buy the commodity connector."
B - MegaCRM Bridge: reject. Unknown maintainer, password-in-plaintext auth, stale, a destructive write tool, local only. Any one of those is a stop; together they are a clear no.
C - SalesDB: adopt and own. Your team maintains it, it sits on proprietary data, it is read-only and remote. This is the "build on your moat" quadrant made real.
Notice: you reached defensible decisions on all three with no code and no vendor call - just the five points and a2's control triangle.
Your org's first three servers ★ 6 min · prioritize
Strategy is choosing what comes first. Using the N x M worksheet from a1 and the matrix above, name the first three servers your organization should stand up - and be ready to defend the order.
Pull your a1 worksheet - the list of systems AI should reach, with business value and data owner. That is your candidate pool.
Place each on the matrix: buy, build, or wait. Cross off the "wait" ones for now.
Rank the survivors by value-to-effort: highest business value, lowest build cost, clearest data owner rises to the top. Buy candidates usually rank fast because effort is low.
Write the top three as a one-line brief each: system, buy-or-build, who owns it, why it is first. This is what you take to your data team and, in a5, into a rollout plan.
Before session 4 ◐ 20-30 min total
- Open the official registry at registry.modelcontextprotocol.io and find a real server for a system you actually use. Score it on the five points. Notice how much you can judge in two minutes.
- Finish your first-three-servers shortlist from Demo 2 and share it with the data or platform lead. Their pushback is free strategy.
- For your top build candidate, write one sentence on why building beats buying - if you cannot, it may belong in the buy column.
- Bring one worry about trusting a third-party server to session 4 - "how do we know it will not leak our data?" is exactly what a4 answers.
Official sources covered
This session distills the official registry documentation and public ecosystem reporting into decision-maker language. Live catalogs and figures stay on the official sites; this page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · What does the official registry provide that a scattered set of code repos does not?
The registry (live since September 2025) is the app-store layer: search a catalog, see versions, and rely on a listing process. A listing is a starting point for your own five-point diligence, not a safety guarantee.
2 · A server touches your proprietary subscription data and gives you a real competitive edge. Build, buy, or wait?
High data sensitivity and high differentiation is the "build your moat" quadrant. You buy commodity connections, wait on immature categories, and build the servers that sit on the data that makes you distinct.
3 · You are judging a registry listing. Which combination should stop you cold?
Any one of an anonymous maintainer, weak auth, staleness, or a destructive tool is a warning; together they are a clear reject. Remote-vs-local is a governance choice, not a red flag - remote is usually preferable for shared capabilities.