From understanding to a plan
Every session so far has built your judgment. This one spends it. The mistake leaders make with a new standard is to ask "should we adopt MCP?" - a yes/no that stalls in committee. The better question is "where does MCP shaped work already exist in our building, and what is the cheapest one to prove?" That reframe is the whole session: a repeatable way to spot the opportunities, a clear posture for each one, and a number the board can act on.
Scanning for MCP-shaped wins 15 min live
There is one tell that never fails. Watch where a person moves information by hand between an AI assistant and a system of record - copying a customer ID out of a chat and into a dashboard, pasting a report back into the chat to ask a follow-up question. Every one of those hops is a human being a human API. An MCP server removes the hop: the AI reaches the system directly, under your rules. So the scan is not "where could we use AI?" - it is "where are people already shuttling data in and out of AI by hand?" Those are your candidates, pre-validated by the fact that someone bothered to do them manually.
LiveThe five-question use-case filter5 min▶
Not every copy-paste hop deserves a server. Run each candidate through five questions - a yes to all five is a green light, and the first no tells you exactly what to fix before you proceed.
- 1 · Is it repeated? A hop done once a quarter is not worth a server. A hop done daily by many people is.
- 2 · Is the system reachable? Does it have an API or database an engineer could wrap? If it is a fax machine, MCP will not save you.
- 3 · Can it start read-only? The safest first server only reads. If your candidate demands writes on day one, the risk conversation from a4 gets larger.
- 4 · Is the blast radius acceptable? Same rings as a4 - read, write, irreversible. A read-only reporting hop is a fine first bet; a "let the AI issue refunds" hop is not where you start.
- 5 · Who owns the answer's correctness? If the AI gets it wrong, who notices and who is accountable? A win with no owner is a liability with a schedule.
Keep this to five questions on purpose. A filter people can hold in their heads gets run; a fifteen-point rubric gets skipped.
Daybreak finds its first server in a stand-up. The DTC coffee brand's founder kept pinging the data team the same question - "how did subscriptions do last week versus the promo?" An analyst would pull the number, paste it into chat, and field three follow-ups the same way. That is the tell: a daily, repeated, read-only hop between a person's AI assistant and the sales database, with a clear owner (the data team). It passed all five questions, so the data team shipped a small Daybreak MCP server in a week. Now the founder's assistant answers sales questions directly - and the analyst got their mornings back.
Connector strategy: buy, build, or become 12 min live
Once you have a candidate, you have a posture decision - and there are exactly three. You can consume a public server someone else maintains, commission an internal server your team builds, or expose your own product as a server the world connects to. The first two are operational choices a director can make. The third is a product and go-to-market decision that belongs on the executive agenda - because if your customers can plug your product into their AI as easily as any other server, that is either a moat or a bypass, depending on who moves first.
LiveConsume and commission - the operational two4 min▶
Consume is the fastest path to value: a maintained public server (from the registry you met in a3) plugs into your AI app today. The cost is trust - you inherit someone else's update schedule and tool descriptions, which is exactly the a4 review discipline in action. Commission is the workhorse: your team wraps your own systems in a server, so your domain logic and access rules are yours. The cost is that you now own a piece of software - build, maintain, and re-review it like any other internal service.
- Consume when: the capability is generic (a public data source, a well-known SaaS) and a trusted maintainer already exists.
- Commission when: the value is in your data or rules, or the blast radius means you want the credentials to stay in-house.
Self-studyExpose - when your product becomes a server4 min read▶
The third posture is the one that keeps CEOs up. If your product exposes an MCP server, any customer can wire it into their AI in an afternoon - no integration project, no partnership deal. That cuts both ways. Done first, it makes you the default node in your customers' AI stack, the thing their assistants already know how to call. Done late, a competitor becomes that node and your product is the one requiring the awkward custom integration.
- The upside: distribution. Every AI app that adopts MCP is a potential new surface for your product, with no per-integration engineering.
- The question it forces: what does "our product, callable by any AI" do to our pricing, our support model, and our competitive position? That is a board conversation, not a backlog ticket.
- Why it is here, not in the builder track: the engineering is the easy part. The strategy - whether and how to open this door - is the hard part, and it is yours.
ROI framing for the board 10 min live
Here is the framing that lands. A server build costs roughly what a small internal API project costs - a known, bounded number your engineering leaders can estimate in their sleep. The benefit is the part boards miss: because MCP is one standard, every AI app you run gains the new capability at once, and every future AI app inherits it for free. You are not buying one integration; you are buying a socket that all your current and future AI tools plug into. The metric that captures this is integration lead-time - how long from "we want the AI to reach this system" to "it can, safely." MCP takes that from a quarter-long project to a config change.
LiveThe one-slide business case4 min▶
Boards fund clarity, not enthusiasm. Put the whole case on one slide with four lines - if it needs a second slide, you have not decided yet.
| Line | What goes here |
|---|---|
| The hop | The specific repeated manual step you are removing - who does it, how often. |
| The cost | One server build, priced like a small API project. A bounded, one-time number. |
| The payoff | The metric: integration lead-time drops from a quarter to a config change, for every AI app - now and future. |
| The guardrail | Which blast-radius ring it starts in (read-only first) and who signs off - straight from a4. |
Notice the case does not promise "AI transformation." It promises one removed hop, a known cost, a lead-time metric, and a safety posture. That is a decision a board can make in the room.
Run the use-case scan on one department ★ 8 min · pick a real team
Pick one department you know well - the one whose work you could describe in a sentence. You are going to find its first MCP candidate live, the same way Daybreak's data team found theirs in a stand-up.
Name the AI apps that department already uses - even informally. If the answer is "people paste things into a chatbot," that counts, and it is where the hops hide.
List three moments someone copies data out of a system into an AI app, or pastes an AI answer back into a system. These are your raw candidates.
Run each through the five-question filter: repeated, reachable, read-only-capable, acceptable blast radius, clear owner.
Keep only the ones that pass all five. Circle the most repeated, lowest-risk survivor - that is your first server, not the flashiest one.
Write its one-sentence owner: "the ___ team owns whether this answer is correct." No owner, no build.
Draft the one-slide case ★ 7 min · fill the four lines
Take the candidate you just circled and turn it into the slide you would actually present. Four lines, no more. Below the steps is a model answer built from the Daybreak example so you can check your shape.
The hop: write the exact manual step in one sentence - who, what system, how often.
The cost: ask your engineering lead for a rough server-build estimate framed as "a small API project." Put that number down.
The payoff: state the lead-time change and name every AI app that gains the capability the day the server ships.
The guardrail: name the starting ring (read-only) and the single person who signs off. Now you have a slide.
Self-studyModel answer - Daybreak's one-slide case3 min read▶
| Line | Daybreak's answer |
|---|---|
| The hop | The founder asks sales questions daily; an analyst manually pulls the number and pastes it into chat, then fields follow-ups the same way. |
| The cost | One read-only server over the sales database - roughly a one-week small-API build for the existing data team. |
| The payoff | Lead-time to "the assistant answers sales questions" drops from a recurring analyst task to instant; the founder's assistant, and any future internal AI app, gains it at once. |
| The guardrail | Read ring only - no writes. Data team lead signs off; no customer data leaves the system. |
One slide, one week, one owner. That is the shape a board approves - and the shape a6 will show you how to defend as the spec evolves.
Questions to ask your teams this week ◐ 20 min total
- Ask each department head: "where do your people copy data by hand between an AI app and one of our systems?" Collect the hops - the list is the pipeline.
- Ask your engineering lead: "what would a small read-only MCP server over our most-asked-about system cost, roughly, in weeks?" You want the order of magnitude, not a quote.
- Ask your product lead the uncomfortable one: "if our product exposed an MCP server, who would connect it - and what would a competitor doing it first cost us?" Even a rough answer tells you whether expose belongs on next quarter's agenda.
- Pick the single strongest candidate from the scan and sketch its one-slide case yourself, so you can pressure-test your teams' versions later.
Official sources covered
This session turns the platform and configuration documentation into strategy. The wiring itself - the connector API, the scope files - is builder-track material; the pages below are where your teams go for the mechanics.
Three questions before you go 🎯 ◐ 90 seconds
1 · The most reliable sign of an MCP-shaped opportunity is...
A manual hop is a candidate someone has already validated by bothering to do it. The server just removes the human-as-API step, under your rules.
2 · Exposing your own product as an MCP server is primarily...
The engineering is the easy part. Whether customers can plug your product into any AI - a moat if you move first, a bypass if you move late - is strategy, and it is yours.
3 · The metric that best captures MCP's payoff on a board slide is...
One server build costs like a small API project, but the capability lands for every current and future AI app at once. Lead-time is what that saving looks like on a slide.