The Architect's Guide to MCP: Building the Connectivity Layer for Microsoft AI Agents

1
00:00:00,000 --> 00:00:02,220
Your AI agents weren't designed for connectivity.

2
00:00:02,220 --> 00:00:06,260
They were designed for reasoning, models, prompts, token windows.

3
00:00:06,260 --> 00:00:09,040
And the assumption that the data would somehow find its way to them,

4
00:00:09,040 --> 00:00:10,680
that assumption is broken.

5
00:00:10,680 --> 00:00:12,840
Because agentic work doesn't start with reasoning.

6
00:00:12,840 --> 00:00:14,440
It starts with the connection.

7
00:00:14,440 --> 00:00:16,640
And the protocol that builds that connection

8
00:00:16,640 --> 00:00:21,760
is already inside Microsoft co-pilot studio, Azure and Dynamics 365.

9
00:00:21,760 --> 00:00:24,040
This is the Architects guide to MCP.

10
00:00:24,040 --> 00:00:25,360
The connectivity crisis.

11
00:00:25,360 --> 00:00:27,520
Every organization is running AI pilots now.

12
00:00:27,520 --> 00:00:28,600
Co-pilot is licensed.

13
00:00:28,600 --> 00:00:29,800
Agents are deployed.

14
00:00:29,800 --> 00:00:31,720
And the demos look great in the boardroom.

15
00:00:31,720 --> 00:00:34,200
But in reality, something is missing.

16
00:00:34,200 --> 00:00:35,160
The model can reason.

17
00:00:35,160 --> 00:00:36,200
It can draft emails.

18
00:00:36,200 --> 00:00:37,280
It can summarize meetings.

19
00:00:37,280 --> 00:00:38,320
It can write code.

20
00:00:38,320 --> 00:00:40,960
But when you ask it to check inventory against your ERP

21
00:00:40,960 --> 00:00:43,960
or route an approval through your custom workflow or pull context

22
00:00:43,960 --> 00:00:46,960
from three different systems at once, it hits a wall.

23
00:00:46,960 --> 00:00:49,120
Not because the model isn't smart enough,

24
00:00:49,120 --> 00:00:50,960
but because the connection doesn't exist.

25
00:00:50,960 --> 00:00:54,080
And here's where most architects miss the structural problem.

26
00:00:54,080 --> 00:00:56,200
The issue isn't that Microsoft lacks APIs.

27
00:00:56,200 --> 00:00:57,800
Microsoft Graph is extensive.

28
00:00:57,800 --> 00:01:00,520
Power Platform has connectors for hundreds of systems.

29
00:01:00,520 --> 00:01:02,760
Azure has every integration pattern you could want.

30
00:01:02,760 --> 00:01:04,680
The problem is that none of these were built for agents.

31
00:01:04,680 --> 00:01:05,720
They were built for humans.

32
00:01:05,720 --> 00:01:08,120
A human opens SharePoint, navigates to a folder,

33
00:01:08,120 --> 00:01:09,760
finds a document and reads it.

34
00:01:09,760 --> 00:01:11,880
An API call retrieves the same document.

35
00:01:11,880 --> 00:01:13,400
But an agent doesn't browse.

36
00:01:13,400 --> 00:01:14,440
It doesn't navigate.

37
00:01:14,440 --> 00:01:15,320
It reasons.

38
00:01:15,320 --> 00:01:18,760
It needs to discover what it can do, understand the parameters,

39
00:01:18,760 --> 00:01:21,520
invoke a capability, and receive a structured response

40
00:01:21,520 --> 00:01:24,320
it can use in its next reasoning step.

41
00:01:24,320 --> 00:01:26,720
Traditional APIs don't provide that contract.

42
00:01:26,720 --> 00:01:28,640
Custom connectors and power platform come close,

43
00:01:28,640 --> 00:01:30,360
but they break on schema changes.

44
00:01:30,360 --> 00:01:33,200
They require manual configuration for every environment.

45
00:01:33,200 --> 00:01:35,760
And they were designed for power apps and power automate,

46
00:01:35,760 --> 00:01:37,280
not for large language models

47
00:01:37,280 --> 00:01:39,560
that need to discover capabilities dynamically.

48
00:01:39,560 --> 00:01:41,280
Direct API calls are even worse.

49
00:01:41,280 --> 00:01:43,000
Every integration is bespoke.

50
00:01:43,000 --> 00:01:44,680
Every auth mechanism is different.

51
00:01:44,680 --> 00:01:46,440
Every payload format is custom.

52
00:01:46,440 --> 00:01:49,160
And when your API version changes your agent break silently

53
00:01:49,160 --> 00:01:51,200
because there's no capability negotiation,

54
00:01:51,200 --> 00:01:53,360
no handshake, no standard contract.

55
00:01:53,360 --> 00:01:56,080
So what's actually happening in most organizations is this.

56
00:01:56,080 --> 00:01:57,840
The AI team builds a beautiful agent

57
00:01:57,840 --> 00:01:59,680
that can reason about customer data.

58
00:01:59,680 --> 00:02:01,640
Then they spend six months writing brittle wrapper code

59
00:02:01,640 --> 00:02:03,920
to connect it to the CRM, then the CRM upgrades,

60
00:02:03,920 --> 00:02:05,000
the wrapper breaks.

61
00:02:05,000 --> 00:02:06,280
The agent starts hallucinating

62
00:02:06,280 --> 00:02:08,600
because it's receiving responses it no longer understands.

63
00:02:08,600 --> 00:02:09,920
This isn't a model problem.

64
00:02:09,920 --> 00:02:11,840
It's an integration architecture problem.

65
00:02:11,840 --> 00:02:14,200
And it's costing organizations more than they realize.

66
00:02:14,200 --> 00:02:17,440
Every brittle integration is technical debt that compounds.

67
00:02:17,440 --> 00:02:19,280
Every schema change requires rework.

68
00:02:19,280 --> 00:02:22,160
Every new data source requires another custom wrapper.

69
00:02:22,160 --> 00:02:24,600
And the agents themselves are reasoning on stale context

70
00:02:24,600 --> 00:02:27,280
because nobody built the bridge to keep their knowledge current.

71
00:02:27,280 --> 00:02:29,560
The organizations that are winning with AI right now

72
00:02:29,560 --> 00:02:31,560
aren't the ones with the best models.

73
00:02:31,560 --> 00:02:33,760
They are the ones with the best connectivity layer.

74
00:02:33,760 --> 00:02:35,840
The ones that figured out that an agent is only as good

75
00:02:35,840 --> 00:02:37,400
as the systems it can reach.

76
00:02:37,400 --> 00:02:39,040
And until now, there was no standard way

77
00:02:39,040 --> 00:02:41,360
to build that layer in a Microsoft environment.

78
00:02:41,360 --> 00:02:44,160
That's where MCP changes the structural assumption.

79
00:02:44,160 --> 00:02:45,240
What is MCP?

80
00:02:45,240 --> 00:02:47,120
The protocol that changes everything.

81
00:02:47,120 --> 00:02:49,600
MCP stands for model context protocol.

82
00:02:49,600 --> 00:02:51,240
It was originally developed by Anthropic

83
00:02:51,240 --> 00:02:53,600
as an open standard for connecting AI assistance

84
00:02:53,600 --> 00:02:56,240
to data sources, tools, and external systems.

85
00:02:56,240 --> 00:02:58,200
But what started as one company's experiment

86
00:02:58,200 --> 00:02:59,760
has become the connectivity backbone

87
00:02:59,760 --> 00:03:01,760
that the entire industry is converging on.

88
00:03:01,760 --> 00:03:03,160
And Microsoft isn't just adopting it,

89
00:03:03,160 --> 00:03:06,000
Microsoft is baking it into every layer of their stack.

90
00:03:06,000 --> 00:03:07,760
So what is MCP structurally?

91
00:03:07,760 --> 00:03:10,760
At its core, MCP is a JSON RPC 2.0 protocol

92
00:03:10,760 --> 00:03:13,720
that means it uses a standard remote procedure core format

93
00:03:13,720 --> 00:03:15,480
where a client sends a structured request

94
00:03:15,480 --> 00:03:17,880
and a server returns a structured response.

95
00:03:17,880 --> 00:03:21,080
But MCP adds something critical on top of that foundation.

96
00:03:21,080 --> 00:03:22,360
It adds discovery.

97
00:03:22,360 --> 00:03:24,640
An MCP server doesn't just expose endpoints,

98
00:03:24,640 --> 00:03:26,280
it exposes capabilities.

99
00:03:26,280 --> 00:03:28,560
When an MCP client connects to a server,

100
00:03:28,560 --> 00:03:30,520
they perform an initialization handshake.

101
00:03:30,520 --> 00:03:32,360
The server announces what tools it offers,

102
00:03:32,360 --> 00:03:35,520
what resources it can provide, and what prompts it supports.

103
00:03:35,520 --> 00:03:38,000
The client announces what it can handle in return.

104
00:03:38,000 --> 00:03:39,640
And only after this negotiation,

105
00:03:39,640 --> 00:03:41,080
do they start working together.

106
00:03:41,080 --> 00:03:42,880
This changes everything.

107
00:03:42,880 --> 00:03:44,760
In a traditional API integration,

108
00:03:44,760 --> 00:03:47,320
the client needs to know the API surface in advance.

109
00:03:47,320 --> 00:03:49,280
You write code against a swagger document.

110
00:03:49,280 --> 00:03:50,960
You handle version changes manually.

111
00:03:50,960 --> 00:03:52,520
You hard-code endpoint paths.

112
00:03:52,520 --> 00:03:55,640
With MCP, the client discovers the surface dynamically.

113
00:03:55,640 --> 00:03:58,280
The agent asks the server, "What can you do?"

114
00:03:58,280 --> 00:04:00,400
The server replies with a typed catalog.

115
00:04:00,400 --> 00:04:03,080
The agent then selects a tool, provides the parameters,

116
00:04:03,080 --> 00:04:04,920
and receives a structured response.

117
00:04:04,920 --> 00:04:07,120
This means your agent can adapt to new capabilities

118
00:04:07,120 --> 00:04:08,360
without code changes.

119
00:04:08,360 --> 00:04:10,520
When you add a new tool to your MCP server,

120
00:04:10,520 --> 00:04:13,640
every connected agent sees it immediately after reconnection.

121
00:04:13,640 --> 00:04:15,640
There is no deployment cycle on the client side,

122
00:04:15,640 --> 00:04:18,000
no version pinning, no breaking changes.

123
00:04:19,320 --> 00:04:22,320
MCP defines four core primitives that make this possible.

124
00:04:22,320 --> 00:04:24,600
Tools are callable functions exposed by the server.

125
00:04:24,600 --> 00:04:26,040
Each tool has a name, a description,

126
00:04:26,040 --> 00:04:27,600
and a typed parameter schema.

127
00:04:27,600 --> 00:04:30,800
The agent reads the description, understands what the tool does,

128
00:04:30,800 --> 00:04:32,360
and decides whether to invoke it.

129
00:04:32,360 --> 00:04:34,360
This is how an agent triggers a workflow,

130
00:04:34,360 --> 00:04:36,680
queries a database, or updates a record.

131
00:04:36,680 --> 00:04:39,720
Resources are read only data sources addressed by URI.

132
00:04:39,720 --> 00:04:41,880
Think of them as files, documents, or reference data

133
00:04:41,880 --> 00:04:44,200
that the agent can pull when it needs context.

134
00:04:44,200 --> 00:04:46,320
A resource might be a SharePoint document,

135
00:04:46,320 --> 00:04:48,920
a product catalog, or a policy manual.

136
00:04:48,920 --> 00:04:51,000
Prompts are templated instructions that the server

137
00:04:51,000 --> 00:04:52,400
can offer to the client.

138
00:04:52,400 --> 00:04:54,320
They're not prompts in the sense of a chat message.

139
00:04:54,320 --> 00:04:56,880
They're reusable patterns that help the agent structure

140
00:04:56,880 --> 00:04:57,800
its reasoning.

141
00:04:57,800 --> 00:05:00,320
A server might offer a prompt for summarizing financial data

142
00:05:00,320 --> 00:05:03,320
in a specific format, or for drafting compliance reports

143
00:05:03,320 --> 00:05:04,760
using company templates.

144
00:05:04,760 --> 00:05:06,400
Sampling is the inverse relationship.

145
00:05:06,400 --> 00:05:08,400
When the server needs the client to generate content,

146
00:05:08,400 --> 00:05:09,840
it can request a sample.

147
00:05:09,840 --> 00:05:12,400
This allows the server to use the AI model's reasoning

148
00:05:12,400 --> 00:05:15,080
capabilities without hosting its own model.

149
00:05:15,080 --> 00:05:18,040
It's a subtle but powerful patent for distributed intelligence.

150
00:05:18,040 --> 00:05:19,640
Together, these four primitives create

151
00:05:19,640 --> 00:05:22,360
a complete contract between an agent and the systems

152
00:05:22,360 --> 00:05:23,760
it needs to interact with.

153
00:05:23,760 --> 00:05:26,280
But why JSON, RPC 2.0 specifically?

154
00:05:26,280 --> 00:05:27,800
The protocol architects had a choice.

155
00:05:27,800 --> 00:05:29,600
They could have built MCP on rest.

156
00:05:29,600 --> 00:05:30,760
Rest is familiar.

157
00:05:30,760 --> 00:05:31,840
Every developer knows it.

158
00:05:31,840 --> 00:05:33,280
Every framework supports it.

159
00:05:33,280 --> 00:05:35,600
And it works well for human-facing web applications.

160
00:05:35,600 --> 00:05:38,280
But rest isn't designed for machine-to-machine reasoning.

161
00:05:38,280 --> 00:05:40,480
A rest API exposes resources at URLs.

162
00:05:40,480 --> 00:05:43,240
A client performs, get, post, put, and delete operations

163
00:05:43,240 --> 00:05:44,200
on those URLs.

164
00:05:44,200 --> 00:05:46,560
The client needs to know the URL structure in advance.

165
00:05:46,560 --> 00:05:49,120
It needs to understand the HTTP status codes.

166
00:05:49,120 --> 00:05:51,880
And it needs to pass the response body to extract meaning.

167
00:05:51,880 --> 00:05:53,560
JSON, RPC 2.0 is different.

168
00:05:53,560 --> 00:05:55,040
It's a message-based protocol.

169
00:05:55,040 --> 00:05:57,680
The client sends a message with a method name and parameters.

170
00:05:57,680 --> 00:05:59,880
The server executes the method and returns a result.

171
00:05:59,880 --> 00:06:01,520
There's no URL structure to learn.

172
00:06:01,520 --> 00:06:02,920
No HTTP verbs to map.

173
00:06:02,920 --> 00:06:04,960
No status code semantics to interpret.

174
00:06:04,960 --> 00:06:07,840
This matters for AI agents, because agents don't browse.

175
00:06:07,840 --> 00:06:09,560
They reason.

176
00:06:09,560 --> 00:06:11,520
An agent looking at a rest API needs

177
00:06:11,520 --> 00:06:14,440
to understand that get means read, post means create,

178
00:06:14,440 --> 00:06:15,680
and delete means remove.

179
00:06:15,680 --> 00:06:18,480
It needs to know that a 404 status means not found,

180
00:06:18,480 --> 00:06:21,200
and a 500 status means server error.

181
00:06:21,200 --> 00:06:23,160
It needs to construct URLs by concatenating

182
00:06:23,160 --> 00:06:25,120
path segments and query parameters.

183
00:06:25,120 --> 00:06:28,400
An agent looking at a JSON RPC API needs to understand one thing.

184
00:06:28,400 --> 00:06:29,280
The method name.

185
00:06:29,280 --> 00:06:32,120
The method name tells the agent what capability is available.

186
00:06:32,120 --> 00:06:35,120
The parameter schema tells the agent what inputs are required.

187
00:06:35,120 --> 00:06:38,480
And the response schema tells the agent what outputs it will receive.

188
00:06:38,480 --> 00:06:40,040
This is a much simpler reasoning surface.

189
00:06:40,040 --> 00:06:43,440
And that's why MCP chose JSON RPC 2.0, not because it's

190
00:06:43,440 --> 00:06:45,480
newer or better than rest in general.

191
00:06:45,480 --> 00:06:47,360
But because it's better for agents that need to discover

192
00:06:47,360 --> 00:06:49,200
capabilities dynamically and invoke them

193
00:06:49,200 --> 00:06:52,280
without understanding the underlying HTTP semantics,

194
00:06:52,280 --> 00:06:54,880
the protocol also supports batch requests.

195
00:06:54,880 --> 00:06:58,400
A client can send multiple JSON RPC messages in a single payload.

196
00:06:58,400 --> 00:07:01,480
The server processes them and returns a batch of responses.

197
00:07:01,480 --> 00:07:03,280
This is efficient for agents that need to invoke

198
00:07:03,280 --> 00:07:05,840
multiple tools to answer a single user query.

199
00:07:05,840 --> 00:07:07,960
And here's why this matters in a Microsoft environment

200
00:07:07,960 --> 00:07:08,760
specifically.

201
00:07:08,760 --> 00:07:10,640
Your organization already has the data.

202
00:07:10,640 --> 00:07:11,400
It's in SharePoint.

203
00:07:11,400 --> 00:07:12,160
It's in OneDrive.

204
00:07:12,160 --> 00:07:13,480
It's in Teams Conversations.

205
00:07:13,480 --> 00:07:14,880
It's in Dynamics 365.

206
00:07:14,880 --> 00:07:16,840
It's in SQL databases running on Azure.

207
00:07:16,840 --> 00:07:19,080
It's in Custom Line of Business applications

208
00:07:19,080 --> 00:07:21,280
that your teams built over the last decade.

209
00:07:21,280 --> 00:07:24,200
What you don't have is a standardized way for AI agents

210
00:07:24,200 --> 00:07:26,960
to discover, access, and reason over all of that data

211
00:07:26,960 --> 00:07:30,040
without writing bespoke integration code for every source.

212
00:07:30,040 --> 00:07:31,880
MCP doesn't replace Microsoft Graph.

213
00:07:31,880 --> 00:07:33,360
It doesn't replace your REST APIs.

214
00:07:33,360 --> 00:07:35,200
It doesn't replace your custom connectors.

215
00:07:35,200 --> 00:07:36,120
It sits above them.

216
00:07:36,120 --> 00:07:38,000
MCP is the translation layer.

217
00:07:38,000 --> 00:07:40,080
The normalization layer, the protocol that

218
00:07:40,080 --> 00:07:43,320
turns your heterogeneous backend systems into a uniform surface

219
00:07:43,320 --> 00:07:45,160
that any agent can understand.

220
00:07:45,160 --> 00:07:47,000
An MCP server for SharePoint doesn't just

221
00:07:47,000 --> 00:07:48,520
wrap graph API calls.

222
00:07:48,520 --> 00:07:52,040
It exposes tools like find documents related to this project

223
00:07:52,040 --> 00:07:54,040
with parameters the agent can reason about.

224
00:07:54,040 --> 00:07:56,520
It exposes resources like the current project charter

225
00:07:56,520 --> 00:07:57,760
addressed by URI.

226
00:07:57,760 --> 00:07:59,960
It exposes prompts like summarise this document

227
00:07:59,960 --> 00:08:01,760
using our executive summary format.

228
00:08:01,760 --> 00:08:04,160
The agent doesn't need to know how SharePoint works.

229
00:08:04,160 --> 00:08:06,600
It just needs to know what the MCP server can do.

230
00:08:06,600 --> 00:08:09,200
And one level deeper, this is where the real shift happens.

231
00:08:09,200 --> 00:08:12,440
Because once you have an MCP server, any agent can use it.

232
00:08:12,440 --> 00:08:14,600
Not just co-pilot, not just your custom chatbot.

233
00:08:14,600 --> 00:08:16,400
Any agent that speaks MCP.

234
00:08:16,400 --> 00:08:19,280
That means the investment you make in building an MCP server

235
00:08:19,280 --> 00:08:22,120
for your ERP pays off across every AI initiative

236
00:08:22,120 --> 00:08:22,960
in your organization.

237
00:08:22,960 --> 00:08:25,160
That's the structural change.

238
00:08:25,160 --> 00:08:28,320
That's why this isn't just another integration pattern.

239
00:08:28,320 --> 00:08:31,240
The Microsoft MCP ecosystem, a landscape overview.

240
00:08:31,240 --> 00:08:34,080
Microsoft didn't just add MCP support as an afterthought.

241
00:08:34,080 --> 00:08:35,960
They built it into the architecture.

242
00:08:35,960 --> 00:08:37,720
Let's walk through where MCP shows up

243
00:08:37,720 --> 00:08:39,400
across the Microsoft ecosystem right now,

244
00:08:39,400 --> 00:08:42,400
because the breadth is wider than most architects realise.

245
00:08:42,400 --> 00:08:45,880
Microsoft co-pilot studio added model context protocol support

246
00:08:45,880 --> 00:08:48,480
and took it to general availability in March, 2026.

247
00:08:48,480 --> 00:08:49,840
This isn't a preview feature anymore.

248
00:08:49,840 --> 00:08:51,320
It's production ready.

249
00:08:51,320 --> 00:08:54,080
And the GA release included tool listing capabilities,

250
00:08:54,080 --> 00:08:57,560
enhanced tracing for debugging, agent to server communication,

251
00:08:57,560 --> 00:09:00,120
and infrastructure for scalable deployments.

252
00:09:00,120 --> 00:09:02,480
What this means practically is that any agent you build

253
00:09:02,480 --> 00:09:06,000
in co-pilot studio can now connect to external MCP servers

254
00:09:06,000 --> 00:09:09,000
as natively as it connects to Microsoft Graph or Dataverse.

255
00:09:09,000 --> 00:09:11,000
The tools exposed by your MCP servers

256
00:09:11,000 --> 00:09:13,040
appear in the agent's tool catalog.

257
00:09:13,040 --> 00:09:15,520
The agent discovers them during initialisation.

258
00:09:15,520 --> 00:09:17,640
And it invokes them through the same reasoning pipeline

259
00:09:17,640 --> 00:09:19,240
that handles built in Microsoft tools.

260
00:09:19,240 --> 00:09:21,760
Microsoft also published a model context protocol lab

261
00:09:21,760 --> 00:09:23,800
on GitHub in April 2025.

262
00:09:23,800 --> 00:09:25,880
This is a collection of templates, sample servers,

263
00:09:25,880 --> 00:09:27,600
and learning exercises specifically

264
00:09:27,600 --> 00:09:29,360
for co-pilot studio integration.

265
00:09:29,360 --> 00:09:30,600
If you're starting from zero,

266
00:09:30,600 --> 00:09:33,280
this is your fastest path to a working prototype.

267
00:09:33,280 --> 00:09:35,080
But co-pilot studio is just the start.

268
00:09:35,080 --> 00:09:37,520
Dynamics 365, finance and operations

269
00:09:37,520 --> 00:09:40,240
added MCP server support in April, 2026.

270
00:09:40,240 --> 00:09:42,520
You can now build and connect MCP servers

271
00:09:42,520 --> 00:09:45,160
that extend the capabilities of your ERP agents.

272
00:09:45,160 --> 00:09:47,840
That means your inventory agent doesn't just query stock levels.

273
00:09:47,840 --> 00:09:51,120
It can trigger reorder workflows, check supplier lead times,

274
00:09:51,120 --> 00:09:53,480
and update purchase orders through a standardized protocol

275
00:09:53,480 --> 00:09:54,160
surface.

276
00:09:54,160 --> 00:09:56,480
Visual Studio is shipping as your MCP tools

277
00:09:56,480 --> 00:10:00,760
inside both Visual Studio 2022 and Visual Studio 2026.

278
00:10:00,760 --> 00:10:03,280
Developers can connect their IDE to MCP servers

279
00:10:03,280 --> 00:10:05,440
for code context, documentation retrieval,

280
00:10:05,440 --> 00:10:06,720
and even build automation.

281
00:10:06,720 --> 00:10:09,080
The same protocol that connects your business agents

282
00:10:09,080 --> 00:10:10,960
is now connecting your development environment.

283
00:10:10,960 --> 00:10:13,880
And all of this is underpinned by the official CR SDK.

284
00:10:13,880 --> 00:10:17,360
Microsoft released version 1.0 of the official MCP CR SDK

285
00:10:17,360 --> 00:10:18,560
in March, 2026.

286
00:10:18,560 --> 00:10:19,920
This isn't a community project.

287
00:10:19,920 --> 00:10:21,840
It's maintained on GitHub in collaboration

288
00:10:21,840 --> 00:10:23,240
with the core MCP team.

289
00:10:23,240 --> 00:10:26,320
It's available on NewGET as the model context protocol package,

290
00:10:26,320 --> 00:10:30,560
version 1.4, zero as of late March, 2026.

291
00:10:30,560 --> 00:10:34,840
Version 1.0 supports the 2025-1125 MCP specification.

292
00:10:34,840 --> 00:10:37,760
It includes hosting extensions, dependency injection support,

293
00:10:37,760 --> 00:10:41,480
enhanced authorization flows, icon support for tools and resources,

294
00:10:41,480 --> 00:10:43,840
richer metadata, tool calling enhancements,

295
00:10:43,840 --> 00:10:45,520
and long-running request handling.

296
00:10:45,520 --> 00:10:49,120
The SDK was updated in July 2025 to support protocol version

297
00:10:49,120 --> 00:10:52,520
2025-0618, which brought structured tool output,

298
00:10:52,520 --> 00:10:55,160
illicitation support, and enhanced security features.

299
00:10:55,160 --> 00:10:58,160
If you haven't looked at the SDK since early 2025,

300
00:10:58,160 --> 00:10:59,920
it's a completely different animal now.

301
00:10:59,920 --> 00:11:01,400
But here's where things get really interesting

302
00:11:01,400 --> 00:11:03,160
from an architect's perspective.

303
00:11:03,160 --> 00:11:04,880
The transport layer is evolving.

304
00:11:04,880 --> 00:11:06,880
MCP started with SDDO transport,

305
00:11:06,880 --> 00:11:08,280
standard input and output.

306
00:11:08,280 --> 00:11:10,120
This is perfect for local development.

307
00:11:10,120 --> 00:11:12,520
Your MCP server runs as a local process.

308
00:11:12,520 --> 00:11:14,440
The agent talks to it through pipes.

309
00:11:14,440 --> 00:11:17,960
It's simple, fast, and requires no network configuration.

310
00:11:17,960 --> 00:11:20,760
Then MCP added server-cent events for remote connections.

311
00:11:20,760 --> 00:11:22,600
SSI allowed a server to push updates

312
00:11:22,600 --> 00:11:24,560
to a client over an HTTP connection.

313
00:11:24,560 --> 00:11:25,680
It worked.

314
00:11:25,680 --> 00:11:27,680
But it had problems with authentication,

315
00:11:27,680 --> 00:11:30,640
cores, policies, and enterprise firewall configurations.

316
00:11:30,640 --> 00:11:33,360
So the MCP specification deprecated SSI

317
00:11:33,360 --> 00:11:35,720
and replaced it with streamable HTTP.

318
00:11:35,720 --> 00:11:39,920
Streamable HTTP uses standard HTTP posts and get requests.

319
00:11:39,920 --> 00:11:41,640
It supports optional server-cent events

320
00:11:41,640 --> 00:11:43,640
for server-to-client streaming where needed.

321
00:11:43,640 --> 00:11:46,320
But the core communication is plain HTTP.

322
00:11:46,320 --> 00:11:48,400
And that means it works with standard load balancers,

323
00:11:48,400 --> 00:11:51,800
standard firewalls, and standard authentication mechanisms.

324
00:11:51,800 --> 00:11:54,080
For Microsoft environments, this is critical.

325
00:11:54,080 --> 00:11:57,280
Because streamable HTTP integrates with Microsoft Entra.

326
00:11:57,280 --> 00:11:59,240
It works behind Azure API management.

327
00:11:59,240 --> 00:12:00,520
It scales on Azure functions.

328
00:12:00,520 --> 00:12:01,960
It doesn't require web socket support

329
00:12:01,960 --> 00:12:03,560
or custom proxy configurations.

330
00:12:03,560 --> 00:12:05,320
We'll dig into transports in details soon.

331
00:12:05,320 --> 00:12:07,480
But the main point is this, Microsoft isn't just

332
00:12:07,480 --> 00:12:08,920
supporting MCP as a protocol.

333
00:12:08,920 --> 00:12:10,960
They're optimizing their entire cloud platform

334
00:12:10,960 --> 00:12:12,320
for MCP deployments.

335
00:12:12,320 --> 00:12:13,720
Then there's the governance layer.

336
00:12:13,720 --> 00:12:17,360
Microsoft Entra.Agent.ID launched in early 2026.

337
00:12:17,360 --> 00:12:19,640
It's an identity and security framework specifically

338
00:12:19,640 --> 00:12:20,680
for AI agents.

339
00:12:20,680 --> 00:12:22,720
It lets you build, discover, govern, and protect

340
00:12:22,720 --> 00:12:24,960
agent identities at enterprise scale.

341
00:12:24,960 --> 00:12:28,200
And in May, 2026, Microsoft added conditional access

342
00:12:28,200 --> 00:12:30,600
for agents, extending zero trust principles

343
00:12:30,600 --> 00:12:31,960
to non-human identities.

344
00:12:31,960 --> 00:12:34,760
Microsoft agent 365 is the control plane.

345
00:12:34,760 --> 00:12:37,520
Observe, govern, and secure AI agents

346
00:12:37,520 --> 00:12:40,800
using the same Microsoft 365 and Microsoft security controls

347
00:12:40,800 --> 00:12:41,720
you already have.

348
00:12:41,720 --> 00:12:42,960
And there's Work IQ.

349
00:12:42,960 --> 00:12:44,680
Work IQ is the intelligence layer

350
00:12:44,680 --> 00:12:47,200
that personalizes Microsoft 365 co-pilot

351
00:12:47,200 --> 00:12:50,240
and your custom agents with real time, shared context

352
00:12:50,240 --> 00:12:51,680
across your organization.

353
00:12:51,680 --> 00:12:55,280
It pulls from SharePoint, OneDrive, Teams, email, and meetings.

354
00:12:55,280 --> 00:12:58,680
And Microsoft open sourced a Work IQ MCP server on GitHub.

355
00:12:58,680 --> 00:13:00,720
Finally, there's the agent to agent protocol

356
00:13:00,720 --> 00:13:03,040
Google launched A2A in April 2025.

357
00:13:03,040 --> 00:13:05,600
Microsoft announced support in May 2025.

358
00:13:05,600 --> 00:13:09,400
And in June 2025, Google donated A2A to the Linux Foundation

359
00:13:09,400 --> 00:13:12,120
with founding members, including AWS and Cisco.

360
00:13:12,120 --> 00:13:14,080
A2A isn't a competitor to MCP.

361
00:13:14,080 --> 00:13:15,280
It solves a different problem.

362
00:13:15,280 --> 00:13:16,800
MCP connects agents to tools.

363
00:13:16,800 --> 00:13:18,800
A2A connects agents to other agents.

364
00:13:18,800 --> 00:13:19,640
You need both.

365
00:13:19,640 --> 00:13:20,960
So the landscape looks like this.

366
00:13:20,960 --> 00:13:23,240
At the bottom, you have your data and systems.

367
00:13:23,240 --> 00:13:28,640
SharePoint, Dynamics, SQL databases, custom applications.

368
00:13:28,640 --> 00:13:31,480
Above that, MCP servers expose capabilities

369
00:13:31,480 --> 00:13:33,000
through a standardized protocol.

370
00:13:33,000 --> 00:13:35,000
Work IQ adds organizational intelligence,

371
00:13:35,000 --> 00:13:38,320
intra agent ID and agent 365 secure the connections.

372
00:13:38,320 --> 00:13:41,360
Co-pilot studio and custom agents consume the capabilities.

373
00:13:41,360 --> 00:13:43,800
And A2A enables those agents to collaborate.

374
00:13:43,800 --> 00:13:45,360
This is the connectivity architecture

375
00:13:45,360 --> 00:13:46,800
Microsoft is building.

376
00:13:46,800 --> 00:13:48,440
And it's not a roadmap slide.

377
00:13:48,440 --> 00:13:49,440
It's shipping now.

378
00:13:49,440 --> 00:13:51,360
MCP architecture deep dive.

379
00:13:51,360 --> 00:13:53,360
Before you start building, you need to understand

380
00:13:53,360 --> 00:13:55,000
how MCP actually works under the hood,

381
00:13:55,000 --> 00:13:57,680
not the marketing description, the wire protocol.

382
00:13:57,680 --> 00:13:59,640
Because the architecture decisions you make here

383
00:13:59,640 --> 00:14:01,920
will determine whether your MCP deployment scales,

384
00:14:01,920 --> 00:14:04,200
whether it remains secure, and whether your agents

385
00:14:04,200 --> 00:14:06,760
can actually discover the capabilities they need.

386
00:14:06,760 --> 00:14:08,600
MCP runs on JSONRPC 2.0.

387
00:14:08,600 --> 00:14:10,160
If you've worked with remote procedure calls

388
00:14:10,160 --> 00:14:11,680
before, this will feel familiar.

389
00:14:11,680 --> 00:14:13,880
If you haven't, the concept is straightforward.

390
00:14:13,880 --> 00:14:16,600
A client sends a request with a method name and parameters.

391
00:14:16,600 --> 00:14:19,520
A server processes the request and returns a response.

392
00:14:19,520 --> 00:14:21,480
If something goes wrong, the server returns

393
00:14:21,480 --> 00:14:23,640
an error object with a code and a message.

394
00:14:23,640 --> 00:14:27,240
But MCP adds a critical layer on top of raw JSONRPC.

395
00:14:27,240 --> 00:14:29,160
It adds the initialization handshake.

396
00:14:29,160 --> 00:14:31,520
When an MCP client first connects to a server,

397
00:14:31,520 --> 00:14:33,560
they don't immediately start invoking tools.

398
00:14:33,560 --> 00:14:34,400
They negotiate.

399
00:14:34,400 --> 00:14:36,000
The client sends an initialized request

400
00:14:36,000 --> 00:14:38,520
with its protocol version that supported capabilities

401
00:14:38,520 --> 00:14:40,240
and its implementation details.

402
00:14:40,240 --> 00:14:41,960
The server responds with its protocol version

403
00:14:41,960 --> 00:14:44,360
its capabilities and its implementation details.

404
00:14:44,360 --> 00:14:46,640
Only after both sides agree on the contract,

405
00:14:46,640 --> 00:14:48,160
do they transition to the ready state

406
00:14:48,160 --> 00:14:49,640
and begin normal operation.

407
00:14:49,640 --> 00:14:51,720
This handshake is why MCP servers and clients

408
00:14:51,720 --> 00:14:53,320
can evolve independently.

409
00:14:53,320 --> 00:14:56,160
A server running protocol version 2025, 1125

410
00:14:56,160 --> 00:14:59,960
can talk to a client that supports version 2025, 0618.

411
00:14:59,960 --> 00:15:01,400
Then negotiate the common subset.

412
00:15:01,400 --> 00:15:03,920
If the server offers a feature, the client doesn't understand,

413
00:15:03,920 --> 00:15:05,320
the client simply ignores it.

414
00:15:05,320 --> 00:15:07,720
If the client requests a feature, the server doesn't support,

415
00:15:07,720 --> 00:15:09,120
the server returns a clear error.

416
00:15:09,120 --> 00:15:11,360
This is capability negotiation in practice.

417
00:15:11,360 --> 00:15:14,040
And it's fundamentally different from REST API versioning

418
00:15:14,040 --> 00:15:17,160
with REST, you typically version the entire API surface.

419
00:15:17,160 --> 00:15:18,720
V1, V2, V3.

420
00:15:18,720 --> 00:15:21,720
When V2 drops a field that V1 had, every client breaks

421
00:15:21,720 --> 00:15:23,120
unless it was already updated.

422
00:15:23,120 --> 00:15:25,200
With MCP capabilities are granular.

423
00:15:25,200 --> 00:15:27,040
The server advertises what it has.

424
00:15:27,040 --> 00:15:29,840
The client selects what it needs, changes are additive by default.

425
00:15:29,840 --> 00:15:31,760
Let's look at the four primitives in detail.

426
00:15:31,760 --> 00:15:34,200
Tools are the most commonly used primitive.

427
00:15:34,200 --> 00:15:36,680
A tool is a calibable function exposed by the server.

428
00:15:36,680 --> 00:15:39,160
The server defines the tool's name, provides a description

429
00:15:39,160 --> 00:15:41,320
that explains what the tool does, and specifies

430
00:15:41,320 --> 00:15:43,160
a JSON schema for the parameters.

431
00:15:43,160 --> 00:15:45,560
This schema is typed, it tells the client exactly

432
00:15:45,560 --> 00:15:48,200
what inputs the tool expects, what types they are,

433
00:15:48,200 --> 00:15:49,960
and which parameters are required.

434
00:15:49,960 --> 00:15:52,440
When an agent wants to use a tool, it doesn't just

435
00:15:52,440 --> 00:15:53,520
guess the parameters.

436
00:15:53,520 --> 00:15:54,560
It reads the schema.

437
00:15:54,560 --> 00:15:56,600
It reads about what values to provide,

438
00:15:56,600 --> 00:15:59,440
and it invokes the tool with a properly structured request.

439
00:15:59,440 --> 00:16:01,760
The server executes the tool and returns a result.

440
00:16:01,760 --> 00:16:04,920
Here's where the 2025 0618 protocol update

441
00:16:04,920 --> 00:16:06,440
changed things significantly.

442
00:16:06,440 --> 00:16:09,960
Before that update, tool results were typically simple strings.

443
00:16:09,960 --> 00:16:11,760
A tool might return a block of text,

444
00:16:11,760 --> 00:16:14,440
and the agent would pass that text to extract meaning.

445
00:16:14,440 --> 00:16:16,320
This was fragile.

446
00:16:16,320 --> 00:16:19,800
If the tool output format changed, the agent's passing logic broke.

447
00:16:19,800 --> 00:16:23,520
The 2025 0618 update introduced structured tool output.

448
00:16:23,520 --> 00:16:25,640
Now tools can return typed objects, arrays,

449
00:16:25,640 --> 00:16:27,160
and nested data structures.

450
00:16:27,160 --> 00:16:28,600
The agent receives a structured result.

451
00:16:28,600 --> 00:16:30,240
It can reason over directly.

452
00:16:30,240 --> 00:16:33,160
No passing, no rejects extraction, no brittle string

453
00:16:33,160 --> 00:16:34,160
manipulation.

454
00:16:34,160 --> 00:16:35,800
This matters for enterprise integrations

455
00:16:35,800 --> 00:16:37,440
because your business systems already

456
00:16:37,440 --> 00:16:39,200
return structured data.

457
00:16:39,200 --> 00:16:42,480
Acquery against your ERP returns records with typed fields,

458
00:16:42,480 --> 00:16:44,720
an inventory check returns quantities, locations,

459
00:16:44,720 --> 00:16:45,880
and status codes.

460
00:16:45,880 --> 00:16:48,840
With structured tool output, that data flows directly

461
00:16:48,840 --> 00:16:51,720
into the agent's reasoning pipeline in its native shape.

462
00:16:51,720 --> 00:16:53,520
Resources are the second primitive.

463
00:16:53,520 --> 00:16:54,960
Where tools are active operations,

464
00:16:54,960 --> 00:16:56,840
resources are passive data sources.

465
00:16:56,840 --> 00:16:59,720
A resource is addressed by a URI, just like a web page.

466
00:16:59,720 --> 00:17:01,960
The server defines what URIs it supports,

467
00:17:01,960 --> 00:17:03,360
and what content they return.

468
00:17:03,360 --> 00:17:05,760
When an agent needs context, it can request a resource

469
00:17:05,760 --> 00:17:06,680
by URI.

470
00:17:06,680 --> 00:17:09,040
The server returns the content, typically as text

471
00:17:09,040 --> 00:17:11,680
that the agent can embed into its reasoning context.

472
00:17:11,680 --> 00:17:13,840
This is how an agent reads a policy document,

473
00:17:13,840 --> 00:17:16,520
pulls a project charter, or retrieves a customer record.

474
00:17:16,520 --> 00:17:18,480
Resources are read only by design.

475
00:17:18,480 --> 00:17:21,240
If an agent needs to modify data, it uses a tool.

476
00:17:21,240 --> 00:17:24,200
This separation creates a clean architectural boundary.

477
00:17:24,200 --> 00:17:25,880
Resources provide context.

478
00:17:25,880 --> 00:17:27,640
Tools perform actions.

479
00:17:27,640 --> 00:17:30,200
Prompts are the third primitive, and they're often misunderstood.

480
00:17:30,200 --> 00:17:32,000
An MCP prompt is not a user message.

481
00:17:32,000 --> 00:17:33,640
It's a template that the server offers

482
00:17:33,640 --> 00:17:35,760
to help the client structure its reasoning.

483
00:17:35,760 --> 00:17:37,760
A server might expose a prompt for generator

484
00:17:37,760 --> 00:17:40,720
quarterly financial summary in the CFO's preferred format.

485
00:17:40,720 --> 00:17:43,280
The prompt includes the template structure, variable slots,

486
00:17:43,280 --> 00:17:45,040
and instructions for how to fill them.

487
00:17:45,040 --> 00:17:47,320
When an agent needs to perform a complex reasoning task,

488
00:17:47,320 --> 00:17:49,320
it can request a relevant prompt from the server.

489
00:17:49,320 --> 00:17:50,880
The server provides the template.

490
00:17:50,880 --> 00:17:52,520
The agent fills in the variables

491
00:17:52,520 --> 00:17:54,560
and uses the resulting structured instruction

492
00:17:54,560 --> 00:17:55,640
to guide its output.

493
00:17:55,640 --> 00:17:58,360
This is particularly valuable in Microsoft environments

494
00:17:58,360 --> 00:18:01,160
where organizations have standardized formats, compliance,

495
00:18:01,160 --> 00:18:03,120
templates, and brand guidelines.

496
00:18:03,120 --> 00:18:05,720
The MCP server encodes these standards as prompts,

497
00:18:05,720 --> 00:18:07,560
and every connected agent automatically

498
00:18:07,560 --> 00:18:09,360
produces output that follows them.

499
00:18:09,360 --> 00:18:11,200
Sampling is the fourth primitive, and it's

500
00:18:11,200 --> 00:18:12,880
the inverse of the other three.

501
00:18:12,880 --> 00:18:15,320
Sampling allows the server to request generative reasoning

502
00:18:15,320 --> 00:18:17,480
from the client when a server encounters a problem that

503
00:18:17,480 --> 00:18:19,920
requires AI reasoning instead of hosting

504
00:18:19,920 --> 00:18:22,920
its own model, it asks the client to generate a response.

505
00:18:22,920 --> 00:18:25,400
This creates a distributed intelligence pattern.

506
00:18:25,400 --> 00:18:27,920
The server handles business logic, data access,

507
00:18:27,920 --> 00:18:29,280
and system integration.

508
00:18:29,280 --> 00:18:32,320
The client handles language understanding, summarization,

509
00:18:32,320 --> 00:18:33,760
and generative reasoning.

510
00:18:33,760 --> 00:18:36,000
They collaborate through a standardized contract.

511
00:18:36,000 --> 00:18:38,480
In a Microsoft environment, this pattern is powerful

512
00:18:38,480 --> 00:18:40,800
because your MCP servers don't need to host

513
00:18:40,800 --> 00:18:42,240
or manage language models.

514
00:18:42,240 --> 00:18:44,440
They use the reasoning capabilities of co-pilot,

515
00:18:44,440 --> 00:18:47,400
Azure OpenAI, or whatever AI client is connecting to them.

516
00:18:47,400 --> 00:18:49,840
Now let's talk about the lifecycle of an MCP session.

517
00:18:49,840 --> 00:18:51,160
The client connects.

518
00:18:51,160 --> 00:18:53,160
The initialization handshake happens.

519
00:18:53,160 --> 00:18:55,080
The client requests the list of available tools,

520
00:18:55,080 --> 00:18:56,280
resources, and prompts.

521
00:18:56,280 --> 00:18:57,920
The server responds with the catalog.

522
00:18:57,920 --> 00:18:59,600
The agent reasons about what it needs.

523
00:18:59,600 --> 00:19:00,440
It invokes tools.

524
00:19:00,440 --> 00:19:01,720
It reads resources.

525
00:19:01,720 --> 00:19:04,080
It may request prompts, and when the work is complete,

526
00:19:04,080 --> 00:19:05,320
the session closes.

527
00:19:05,320 --> 00:19:08,200
Throughout this lifecycle, the protocol maintains state.

528
00:19:08,200 --> 00:19:10,000
The server knows which client it's talking to.

529
00:19:10,000 --> 00:19:12,400
The client knows which capabilities the server offers,

530
00:19:12,400 --> 00:19:14,240
and both sides can send notifications,

531
00:19:14,240 --> 00:19:16,120
not just requests and responses.

532
00:19:16,120 --> 00:19:17,920
Notifications are one-way messages.

533
00:19:17,920 --> 00:19:20,640
A server might notify the client that a resource has changed,

534
00:19:20,640 --> 00:19:22,920
prompting the agent to refresh its context.

535
00:19:22,920 --> 00:19:25,520
A client might notify the server that it's shutting down,

536
00:19:25,520 --> 00:19:27,520
allowing the server to clean up resources.

537
00:19:27,520 --> 00:19:29,640
This event-driven pattern keeps agents working

538
00:19:29,640 --> 00:19:32,240
with current context rather than stale snapshots.

539
00:19:32,240 --> 00:19:33,920
When a SharePoint document is updated,

540
00:19:33,920 --> 00:19:36,200
the MCP server can notify all connected agents

541
00:19:36,200 --> 00:19:37,680
that the resource has changed.

542
00:19:37,680 --> 00:19:40,600
The agents pull the new version and update their reasoning.

543
00:19:40,600 --> 00:19:42,680
The message format itself is worth understanding

544
00:19:42,680 --> 00:19:45,960
because you'll see it in logs, traces, and debugging sessions.

545
00:19:45,960 --> 00:19:49,160
A JSON RPC request is a JSON object with four fields.

546
00:19:49,160 --> 00:19:51,000
JSON RPC is always 2.0.

547
00:19:51,000 --> 00:19:53,880
I'd is a unique identifier that the client generates,

548
00:19:53,880 --> 00:19:56,320
so it can match the response to the request.

549
00:19:56,320 --> 00:19:58,200
Method is the capability being invoked

550
00:19:58,200 --> 00:20:00,880
like tools, call, or resources, read.

551
00:20:00,880 --> 00:20:02,240
And Params is an object containing

552
00:20:02,240 --> 00:20:03,840
the method-specific parameters.

553
00:20:03,840 --> 00:20:06,440
A JSON RPC response is similarly structured.

554
00:20:06,440 --> 00:20:08,120
JSON RPC is 2.0.

555
00:20:08,120 --> 00:20:11,200
I'd match the request and result contains the response data.

556
00:20:11,200 --> 00:20:13,960
If something goes wrong, result is replaced by error,

557
00:20:13,960 --> 00:20:16,120
which contains a numeric code, a message string,

558
00:20:16,120 --> 00:20:18,600
and optional data with additional context.

559
00:20:18,600 --> 00:20:20,280
This format is intentionally simple.

560
00:20:20,280 --> 00:20:22,000
You can read it in a text editor.

561
00:20:22,000 --> 00:20:24,200
You can pass it with any JSON library.

562
00:20:24,200 --> 00:20:25,720
And you can trace it through network logs

563
00:20:25,720 --> 00:20:27,360
without specialized tools.

564
00:20:27,360 --> 00:20:30,160
The initialization handshake uses the same format.

565
00:20:30,160 --> 00:20:31,680
The client sends an initialized request

566
00:20:31,680 --> 00:20:33,480
with method, initialize, and Params

567
00:20:33,480 --> 00:20:36,600
containing protocol version, capabilities, and client info.

568
00:20:36,600 --> 00:20:38,440
The server responds with a result containing

569
00:20:38,440 --> 00:20:42,480
the server's protocol version, capabilities, and server info.

570
00:20:42,480 --> 00:20:44,600
Only after this exchange does the client send

571
00:20:44,600 --> 00:20:48,040
an initialized notification, and only after that notification

572
00:20:48,040 --> 00:20:50,000
does the server accept normal requests.

573
00:20:50,000 --> 00:20:51,760
This sequence matters for debugging.

574
00:20:51,760 --> 00:20:53,440
If your agent can't discover tools,

575
00:20:53,440 --> 00:20:56,160
the first thing to check is whether the initialization handshake

576
00:20:56,160 --> 00:20:57,000
completed.

577
00:20:57,000 --> 00:20:58,920
Look for the initialize request in your logs.

578
00:20:58,920 --> 00:21:00,200
Look for the response.

579
00:21:00,200 --> 00:21:02,440
Check that the protocol versions are compatible,

580
00:21:02,440 --> 00:21:05,240
and verify that the initialized notification was sent.

581
00:21:05,240 --> 00:21:07,240
Most connection failures happen at this layer,

582
00:21:07,240 --> 00:21:08,880
not at the tool invocation layer.

583
00:21:08,880 --> 00:21:10,880
The protocol version evolution is worth tracking

584
00:21:10,880 --> 00:21:12,680
because it affects what you can build.

585
00:21:12,680 --> 00:21:16,520
Version 2025 0618 added structured tool output,

586
00:21:16,520 --> 00:21:19,200
illicitation support, and enhanced security.

587
00:21:19,200 --> 00:21:21,680
Illicitation is a pattern where a tool can ask the client

588
00:21:21,680 --> 00:21:24,680
for additional information before completing its execution.

589
00:21:24,680 --> 00:21:27,200
Instead of failing when a required parameter is missing,

590
00:21:27,200 --> 00:21:29,440
the tool can prompt the client to provide it.

591
00:21:29,440 --> 00:21:33,920
Version 2025 1125, which the C-PARCH SDK View 1.0 targets,

592
00:21:33,920 --> 00:21:36,320
refined these patterns and added richer metadata

593
00:21:36,320 --> 00:21:37,800
for tools and resources.

594
00:21:37,800 --> 00:21:39,440
It also formalizes the authorization

595
00:21:39,440 --> 00:21:42,080
of flows that secure connections between clients and servers.

596
00:21:42,080 --> 00:21:43,560
As an architect, you need to decide

597
00:21:43,560 --> 00:21:45,120
which protocol version to target.

598
00:21:45,120 --> 00:21:47,360
The general rule is this, target the oldest version

599
00:21:47,360 --> 00:21:49,080
that supports all the features you need.

600
00:21:49,080 --> 00:21:50,800
This maximizes client compatibility.

601
00:21:50,800 --> 00:21:52,800
If you don't need structured tool output,

602
00:21:52,800 --> 00:21:55,480
targeting an older version means more clients can connect.

603
00:21:55,480 --> 00:21:59,640
If you do need it, targeting 2025 0618 or later is the right call.

604
00:21:59,640 --> 00:22:03,280
The C-PARCH SDK handles much of this negotiation automatically,

605
00:22:03,280 --> 00:22:04,720
but you need to understand the trade-offs

606
00:22:04,720 --> 00:22:06,600
because they affect your server design.

607
00:22:06,600 --> 00:22:09,480
Building your first MCP server in C, theory is fine,

608
00:22:09,480 --> 00:22:12,040
but let's look at what this actually looks like in C-PARCH.

609
00:22:12,040 --> 00:22:15,480
Microsoft's official C-PAR SDK for model context protocol

610
00:22:15,480 --> 00:22:17,080
is available on NewGit.

611
00:22:17,080 --> 00:22:19,320
The package is called ModelContext Protocol,

612
00:22:19,320 --> 00:22:22,640
and as of March 2026, the current version is 1.4.

613
00:22:22,640 --> 00:22:25,040
So, the source is on GitHub at GitHub.

614
00:22:25,040 --> 00:22:27,880
COM ModelContext Protocol, C# SDK,

615
00:22:27,880 --> 00:22:30,320
and it's actively maintained in collaboration with Microsoft.

616
00:22:30,320 --> 00:22:32,440
This isn't a community wrapper around the protocol,

617
00:22:32,440 --> 00:22:34,200
it's the official SDK.

618
00:22:34,200 --> 00:22:37,320
And version 1.0 released in March 2026 marks the point

619
00:22:37,320 --> 00:22:40,280
where the API surface is stable enough for production use.

620
00:22:40,280 --> 00:22:43,280
Let's walk through building a simple MCP server from scratch.

621
00:22:43,280 --> 00:22:45,560
You start with a standard net project.

622
00:22:45,560 --> 00:22:47,680
Console Application for Local Testing.

623
00:22:47,680 --> 00:22:49,880
Web API project for remote deployment.

624
00:22:49,880 --> 00:22:51,440
The SDK supports both.

625
00:22:51,440 --> 00:22:53,960
You add the NewGit package, ModelContext Protocol.

626
00:22:53,960 --> 00:22:56,840
That's the only required dependency for a basic server.

627
00:22:56,840 --> 00:22:58,200
Then you define your tools.

628
00:22:58,200 --> 00:23:03,080
A tool in the C-PARCH SDK is a method decorated with attributes

629
00:23:03,080 --> 00:23:06,240
that describe its name, description, and parameter schema.

630
00:23:06,240 --> 00:23:08,520
The SDK uses source generators to inspect

631
00:23:08,520 --> 00:23:10,240
these attributes at compile time

632
00:23:10,240 --> 00:23:12,520
and build the protocol metadata automatically.

633
00:23:12,520 --> 00:23:13,400
Here's the pattern.

634
00:23:13,400 --> 00:23:15,560
You create a class that holds your business logic.

635
00:23:15,560 --> 00:23:18,400
You add a method that performs the operation your agent needs.

636
00:23:18,400 --> 00:23:20,520
You decorate it with the MCP tool attribute.

637
00:23:20,520 --> 00:23:23,640
You define the parameters as a strongly typed record or class.

638
00:23:23,640 --> 00:23:26,280
And the SDK generates the JSON schema for you.

639
00:23:26,280 --> 00:23:28,480
This means you don't write JSON schema by hand.

640
00:23:28,480 --> 00:23:29,960
You write CRS types.

641
00:23:29,960 --> 00:23:31,880
The SDK reflects over them and produces

642
00:23:31,880 --> 00:23:34,240
the schema that the agencies during discovery.

643
00:23:34,240 --> 00:23:37,040
When the protocol evolves and new schema features are added,

644
00:23:37,040 --> 00:23:39,440
the SDK updates its generation logic.

645
00:23:39,440 --> 00:23:40,640
Your code stays clean.

646
00:23:40,640 --> 00:23:42,640
The method body is standard C-FARCH.

647
00:23:42,640 --> 00:23:45,360
You can inject services through dependency injection.

648
00:23:45,360 --> 00:23:47,240
You can call your existing business layers.

649
00:23:47,240 --> 00:23:48,440
You can query databases.

650
00:23:48,440 --> 00:23:49,760
You can invoke other APIs.

651
00:23:49,760 --> 00:23:52,280
The tool method is just a normal C-SARCH method

652
00:23:52,280 --> 00:23:55,280
that happens to be exposed through the MCP protocol.

653
00:23:55,280 --> 00:23:57,960
This is where the SDK's hosting extensions shine.

654
00:23:57,960 --> 00:24:00,120
In a typical ASP.NET Core application,

655
00:24:00,120 --> 00:24:01,640
you configure the host builder.

656
00:24:01,640 --> 00:24:03,840
You register your services in the dependency injection

657
00:24:03,840 --> 00:24:04,720
container.

658
00:24:04,720 --> 00:24:08,440
And then you call add MCP server to add the MCP server to the host.

659
00:24:08,440 --> 00:24:11,160
You configure it with the protocol version you want to target.

660
00:24:11,160 --> 00:24:12,760
You register your tool classes.

661
00:24:12,760 --> 00:24:14,360
And you map the MCP endpoints.

662
00:24:14,360 --> 00:24:16,880
The SDK handles the initialization handshake.

663
00:24:16,880 --> 00:24:19,080
It processes the JSON RPC messages.

664
00:24:19,080 --> 00:24:21,240
It routes tool invocations to the correct methods.

665
00:24:21,240 --> 00:24:22,880
It serializes the responses.

666
00:24:22,880 --> 00:24:24,840
And it manages the session lifecycle.

667
00:24:24,840 --> 00:24:26,560
For local development, you run the server

668
00:24:26,560 --> 00:24:29,400
as a console application using SDDO transport.

669
00:24:29,400 --> 00:24:31,680
The agent connects to the standard input and output streams.

670
00:24:31,680 --> 00:24:34,200
There's no network configuration, no firewall rules,

671
00:24:34,200 --> 00:24:35,520
no SSL certificates.

672
00:24:35,520 --> 00:24:38,680
It's just a process that speaks JSON RPC over pipes.

673
00:24:38,680 --> 00:24:40,360
This is perfect for rapid iteration.

674
00:24:40,360 --> 00:24:42,840
You write a tool, you test it with an MCP client,

675
00:24:42,840 --> 00:24:44,280
you see the results immediately.

676
00:24:44,280 --> 00:24:46,080
You iterate on the parameter schema.

677
00:24:46,080 --> 00:24:47,520
You refine the description.

678
00:24:47,520 --> 00:24:50,640
And once it's working, you graduate to a remote transport.

679
00:24:50,640 --> 00:24:52,800
Let's talk about structured output in practice.

680
00:24:52,800 --> 00:24:56,040
Before the 2025-0618 protocol update,

681
00:24:56,040 --> 00:24:58,280
your tool methods probably return strings.

682
00:24:58,280 --> 00:25:01,160
You formatted the result as text and the agent pasted.

683
00:25:01,160 --> 00:25:02,880
Now you can return typed objects.

684
00:25:02,880 --> 00:25:05,920
You define a C-Parts record that represents your result.

685
00:25:05,920 --> 00:25:08,120
You populate it with data from your business system.

686
00:25:08,120 --> 00:25:09,600
You return it from your tool method.

687
00:25:09,600 --> 00:25:12,600
The SDK serializes it to JSON automatically.

688
00:25:12,600 --> 00:25:14,480
And the agent receives a structured object.

689
00:25:14,480 --> 00:25:16,400
It can reason over natively.

690
00:25:16,400 --> 00:25:18,960
If your inventory query returns a list of stock items,

691
00:25:18,960 --> 00:25:21,280
you define a stock item record with fields for product

692
00:25:21,280 --> 00:25:23,800
id, quantity, location, and last updated.

693
00:25:23,800 --> 00:25:26,320
The agent doesn't need to pass text to find the quantity.

694
00:25:26,320 --> 00:25:28,880
It accesses the quantity field directly in its reasoning.

695
00:25:28,880 --> 00:25:31,360
This is a subtle change with massive implications.

696
00:25:31,360 --> 00:25:33,400
It means your agents can make precise decisions

697
00:25:33,400 --> 00:25:34,720
based on typed data.

698
00:25:34,720 --> 00:25:35,880
They can compare quantities.

699
00:25:35,880 --> 00:25:36,760
They can check dates.

700
00:25:36,760 --> 00:25:38,120
They can filter lists.

701
00:25:38,120 --> 00:25:40,240
And they can do all of this without you writing custom

702
00:25:40,240 --> 00:25:41,400
passing logic.

703
00:25:41,400 --> 00:25:43,280
The SDK also supports elicitation.

704
00:25:43,280 --> 00:25:46,760
Elicitation is a pattern where a tool can request additional input

705
00:25:46,760 --> 00:25:48,360
from the agent during execution.

706
00:25:48,360 --> 00:25:50,800
Instead of throwing an exception when a required parameter

707
00:25:50,800 --> 00:25:53,880
is missing, the tool returns an elicitation response.

708
00:25:53,880 --> 00:25:56,840
The agent sees the request, asks the user for the missing information

709
00:25:56,840 --> 00:25:58,400
and provides it in a follow-up call.

710
00:25:58,400 --> 00:26:00,440
This creates a conversational interaction pattern.

711
00:26:00,440 --> 00:26:02,280
The agent doesn't need to know everything upfront.

712
00:26:02,280 --> 00:26:04,200
It can discover what's needed as it goes.

713
00:26:04,200 --> 00:26:05,640
And the user experience feels natural

714
00:26:05,640 --> 00:26:08,520
because the agent asks clarifying questions rather

715
00:26:08,520 --> 00:26:09,960
than failing silently.

716
00:26:09,960 --> 00:26:14,040
Error handling in the SDK follows the JSON RPC specification.

717
00:26:14,040 --> 00:26:16,880
When a tool throws an exception, the SDK catches it

718
00:26:16,880 --> 00:26:19,000
and returns a JSON RPC error response

719
00:26:19,000 --> 00:26:20,800
with an appropriate error code.

720
00:26:20,800 --> 00:26:22,800
You can customize this behavior by implementing

721
00:26:22,800 --> 00:26:24,560
your own error handling middleware.

722
00:26:24,560 --> 00:26:27,200
The SDK also integrates with standard net logging.

723
00:26:27,200 --> 00:26:29,320
Every request, every tool invocation,

724
00:26:29,320 --> 00:26:32,080
every error is logged through the iLogger pipeline.

725
00:26:32,080 --> 00:26:34,080
This means you're existing logging infrastructure,

726
00:26:34,080 --> 00:26:35,760
whether it's application insights,

727
00:26:35,760 --> 00:26:37,640
serolog, or another provider captures

728
00:26:37,640 --> 00:26:39,800
MCP activity without custom code.

729
00:26:39,800 --> 00:26:41,200
And there's one more feature that matters

730
00:26:41,200 --> 00:26:44,880
for enterprise deployments, long running requests.

731
00:26:44,880 --> 00:26:46,360
Some tools take time.

732
00:26:46,360 --> 00:26:49,600
A report generation query might run for 30 seconds.

733
00:26:49,600 --> 00:26:52,160
An approval workflow might wait for a human response.

734
00:26:52,160 --> 00:26:54,320
The SDK supports long running tool executions

735
00:26:54,320 --> 00:26:55,760
through asynchronous patterns.

736
00:26:55,760 --> 00:26:58,120
The client can pull for status, or the server

737
00:26:58,120 --> 00:27:01,160
can send progress notifications while the work continues.

738
00:27:01,160 --> 00:27:03,000
This prevents timeouts on slow operations.

739
00:27:03,000 --> 00:27:05,200
It keeps the agent informed about what's happening.

740
00:27:05,200 --> 00:27:08,360
And it allows your MCP servers to integrate with human in the loop

741
00:27:08,360 --> 00:27:10,760
processes that are common in enterprise workflows.

742
00:27:10,760 --> 00:27:12,560
So the development workflow looks like this.

743
00:27:12,560 --> 00:27:13,920
You scaffold a .NET project.

744
00:27:13,920 --> 00:27:16,440
You add the model context protocol, you get package.

745
00:27:16,440 --> 00:27:19,280
You define your tools as CRs methods with typed parameters.

746
00:27:19,280 --> 00:27:21,440
You configure the host with ad MCP server.

747
00:27:21,440 --> 00:27:22,480
You register your tools.

748
00:27:22,480 --> 00:27:24,400
You run locally with SDDO transport.

749
00:27:24,400 --> 00:27:26,160
You test with an MCP client.

750
00:27:26,160 --> 00:27:27,400
And when you're ready for production,

751
00:27:27,400 --> 00:27:30,320
you switch to streamable HTTP and deploy to Azure.

752
00:27:30,320 --> 00:27:32,880
Let's look at what the CR code actually feels like.

753
00:27:32,880 --> 00:27:35,480
A tool method is a standard C-PASS method decorated

754
00:27:35,480 --> 00:27:36,240
with an attribute.

755
00:27:36,240 --> 00:27:38,880
The method might be called GetInventoryAsync.

756
00:27:38,880 --> 00:27:40,880
It might take a product id string parameter

757
00:27:40,880 --> 00:27:42,680
and a location code string parameter.

758
00:27:42,680 --> 00:27:45,520
It returns a task containing an inventory result record.

759
00:27:45,520 --> 00:27:47,560
The inventory result has fields for quantity,

760
00:27:47,560 --> 00:27:49,280
last updated, and status.

761
00:27:49,280 --> 00:27:52,640
The attribute on the method provides the MCP facing metadata.

762
00:27:52,640 --> 00:27:54,520
The tool name, the description that the agent

763
00:27:54,520 --> 00:27:57,200
will read during discovery, and hints about when the agent

764
00:27:57,200 --> 00:27:58,080
should invoke it.

765
00:27:58,080 --> 00:28:00,440
The SDK's source generator reads this attribute

766
00:28:00,440 --> 00:28:03,000
at compile time and produces the JSON schema

767
00:28:03,000 --> 00:28:05,320
that gets sent to clients during initialization.

768
00:28:05,320 --> 00:28:08,320
The parameters are defined as a CR record or class.

769
00:28:08,320 --> 00:28:11,280
Each property becomes a parameter in the JSON schema.

770
00:28:11,280 --> 00:28:13,520
Property types map to JSON schema types.

771
00:28:13,520 --> 00:28:14,880
String becomes string.

772
00:28:14,880 --> 00:28:16,200
It becomes integer.

773
00:28:16,200 --> 00:28:17,440
Bull becomes Boolean.

774
00:28:17,440 --> 00:28:20,360
Date time offset becomes string with format date time.

775
00:28:20,360 --> 00:28:22,840
And nullable properties become optional parameters.

776
00:28:22,840 --> 00:28:24,880
This type driven approach means your tool contract

777
00:28:24,880 --> 00:28:27,440
is defined in C-Farset, not in JSON.

778
00:28:27,440 --> 00:28:30,160
When you rename a property, the schema updates automatically.

779
00:28:30,160 --> 00:28:32,720
When you add a new property, the schema includes it.

780
00:28:32,720 --> 00:28:35,240
When you change a type, the schema reflects the new type.

781
00:28:35,240 --> 00:28:37,600
There's no separate open API document to maintain.

782
00:28:37,600 --> 00:28:39,800
No manual schema editing and no risk

783
00:28:39,800 --> 00:28:41,800
that your code and your schema drift out of sync.

784
00:28:41,800 --> 00:28:43,480
The dependency injection integration

785
00:28:43,480 --> 00:28:45,840
means your tool methods can request services

786
00:28:45,840 --> 00:28:48,280
through constructor injection or method parameters.

787
00:28:48,280 --> 00:28:50,080
If your tool needs to query a database,

788
00:28:50,080 --> 00:28:51,880
you inject the database context.

789
00:28:51,880 --> 00:28:53,520
If your tool needs to call another API,

790
00:28:53,520 --> 00:28:55,240
you inject the HTTP client.

791
00:28:55,240 --> 00:28:56,920
If your tool needs to reconfiguration,

792
00:28:56,920 --> 00:28:58,480
you inject i-configuration.

793
00:28:58,480 --> 00:29:01,160
This is standard ASP.NET Core dependency injection.

794
00:29:01,160 --> 00:29:02,760
The same patterns you use in controllers,

795
00:29:02,760 --> 00:29:04,520
background services, and middleware.

796
00:29:04,520 --> 00:29:07,240
MCP servers are just another host in your ASP.

797
00:29:07,240 --> 00:29:08,680
Net Core application.

798
00:29:08,680 --> 00:29:12,280
The SDK also supports testing through the IMCP server abstraction.

799
00:29:12,280 --> 00:29:15,040
You can create an in-memory MCP server in your unit tests.

800
00:29:15,040 --> 00:29:17,640
You register your tools, you send JSON RPC requests,

801
00:29:17,640 --> 00:29:19,080
you verify the responses.

802
00:29:19,080 --> 00:29:20,880
And you test error handling, edge cases,

803
00:29:20,880 --> 00:29:23,360
and schema validation without running the full web host.

804
00:29:23,360 --> 00:29:26,600
This testability is important because MCP servers are infrastructure.

805
00:29:26,600 --> 00:29:29,440
They need the same testing rigor as any other production service.

806
00:29:29,440 --> 00:29:32,960
Unit tests for business logic, integration tests for database queries,

807
00:29:32,960 --> 00:29:35,520
and to end tests for the full JSON RPC pipeline.

808
00:29:35,520 --> 00:29:38,280
The SDK's logging integration is equally straightforward.

809
00:29:38,280 --> 00:29:41,040
Every JSON RPC request is logged at the information level.

810
00:29:41,040 --> 00:29:44,280
Every tool invocation is logged with the method name and the duration.

811
00:29:44,280 --> 00:29:46,520
Every error is logged with the exception details.

812
00:29:46,520 --> 00:29:48,520
And the JSON RPC error code.

813
00:29:48,520 --> 00:29:51,480
And because it uses the standard iLogger interface,

814
00:29:51,480 --> 00:29:55,040
your existing logging providers capture everything without configuration changes.

815
00:29:55,040 --> 00:29:59,080
For local testing, the SDK includes a built-in STDIO transport.

816
00:29:59,080 --> 00:30:00,440
You run your console application.

817
00:30:00,440 --> 00:30:02,360
The SDK listens on standard input.

818
00:30:02,360 --> 00:30:04,240
It processes JSON RPC messages.

819
00:30:04,240 --> 00:30:05,440
It routes them to your tools.

820
00:30:05,440 --> 00:30:07,320
And it writes responses to standard output.

821
00:30:07,320 --> 00:30:10,400
This means you can test your server using any MCP client

822
00:30:10,400 --> 00:30:13,160
that supports STDIO, including the reference client

823
00:30:13,160 --> 00:30:14,640
from the MCP project.

824
00:30:14,640 --> 00:30:17,520
The transition from STDIO to streamable HTTP

825
00:30:17,520 --> 00:30:19,320
is a single configuration change.

826
00:30:19,320 --> 00:30:21,800
In your host setup, you switch from user studio transport

827
00:30:21,800 --> 00:30:23,920
to use streamable HTTP transport.

828
00:30:23,920 --> 00:30:25,800
You configure the HTTP endpoint.

829
00:30:25,800 --> 00:30:27,240
You add authentication middleware.

830
00:30:27,240 --> 00:30:28,600
And everything else stays the same.

831
00:30:28,600 --> 00:30:29,920
Your tools don't change.

832
00:30:29,920 --> 00:30:31,560
Your business logic doesn't change.

833
00:30:31,560 --> 00:30:33,640
Your dependency injection setup doesn't change.

834
00:30:33,640 --> 00:30:36,760
This transport abstraction is one of the SDK's strongest features.

835
00:30:36,760 --> 00:30:39,600
It lets you develop locally with the simplest possible transport

836
00:30:39,600 --> 00:30:42,200
and deploy to production with the most robust transport

837
00:30:42,200 --> 00:30:43,480
without rewriting your server.

838
00:30:43,480 --> 00:30:44,760
That's the core pattern.

839
00:30:44,760 --> 00:30:47,000
And it scales from a single tool on your laptop

840
00:30:47,000 --> 00:30:50,640
to hundreds of tools across a distributed Azure architecture.

841
00:30:50,640 --> 00:30:54,040
Transport layers from STDIO to streamable HTTP.

842
00:30:54,040 --> 00:30:56,600
Local STDIO testing is fine for your laptop,

843
00:30:56,600 --> 00:30:59,000
but production is a completely different conversation.

844
00:30:59,000 --> 00:31:00,720
And the transport you choose will determine

845
00:31:00,720 --> 00:31:03,560
whether your MCP deployment succeeds or fails at enterprise

846
00:31:03,560 --> 00:31:04,240
scale.

847
00:31:04,240 --> 00:31:07,040
Let's look at the three transports, MCP supports,

848
00:31:07,040 --> 00:31:09,760
and understand why the protocol deprecated one of them.

849
00:31:09,760 --> 00:31:12,880
STDIO is the simplest transport, standard input and output.

850
00:31:12,880 --> 00:31:14,960
Your MCP server runs as a local process,

851
00:31:14,960 --> 00:31:17,040
the agent, which is also a local process,

852
00:31:17,040 --> 00:31:20,160
connects to the server's SDD and SDD out streams.

853
00:31:20,160 --> 00:31:23,520
Messages are JSON RPC objects delimited by new lines.

854
00:31:23,520 --> 00:31:26,360
This transport has exactly one advantage, simplicity.

855
00:31:26,360 --> 00:31:28,480
There are no network stacks, no port bindings,

856
00:31:28,480 --> 00:31:30,920
no SSL certificates, no firewall rules.

857
00:31:30,920 --> 00:31:32,760
You run the server executable and the client

858
00:31:32,760 --> 00:31:33,840
connects automatically.

859
00:31:33,840 --> 00:31:35,040
It's perfect for development.

860
00:31:35,040 --> 00:31:36,400
It's perfect for testing.

861
00:31:36,400 --> 00:31:38,360
And it's perfect for local tooling scenarios

862
00:31:38,360 --> 00:31:41,000
where the server and client are on the same machine.

863
00:31:41,000 --> 00:31:43,280
But STDIO has exactly one massive limitation.

864
00:31:43,280 --> 00:31:44,560
It only works locally.

865
00:31:44,560 --> 00:31:47,760
You cannot run an STIO MCP server on Azure

866
00:31:47,760 --> 00:31:49,440
and connect to it from co-pilot studio.

867
00:31:49,440 --> 00:31:51,640
You cannot host it in a container and expose it

868
00:31:51,640 --> 00:31:52,720
to remote clients.

869
00:31:52,720 --> 00:31:55,680
STDIO is a single process, single machine transport,

870
00:31:55,680 --> 00:31:58,040
and that makes it unsuitable for production deployments.

871
00:31:58,040 --> 00:32:00,360
Then MCP added server center vents, SSE,

872
00:32:00,360 --> 00:32:01,680
was the first remote transport.

873
00:32:01,680 --> 00:32:03,920
It uses an HTTP connection where the server can

874
00:32:03,920 --> 00:32:05,600
push updates to the client.

875
00:32:05,600 --> 00:32:07,120
The client opens a connection.

876
00:32:07,120 --> 00:32:08,480
The server keeps it open.

877
00:32:08,480 --> 00:32:10,400
And whenever the server has data descend,

878
00:32:10,400 --> 00:32:12,400
it pushes it through the open channel.

879
00:32:12,400 --> 00:32:14,600
SSE solves the remote connectivity problem.

880
00:32:14,600 --> 00:32:16,960
You could host an MCP server on a remote machine.

881
00:32:16,960 --> 00:32:18,920
Clients could connect over HTTP.

882
00:32:18,920 --> 00:32:20,680
And the server could push real-time updates

883
00:32:20,680 --> 00:32:22,400
without the client constantly polling.

884
00:32:22,400 --> 00:32:24,440
But SSE introduced new problems.

885
00:32:24,440 --> 00:32:25,840
Authentication was difficult.

886
00:32:25,840 --> 00:32:27,680
Because SSE connections are long-lived,

887
00:32:27,680 --> 00:32:30,000
standard HTTP authentication mechanisms

888
00:32:30,000 --> 00:32:31,160
don't fit cleanly.

889
00:32:31,160 --> 00:32:32,560
Baratokens expire.

890
00:32:32,560 --> 00:32:34,320
Sessions need refresh logic.

891
00:32:34,320 --> 00:32:37,080
And the long-lived connection makes token renewal awkward.

892
00:32:37,080 --> 00:32:38,640
Chores policies were problematic.

893
00:32:38,640 --> 00:32:41,360
Cross-origin resource sharing is a standard browser security

894
00:32:41,360 --> 00:32:41,960
feature.

895
00:32:41,960 --> 00:32:44,920
But SSE connections often run a foul of course configurations,

896
00:32:44,920 --> 00:32:46,320
especially in enterprise environments

897
00:32:46,320 --> 00:32:48,720
where strict security policies are the norm.

898
00:32:48,720 --> 00:32:51,720
Firewalls and proxies sometimes buffer SSE connections.

899
00:32:51,720 --> 00:32:52,680
This creates latency.

900
00:32:52,680 --> 00:32:54,800
Messages arrive late or in bursts.

901
00:32:54,800 --> 00:32:57,080
And some corporate proxies drop long-lived connections

902
00:32:57,080 --> 00:32:59,160
entirely, causing intermittent failures

903
00:32:59,160 --> 00:33:00,440
that are hard to diagnose.

904
00:33:00,440 --> 00:33:03,000
So the MCP specification deprecated SSE.

905
00:33:03,000 --> 00:33:05,240
And replaced it with streamable HTTP.

906
00:33:05,240 --> 00:33:08,120
Streamable HTTP is a fundamentally different approach.

907
00:33:08,120 --> 00:33:10,360
Instead of maintaining a single long-lived connection,

908
00:33:10,360 --> 00:33:13,480
it uses standard HTTP post and get requests.

909
00:33:13,480 --> 00:33:16,040
The client sends requests as post operations.

910
00:33:16,040 --> 00:33:17,360
The server responds immediately

911
00:33:17,360 --> 00:33:19,920
or streams the response over the same connection.

912
00:33:19,920 --> 00:33:21,920
If the server needs to send notifications,

913
00:33:21,920 --> 00:33:24,480
the client opens a get connection that the server can write to.

914
00:33:24,480 --> 00:33:28,520
This means streamable HTTP works with standard HTTP infrastructure.

915
00:33:28,520 --> 00:33:29,840
Load balancers handle it.

916
00:33:29,840 --> 00:33:31,320
Firewalls understand it.

917
00:33:31,320 --> 00:33:33,120
Chores policies apply cleanly.

918
00:33:33,120 --> 00:33:34,640
And authentication is straightforward

919
00:33:34,640 --> 00:33:36,440
because every request is independent

920
00:33:36,440 --> 00:33:38,160
and can carry its own orthotocons.

921
00:33:38,160 --> 00:33:40,680
For Microsoft environments, this is the transport you want.

922
00:33:40,680 --> 00:33:44,280
Streamable HTTP integrates with Microsoft Enter Authentication.

923
00:33:44,280 --> 00:33:48,200
Every post and get request can include a bearer token from Enter ID.

924
00:33:48,200 --> 00:33:50,640
Conditional access policies apply per request.

925
00:33:50,640 --> 00:33:53,080
Multi-factor authentication can be enforced

926
00:33:53,080 --> 00:33:54,880
at the API gateway level.

927
00:33:54,880 --> 00:33:56,600
And session management follows patterns

928
00:33:56,600 --> 00:33:59,240
that Microsoft security teams already understand.

929
00:33:59,240 --> 00:34:01,920
Streamable HTTP also supports session management.

930
00:34:01,920 --> 00:34:03,920
When a client connects, the server can assign

931
00:34:03,920 --> 00:34:05,360
a session identifier.

932
00:34:05,360 --> 00:34:07,720
Subsequent requests include this identifier,

933
00:34:07,720 --> 00:34:09,400
allowing the server to maintain state

934
00:34:09,400 --> 00:34:11,720
across multiple HTTP requests.

935
00:34:11,720 --> 00:34:15,000
This is how an MCP server remembers what tools it has exposed,

936
00:34:15,000 --> 00:34:17,680
what resources are available, and what notifications

937
00:34:17,680 --> 00:34:19,320
the client has subscribed to.

938
00:34:19,320 --> 00:34:23,040
For Azure deployments, streamable HTTP is the natural fit.

939
00:34:23,040 --> 00:34:25,680
Azure functions can handle streamable HTTP requests

940
00:34:25,680 --> 00:34:27,200
through HTTP triggers.

941
00:34:27,200 --> 00:34:29,560
An agent sends a post to your function endpoint.

942
00:34:29,560 --> 00:34:32,240
The function processes the JSON RPC request

943
00:34:32,240 --> 00:34:33,480
and returns the response.

944
00:34:33,480 --> 00:34:35,000
If the operation is long running,

945
00:34:35,000 --> 00:34:36,960
the function can return and accept its status

946
00:34:36,960 --> 00:34:38,920
and send the final result through a callback

947
00:34:38,920 --> 00:34:40,720
or a subsequent get request.

948
00:34:40,720 --> 00:34:43,480
Azure API management sits in front of your MCP servers

949
00:34:43,480 --> 00:34:46,520
and provides unified routing, rate limiting, and monitoring.

950
00:34:46,520 --> 00:34:48,360
You can expose multiple MCP servers

951
00:34:48,360 --> 00:34:50,600
through a single API management gateway.

952
00:34:50,600 --> 00:34:52,760
The gateway handles authentication, throttling,

953
00:34:52,760 --> 00:34:54,320
and request transformation.

954
00:34:54,320 --> 00:34:56,720
And your backend servers focus on business logic.

955
00:34:56,720 --> 00:34:59,400
Azure Container Apps can host persistent MCP servers

956
00:34:59,400 --> 00:35:01,520
that need stateful session management.

957
00:35:01,520 --> 00:35:03,360
If your server maintains long-lived connections

958
00:35:03,360 --> 00:35:06,320
to backend systems, or if it needs to cache resource data

959
00:35:06,320 --> 00:35:08,320
between requests, a containerized deployment

960
00:35:08,320 --> 00:35:09,920
gives you the control you need.

961
00:35:09,920 --> 00:35:11,680
And as your front door or application gateway

962
00:35:11,680 --> 00:35:14,320
can distribute MCP traffic across multiple regions,

963
00:35:14,320 --> 00:35:16,760
providing geographic redundancy and failover,

964
00:35:16,760 --> 00:35:19,120
the choice between transports is not really a choice anymore.

965
00:35:19,120 --> 00:35:20,560
STDO for development.

966
00:35:20,560 --> 00:35:23,160
Streamable HTTP for production.

967
00:35:23,160 --> 00:35:26,120
SSE is deprecated and should not be used for new deployments.

968
00:35:26,120 --> 00:35:27,920
If you have existing SSE deployments,

969
00:35:27,920 --> 00:35:30,720
you should plan a migration to streamable HTTP.

970
00:35:30,720 --> 00:35:32,400
The protocol changes are not dramatic.

971
00:35:32,400 --> 00:35:34,600
The JSON RPC message format is the same.

972
00:35:34,600 --> 00:35:36,880
But the connection model shifts from persistent streams

973
00:35:36,880 --> 00:35:38,440
to request response pairs.

974
00:35:38,440 --> 00:35:41,160
And that shift unlocks enterprise grade authentication,

975
00:35:41,160 --> 00:35:42,480
scaling, and monitoring.

976
00:35:42,480 --> 00:35:44,320
Here's the decision matrix.

977
00:35:44,320 --> 00:35:47,040
If you're building a local tool or developer utility,

978
00:35:47,040 --> 00:35:48,760
use STDO.

979
00:35:48,760 --> 00:35:50,840
It's the fastest path to a working server.

980
00:35:50,840 --> 00:35:53,800
If you're deploying to Azure, use streamable HTTP.

981
00:35:53,800 --> 00:35:55,520
It's the only transport that integrates

982
00:35:55,520 --> 00:35:57,880
cleanly with Entra, API management,

983
00:35:57,880 --> 00:36:00,040
and standard enterprise security policies.

984
00:36:00,040 --> 00:36:02,040
If you're evaluating SSE for a new project,

985
00:36:02,040 --> 00:36:04,360
stop, use streamable HTTP instead.

986
00:36:04,360 --> 00:36:07,560
SSE is deprecated in the MCP specification

987
00:36:07,560 --> 00:36:09,680
and will not receive further enhancements.

988
00:36:09,680 --> 00:36:11,760
This transport decision is one of the most important

989
00:36:11,760 --> 00:36:13,520
architectural choices you'll make.

990
00:36:13,520 --> 00:36:15,560
Because once you have hundreds of agents connecting

991
00:36:15,560 --> 00:36:18,200
to dozens of MCP servers, the transport layer

992
00:36:18,200 --> 00:36:19,880
determines your authentication model,

993
00:36:19,880 --> 00:36:23,000
your scaling strategy, and your observability footprint.

994
00:36:23,000 --> 00:36:25,720
Get this right and the rest of your MCP architecture

995
00:36:25,720 --> 00:36:26,800
follows cleanly.

996
00:36:26,800 --> 00:36:29,080
Get this wrong and you'll be fighting connection issues,

997
00:36:29,080 --> 00:36:32,280
or failures and firewall rules while your AI team

998
00:36:32,280 --> 00:36:34,800
waits for the connectivity layer to work.

999
00:36:34,800 --> 00:36:38,040
The USB-C for AI pattern, why standardization wins.

1000
00:36:38,040 --> 00:36:40,200
This is where the USB-C for AI analogy

1001
00:36:40,200 --> 00:36:42,680
starts to make real sense, not as a marketing phrase,

1002
00:36:42,680 --> 00:36:45,400
as a structural pattern.

1003
00:36:45,400 --> 00:36:47,960
Before USB-C, every device had its own cable,

1004
00:36:47,960 --> 00:36:50,400
its own connector, its own pinot.

1005
00:36:50,400 --> 00:36:52,000
You needed a drawer full of adapters

1006
00:36:52,000 --> 00:36:55,120
just to connect a phone, a laptop, and a monitor.

1007
00:36:55,120 --> 00:36:57,520
The connections worked, but they were bespoke.

1008
00:36:57,520 --> 00:36:58,360
FraudGile.

1009
00:36:58,360 --> 00:37:00,760
And every new device added another cable to the pile.

1010
00:37:00,760 --> 00:37:03,240
That's where we are with AI integrations today.

1011
00:37:03,240 --> 00:37:05,760
Every business system has its own API, its own auth model,

1012
00:37:05,760 --> 00:37:08,080
its own payload format, its own error handling,

1013
00:37:08,080 --> 00:37:10,640
and every AI agent that needs to talk to those systems

1014
00:37:10,640 --> 00:37:12,520
needs custom code for each connection,

1015
00:37:12,520 --> 00:37:15,920
a custom wrapper for the ERP, a custom connector for the CRM,

1016
00:37:15,920 --> 00:37:18,200
a custom pipeline for the SharePoint search,

1017
00:37:18,200 --> 00:37:20,080
and when any of those systems upgrade,

1018
00:37:20,080 --> 00:37:21,440
the custom code breaks.

1019
00:37:21,440 --> 00:37:24,560
MCP is the USB-C moment for AI connectivity,

1020
00:37:24,560 --> 00:37:26,600
one protocol, one discovery model,

1021
00:37:26,600 --> 00:37:30,000
one capability contract, and any agent that speaks MCP

1022
00:37:30,000 --> 00:37:31,960
can connect to any MCP server

1023
00:37:31,960 --> 00:37:34,000
without knowing what backend system it wraps.

1024
00:37:34,000 --> 00:37:37,120
The standardization unlocks something bigger than convenience.

1025
00:37:37,120 --> 00:37:38,920
It unlocks composability.

1026
00:37:38,920 --> 00:37:41,720
When every integration is bespoke, you can't compose them.

1027
00:37:41,720 --> 00:37:44,040
Your inventory agent knows how to talk to your ERP

1028
00:37:44,040 --> 00:37:45,480
because you wrote that wrapper,

1029
00:37:45,480 --> 00:37:46,760
but your customer service agent

1030
00:37:46,760 --> 00:37:48,680
doesn't know how to talk to your inventory system

1031
00:37:48,680 --> 00:37:50,040
because it uses a different wrapper

1032
00:37:50,040 --> 00:37:51,120
with a different interface.

1033
00:37:51,120 --> 00:37:52,480
The knowledge doesn't transfer.

1034
00:37:52,480 --> 00:37:55,160
With MCP, every agent speaks the same protocol.

1035
00:37:55,160 --> 00:37:58,440
When you build an MCP server for your ERP, any agent can use it.

1036
00:37:58,440 --> 00:38:01,080
The inventory agent, the customer service agent,

1037
00:38:01,080 --> 00:38:02,720
the finance agent, the procurement agent,

1038
00:38:02,720 --> 00:38:04,520
they all discover the same tools,

1039
00:38:04,520 --> 00:38:06,640
they all invoke them through the same contract,

1040
00:38:06,640 --> 00:38:09,600
and they all receive structured responses they can reason over.

1041
00:38:09,600 --> 00:38:11,080
This is the digital twin pattern.

1042
00:38:11,080 --> 00:38:13,120
Instead of writing integration code for every agent,

1043
00:38:13,120 --> 00:38:16,480
you codify your business logic into an MCP server.

1044
00:38:16,480 --> 00:38:18,200
The server knows your approval hierarchy,

1045
00:38:18,200 --> 00:38:19,440
it knows your discount rules,

1046
00:38:19,440 --> 00:38:20,920
it knows your compliance checks,

1047
00:38:20,920 --> 00:38:22,920
it knows which orders need manager approval

1048
00:38:22,920 --> 00:38:24,360
and which can auto-approve,

1049
00:38:24,360 --> 00:38:26,600
it knows which customers get expedited shipping

1050
00:38:26,600 --> 00:38:28,760
and which regions have export restrictions.

1051
00:38:28,760 --> 00:38:31,040
The AI doesn't need to guess how your business works.

1052
00:38:31,040 --> 00:38:32,720
It asks the MCP server,

1053
00:38:32,720 --> 00:38:34,000
and the server provides the answer

1054
00:38:34,000 --> 00:38:35,760
through a structured, typed contract.

1055
00:38:35,760 --> 00:38:37,920
This changes the economics of AI deployment.

1056
00:38:37,920 --> 00:38:41,000
Without MCP, every AI project starts with integration,

1057
00:38:41,000 --> 00:38:42,400
six months of wrapper development

1058
00:38:42,400 --> 00:38:44,240
before the agent can do anything useful.

1059
00:38:44,240 --> 00:38:45,840
With MCP, you build the server once,

1060
00:38:45,840 --> 00:38:48,400
you expose your business capabilities as tools,

1061
00:38:48,400 --> 00:38:51,480
and every subsequent AI project inherits that connectivity for free.

1062
00:38:51,480 --> 00:38:54,040
The organizations that will dominate the agentic era

1063
00:38:54,040 --> 00:38:56,760
are the ones that invest in their MCP layer first,

1064
00:38:56,760 --> 00:38:58,680
not because the protocol is exciting,

1065
00:38:58,680 --> 00:38:59,800
but because it compounds,

1066
00:38:59,800 --> 00:39:01,680
every agent you deploy gets cheaper,

1067
00:39:01,680 --> 00:39:03,240
every integration gets faster,

1068
00:39:03,240 --> 00:39:05,920
and your AI strategy stops being a collection of brittle,

1069
00:39:05,920 --> 00:39:07,320
point-to-point connections,

1070
00:39:07,320 --> 00:39:09,520
and starts being a composable capability platform.

1071
00:39:09,520 --> 00:39:11,280
That's why Microsoft is betting on MCP,

1072
00:39:11,280 --> 00:39:13,080
not as a feature, as a foundation,

1073
00:39:13,080 --> 00:39:15,320
from local dev to Azure production.

1074
00:39:15,320 --> 00:39:16,880
Let's get specific about Azure.

1075
00:39:16,880 --> 00:39:18,960
Because this is where most architects get stuck,

1076
00:39:18,960 --> 00:39:21,560
they build a beautiful MCP server on their laptop,

1077
00:39:21,560 --> 00:39:23,000
it works in STDO mode.

1078
00:39:23,000 --> 00:39:24,800
The local agent discovers the tools,

1079
00:39:24,800 --> 00:39:27,440
the tool calls, return, perfect structured data,

1080
00:39:27,440 --> 00:39:29,240
and then they try to deploy it to Azure

1081
00:39:29,240 --> 00:39:30,480
and everything falls apart,

1082
00:39:30,480 --> 00:39:31,960
not because Azure is hard,

1083
00:39:31,960 --> 00:39:33,760
but because the mental model changes.

1084
00:39:33,760 --> 00:39:35,760
Local development is about getting it working,

1085
00:39:35,760 --> 00:39:38,200
production deployment is about keeping it working at scale.

1086
00:39:38,200 --> 00:39:40,080
Let's walk through the Azure deployment patterns

1087
00:39:40,080 --> 00:39:42,000
that make sense for MCP servers.

1088
00:39:42,000 --> 00:39:44,920
Azure Functions is the simplest starting point for most use cases.

1089
00:39:44,920 --> 00:39:46,480
You write an HTTP triggered function

1090
00:39:46,480 --> 00:39:50,240
that receives MCP requests and returns MCP responses.

1091
00:39:50,240 --> 00:39:51,280
The functions runtime,

1092
00:39:51,280 --> 00:39:53,480
handle scaling, load balancing, and monitoring.

1093
00:39:53,480 --> 00:39:54,720
You pay per execution,

1094
00:39:54,720 --> 00:39:57,800
and when nobody is using your MCP server, it scales to zero.

1095
00:39:57,800 --> 00:40:01,040
This is ideal for MCP servers with sporadic usage patterns.

1096
00:40:01,040 --> 00:40:03,200
A server that handles approval workflows

1097
00:40:03,200 --> 00:40:05,840
might only receive a few hundred requests per day.

1098
00:40:05,840 --> 00:40:08,800
Running it on functions means you don't pay for idle capacity.

1099
00:40:08,800 --> 00:40:11,360
And when usage spikes function scales automatically,

1100
00:40:11,360 --> 00:40:13,440
the implementation pattern is straightforward.

1101
00:40:13,440 --> 00:40:15,240
Your function receives an HTTP post

1102
00:40:15,240 --> 00:40:17,160
containing a JSON RPC request.

1103
00:40:17,160 --> 00:40:19,200
It passes the method name and parameters.

1104
00:40:19,200 --> 00:40:20,840
It routes to the appropriate tool handler.

1105
00:40:20,840 --> 00:40:22,200
It executes the business logic.

1106
00:40:22,200 --> 00:40:23,800
It serializes the result.

1107
00:40:23,800 --> 00:40:25,640
And it returns an HTTP response

1108
00:40:25,640 --> 00:40:27,840
with the JSON RPC response object.

1109
00:40:27,840 --> 00:40:30,840
For streamable HTTP, you need to handle session management.

1110
00:40:30,840 --> 00:40:32,800
When a client initializes a connection,

1111
00:40:32,800 --> 00:40:34,520
you assign a session identifier.

1112
00:40:34,520 --> 00:40:38,360
You store the session state in Azure cache for Radys or Cosmos DB.

1113
00:40:38,360 --> 00:40:40,360
Subsequent requests include the session ID

1114
00:40:40,360 --> 00:40:41,960
and your function retrieves the state

1115
00:40:41,960 --> 00:40:43,360
to continue the conversation.

1116
00:40:43,360 --> 00:40:45,120
Azure Container Apps is the next step up.

1117
00:40:45,120 --> 00:40:47,080
If your MCP server needs persistent state,

1118
00:40:47,080 --> 00:40:49,400
long running connections or complex dependency graphs,

1119
00:40:49,400 --> 00:40:51,040
functions might feel constraining.

1120
00:40:51,040 --> 00:40:52,840
Container Apps gives you a fully managed

1121
00:40:52,840 --> 00:40:54,160
Kubernetes-like environment

1122
00:40:54,160 --> 00:40:55,920
without the Kubernetes complexity.

1123
00:40:55,920 --> 00:40:58,200
You containerize your MCP server application.

1124
00:40:58,200 --> 00:40:59,720
You define the container image,

1125
00:40:59,720 --> 00:41:02,240
the resource requirements, and the scaling rules.

1126
00:41:02,240 --> 00:41:03,600
Azure Deploys it, monitors it,

1127
00:41:03,600 --> 00:41:07,240
and scales it based on HTTP request volume or custom metrics.

1128
00:41:07,240 --> 00:41:09,440
Container Apps is ideal when your MCP server

1129
00:41:09,440 --> 00:41:12,080
maintains a connection pool to back-end databases

1130
00:41:12,080 --> 00:41:15,040
when it caches resource data in memory for fast access.

1131
00:41:15,040 --> 00:41:16,800
Or when it needs to run background tasks

1132
00:41:16,800 --> 00:41:18,680
alongside the main request processing.

1133
00:41:19,440 --> 00:41:21,640
Azure API management sits in front of both.

1134
00:41:21,640 --> 00:41:24,760
You don't want to expose your MCP servers directly to the internet.

1135
00:41:24,760 --> 00:41:25,840
You want a gateway.

1136
00:41:25,840 --> 00:41:27,600
API management provides that gateway.

1137
00:41:27,600 --> 00:41:29,200
It handles authentication at the edge.

1138
00:41:29,200 --> 00:41:31,960
It validates baritokens against Microsoft Entra.

1139
00:41:31,960 --> 00:41:33,920
It applies rate limiting to prevent abuse.

1140
00:41:33,920 --> 00:41:36,040
It transforms requests if your back-end servers

1141
00:41:36,040 --> 00:41:37,200
need a different format.

1142
00:41:37,200 --> 00:41:39,920
And it logs every request for auditing and monitoring.

1143
00:41:39,920 --> 00:41:40,920
With API management,

1144
00:41:40,920 --> 00:41:44,040
you can publish multiple MCP servers through a single endpoint.

1145
00:41:44,040 --> 00:41:45,760
The client connects to one URL.

1146
00:41:45,760 --> 00:41:48,680
API management routes the request to the appropriate back-end,

1147
00:41:48,680 --> 00:41:51,520
based on the path, the headers, or the payload content.

1148
00:41:51,520 --> 00:41:54,720
You can add new MCP servers without changing the client configuration.

1149
00:41:54,720 --> 00:41:57,320
You can update back-end servers without taking down the gateway.

1150
00:41:57,320 --> 00:41:59,680
This is the pattern you want for multi-server deployments.

1151
00:41:59,680 --> 00:42:01,200
Azure Key Vault stores your secrets.

1152
00:42:01,200 --> 00:42:03,840
MCP servers need connection strings to databases.

1153
00:42:03,840 --> 00:42:06,240
They need API keys for third-party services.

1154
00:42:06,240 --> 00:42:08,000
They need certificates for mutual TLS.

1155
00:42:08,000 --> 00:42:09,800
You don't hard-code these in your application.

1156
00:42:09,800 --> 00:42:11,560
You store them in Key Vault.

1157
00:42:11,560 --> 00:42:13,240
Your application reads them at start-up.

1158
00:42:13,240 --> 00:42:15,720
And when a secret rotates, you update it in one place

1159
00:42:15,720 --> 00:42:17,320
without redeploying your code.

1160
00:42:17,320 --> 00:42:19,600
Application Insights provides observability.

1161
00:42:19,600 --> 00:42:21,760
Every MCP request, every tool invocation,

1162
00:42:21,760 --> 00:42:24,440
every error is logged to application Insights.

1163
00:42:24,440 --> 00:42:25,720
You see request latency.

1164
00:42:25,720 --> 00:42:26,520
You see error rates.

1165
00:42:26,520 --> 00:42:28,560
You see which tools are called most frequently.

1166
00:42:28,560 --> 00:42:30,840
You see which agents are generating the most load.

1167
00:42:30,840 --> 00:42:33,280
And you can set up alerts for anomalous patterns.

1168
00:42:33,280 --> 00:42:37,760
This observability is critical because MCP servers are infrastructure

1169
00:42:37,760 --> 00:42:39,400
when they fail agents fail.

1170
00:42:39,400 --> 00:42:41,080
And when agents fail, users notice.

1171
00:42:41,080 --> 00:42:43,280
You need monitoring that tells you something is wrong

1172
00:42:43,280 --> 00:42:44,520
before the users do.

1173
00:42:44,520 --> 00:42:46,280
For network isolation, VNet integration

1174
00:42:46,280 --> 00:42:49,080
keeps MCP traffic inside your network boundary.

1175
00:42:49,080 --> 00:42:50,880
Your MCP servers run in a subnet that

1176
00:42:50,880 --> 00:42:52,640
has no public internet access.

1177
00:42:52,640 --> 00:42:55,400
API management has a private endpoint in the same VNet.

1178
00:42:55,400 --> 00:42:57,360
Agents connect through the private endpoint.

1179
00:42:57,360 --> 00:42:59,720
The traffic never traverses the public internet.

1180
00:42:59,720 --> 00:43:02,120
And your network security team can apply the same policies

1181
00:43:02,120 --> 00:43:04,240
they use for every other internal API.

1182
00:43:04,240 --> 00:43:06,840
For scaling patterns, you need to match the Azure service

1183
00:43:06,840 --> 00:43:08,120
to the workload shape.

1184
00:43:08,120 --> 00:43:09,880
As your functions with a consumption plan

1185
00:43:09,880 --> 00:43:12,840
is ideal for bursty, low-frequency workloads.

1186
00:43:12,840 --> 00:43:16,000
If your agents invoke tools sporadically, consumption plan

1187
00:43:16,000 --> 00:43:17,800
means you pay nothing during idle periods

1188
00:43:17,800 --> 00:43:20,280
and scale automatically when traffic arrives.

1189
00:43:20,280 --> 00:43:22,440
But cold start latency can be several seconds

1190
00:43:22,440 --> 00:43:23,880
for complex applications.

1191
00:43:23,880 --> 00:43:26,600
If your agents are interactive, those seconds matter.

1192
00:43:26,600 --> 00:43:29,320
For interactive agents that need sub-second responses,

1193
00:43:29,320 --> 00:43:31,640
use Azure Functions with a premium plan.

1194
00:43:31,640 --> 00:43:33,360
Premium plan keeps instances warm.

1195
00:43:33,360 --> 00:43:35,000
It eliminates cold start latency.

1196
00:43:35,000 --> 00:43:37,520
And it supports VNet integration for private connectivity.

1197
00:43:37,520 --> 00:43:38,600
The tradeoff is cost.

1198
00:43:38,600 --> 00:43:42,000
You pay for the warm instances even when idle.

1199
00:43:42,000 --> 00:43:43,960
Azure Container Apps is the middle ground.

1200
00:43:43,960 --> 00:43:46,080
It scales to zero like consumption functions.

1201
00:43:46,080 --> 00:43:48,120
But it warms containers faster than functions

1202
00:43:48,120 --> 00:43:50,200
because the container image is already pulled

1203
00:43:50,200 --> 00:43:51,880
and the runtime is already initialized.

1204
00:43:51,880 --> 00:43:53,760
For MCP servers that need persistent state

1205
00:43:53,760 --> 00:43:55,280
or complex dependency graphs,

1206
00:43:55,280 --> 00:43:57,080
Container Apps is often the right choice.

1207
00:43:57,080 --> 00:44:00,400
For very high throughput, consider Azure Kubernetes service.

1208
00:44:00,400 --> 00:44:03,000
AKS gives you full control over the orchestration layer.

1209
00:44:03,000 --> 00:44:04,600
You define the pod specifications.

1210
00:44:04,600 --> 00:44:06,960
You configure the horizontal pod auto-scaler.

1211
00:44:06,960 --> 00:44:08,280
You manage the node pools.

1212
00:44:08,280 --> 00:44:10,440
And you optimize every layer of the stack

1213
00:44:10,440 --> 00:44:13,680
for your specific latency and throughput requirements.

1214
00:44:13,680 --> 00:44:15,520
The tradeoff is operational complexity.

1215
00:44:15,520 --> 00:44:17,480
AKS requires Kubernetes expertise

1216
00:44:17,480 --> 00:44:19,520
and it requires ongoing cluster management.

1217
00:44:19,520 --> 00:44:22,440
Most MCP deployments start with functions or Container Apps

1218
00:44:22,440 --> 00:44:25,200
and graduate to AKS only when the workload demands it.

1219
00:44:25,200 --> 00:44:28,000
For deployment automation, Azure DevOps and GitHub actions

1220
00:44:28,000 --> 00:44:30,960
both support CI/CD pipelines for MCP servers.

1221
00:44:30,960 --> 00:44:31,840
You commit code.

1222
00:44:31,840 --> 00:44:33,080
The pipeline builds the project.

1223
00:44:33,080 --> 00:44:34,080
It runs unit tests.

1224
00:44:34,080 --> 00:44:35,400
It packages the application.

1225
00:44:35,400 --> 00:44:37,280
It deploys to a staging environment.

1226
00:44:37,280 --> 00:44:39,920
It runs integration tests against a real MCP client.

1227
00:44:39,920 --> 00:44:42,520
And if everything passes, it deploys to production.

1228
00:44:42,520 --> 00:44:44,240
Blue Green deployment is the pattern you want

1229
00:44:44,240 --> 00:44:45,720
for zero downtime updates.

1230
00:44:45,720 --> 00:44:47,360
You run two identical environments.

1231
00:44:47,360 --> 00:44:48,400
Blue is production.

1232
00:44:48,400 --> 00:44:49,440
Green is staging.

1233
00:44:49,440 --> 00:44:51,840
When you deploy a new version, you push it to green.

1234
00:44:51,840 --> 00:44:53,160
You verify it works.

1235
00:44:53,160 --> 00:44:56,200
You switch the API management routing from blue to green.

1236
00:44:56,200 --> 00:44:58,440
And the old version stays running as a hot standby

1237
00:44:58,440 --> 00:45:00,840
until you're confident the new version is stable.

1238
00:45:00,840 --> 00:45:03,760
This matters for MCP because agents maintain session state.

1239
00:45:03,760 --> 00:45:05,320
If you restart a server mid-session,

1240
00:45:05,320 --> 00:45:06,800
the client loses its context.

1241
00:45:06,800 --> 00:45:08,160
It has to re-initialize.

1242
00:45:08,160 --> 00:45:09,440
It has to rediscover tools.

1243
00:45:09,440 --> 00:45:11,840
And if the new server version has different capabilities,

1244
00:45:11,840 --> 00:45:14,240
the agent's reasoning might change unexpectedly.

1245
00:45:14,240 --> 00:45:15,920
Blue Green deployment avoids this.

1246
00:45:15,920 --> 00:45:17,640
The switch happens at the routing layer.

1247
00:45:17,640 --> 00:45:19,480
Active sessions stay on the old version.

1248
00:45:19,480 --> 00:45:21,080
New sessions go to the new version.

1249
00:45:21,080 --> 00:45:23,240
And after a grace period, you retire the old version.

1250
00:45:23,240 --> 00:45:25,080
That's the Azure deployment pattern.

1251
00:45:25,080 --> 00:45:27,240
Functions or container apps for compute.

1252
00:45:27,240 --> 00:45:28,680
API management for the gateway.

1253
00:45:28,680 --> 00:45:30,040
Key vault for secrets.

1254
00:45:30,040 --> 00:45:31,920
Application insights for monitoring.

1255
00:45:31,920 --> 00:45:33,600
VNet integration for security.

1256
00:45:33,600 --> 00:45:35,200
CI/CD for deployment.

1257
00:45:35,200 --> 00:45:36,520
Blue Green for updates.

1258
00:45:36,520 --> 00:45:37,280
It's not exotic.

1259
00:45:37,280 --> 00:45:40,280
It's standard as your architecture applied to a new protocol.

1260
00:45:40,280 --> 00:45:41,160
And that's the point.

1261
00:45:41,160 --> 00:45:44,600
MCP doesn't require you to invent new infrastructure patterns.

1262
00:45:44,600 --> 00:45:47,000
It fits into the patterns you already know.

1263
00:45:47,000 --> 00:45:50,320
Connecting co-pilot studio to MCP servers.

1264
00:45:50,320 --> 00:45:54,280
Now let's look at where MCP meets the tools your users already know.

1265
00:45:54,280 --> 00:45:56,680
Co-pilot studio, Microsoft co-pilot studio

1266
00:45:56,680 --> 00:45:58,640
added model context protocol support

1267
00:45:58,640 --> 00:46:01,640
and took it to general availability in March, 2026.

1268
00:46:01,640 --> 00:46:02,960
This wasn't a quiet feature launch.

1269
00:46:02,960 --> 00:46:03,920
It was a signal.

1270
00:46:03,920 --> 00:46:07,000
Microsoft is treating MCP as a first class integration pattern

1271
00:46:07,000 --> 00:46:08,520
for business agents.

1272
00:46:08,520 --> 00:46:10,320
The GA release included three capabilities

1273
00:46:10,320 --> 00:46:11,560
that matter for architects.

1274
00:46:11,560 --> 00:46:12,520
Tool listing.

1275
00:46:12,520 --> 00:46:15,360
Your co-pilot studio agents can discover and display tools

1276
00:46:15,360 --> 00:46:16,880
from connected MCP servers.

1277
00:46:16,880 --> 00:46:19,360
When an agent initializes, it queries the MCP server

1278
00:46:19,360 --> 00:46:20,760
for its tool catalog.

1279
00:46:20,760 --> 00:46:23,120
Each tool appears in the agent's reasoning pipeline

1280
00:46:23,120 --> 00:46:25,160
with its description and parameter schema.

1281
00:46:25,160 --> 00:46:29,000
The agent decides which tools to invoke based on the user's intent.

1282
00:46:29,000 --> 00:46:30,560
Enhanced tracing.

1283
00:46:30,560 --> 00:46:33,480
When an agent invokes an MCP tool, co-pilot studio

1284
00:46:33,480 --> 00:46:36,120
logs the request, the parameters, the response,

1285
00:46:36,120 --> 00:46:36,960
and any errors.

1286
00:46:36,960 --> 00:46:38,560
This isn't just debugging information.

1287
00:46:38,560 --> 00:46:39,760
It's audit-diter.

1288
00:46:39,760 --> 00:46:42,160
You can see which agents called which tools.

1289
00:46:42,160 --> 00:46:43,520
You can trace a user's request

1290
00:46:43,520 --> 00:46:45,840
through the entire chain of tool invocations.

1291
00:46:45,840 --> 00:46:49,160
And you can identify which tools fail most frequently.

1292
00:46:49,160 --> 00:46:50,840
Scalable deployment infrastructure.

1293
00:46:50,840 --> 00:46:52,760
The GA release added backend improvements

1294
00:46:52,760 --> 00:46:54,720
that let co-pilot studio handle large numbers

1295
00:46:54,720 --> 00:46:57,280
of concurrent MCP connections.

1296
00:46:57,280 --> 00:46:58,760
This matters because enterprise agents

1297
00:46:58,760 --> 00:47:00,920
serve thousands of users simultaneously.

1298
00:47:00,920 --> 00:47:03,800
If the MCP integration was built for demo scale loads,

1299
00:47:03,800 --> 00:47:05,320
it would collapse in production.

1300
00:47:05,320 --> 00:47:07,840
The GA release is built for production scale.

1301
00:47:07,840 --> 00:47:09,960
Connecting an MCP server to co-pilot studio

1302
00:47:09,960 --> 00:47:12,640
is a configuration task, not a development project.

1303
00:47:12,640 --> 00:47:14,360
You provide the server endpoint.

1304
00:47:14,360 --> 00:47:16,280
You configure the authentication method,

1305
00:47:16,280 --> 00:47:18,600
typically a Microsoft Entra Service principle,

1306
00:47:18,600 --> 00:47:20,760
or an API key stored in Key Vault.

1307
00:47:20,760 --> 00:47:22,680
You set the protocol version you want to use.

1308
00:47:22,680 --> 00:47:24,640
And co-pilot studio handles the rest.

1309
00:47:24,640 --> 00:47:26,960
The agent discovers the tools automatically.

1310
00:47:26,960 --> 00:47:28,920
It adds them to its reasoning context.

1311
00:47:28,920 --> 00:47:31,640
And when a user asks a question that requires tool access,

1312
00:47:31,640 --> 00:47:33,400
the agent invokes the appropriate tool

1313
00:47:33,400 --> 00:47:34,720
through the MCP protocol.

1314
00:47:34,720 --> 00:47:36,960
This means your existing co-pilot studio agents

1315
00:47:36,960 --> 00:47:39,240
get new capabilities without rewriting them.

1316
00:47:39,240 --> 00:47:42,600
If you build an MCP server that exposes inventory lookup,

1317
00:47:42,600 --> 00:47:45,120
every co-pilot studio agent you connect to that server

1318
00:47:45,120 --> 00:47:46,600
can now check inventory.

1319
00:47:46,600 --> 00:47:48,960
If you add a tool for approval workflow status,

1320
00:47:48,960 --> 00:47:51,000
every agent can now track approvals.

1321
00:47:51,000 --> 00:47:52,840
If you add a tool for document generation

1322
00:47:52,840 --> 00:47:55,760
with sensitivity labels, every agent can now draft

1323
00:47:55,760 --> 00:47:57,000
compliant documents.

1324
00:47:57,000 --> 00:47:57,960
The agents don't change.

1325
00:47:57,960 --> 00:47:59,600
The MCP server changes.

1326
00:47:59,600 --> 00:48:01,640
And the agents inherit the new capabilities

1327
00:48:01,640 --> 00:48:02,760
through discovery.

1328
00:48:02,760 --> 00:48:05,840
Microsoft also published a model context protocol lab on GitHub

1329
00:48:05,840 --> 00:48:07,440
in April 2025.

1330
00:48:07,440 --> 00:48:09,720
This is a hands-on repository with sample servers,

1331
00:48:09,720 --> 00:48:11,840
client configurations, and exercises

1332
00:48:11,840 --> 00:48:13,760
specifically for co-pilot studio.

1333
00:48:13,760 --> 00:48:16,000
If you're evaluating MCP for your organization,

1334
00:48:16,000 --> 00:48:16,680
start here.

1335
00:48:16,680 --> 00:48:18,560
The lab gives you a working end-to-end connection

1336
00:48:18,560 --> 00:48:19,560
in under an hour.

1337
00:48:19,560 --> 00:48:22,280
And the integration goes beyond co-pilot studio itself.

1338
00:48:22,280 --> 00:48:24,280
Dynamics 365, Finance and Operations

1339
00:48:24,280 --> 00:48:27,080
added MCP server support in April, 2026.

1340
00:48:27,080 --> 00:48:29,200
This means you can extend your ERP agents

1341
00:48:29,200 --> 00:48:31,600
with custom tools through the same protocol.

1342
00:48:31,600 --> 00:48:34,160
Your supply chain agent can query an MCP server

1343
00:48:34,160 --> 00:48:36,280
that knows your custom procurement rules.

1344
00:48:36,280 --> 00:48:38,560
Your finance agent can invoke tools that understand

1345
00:48:38,560 --> 00:48:40,320
your chart of accounts or structure.

1346
00:48:40,320 --> 00:48:42,800
Your manufacturing agent can check production schedules

1347
00:48:42,800 --> 00:48:45,400
through tools that integrate with your shop floor systems.

1348
00:48:45,400 --> 00:48:48,520
This isn't a replacement for Dynamics 365's native capabilities.

1349
00:48:48,520 --> 00:48:49,520
It's an extension patent.

1350
00:48:49,520 --> 00:48:51,880
Dynamics provides the standard ERP functions.

1351
00:48:51,880 --> 00:48:54,720
MCP servers provide the custom business logic

1352
00:48:54,720 --> 00:48:58,360
that makes your ERP fit your organization's specific processes.

1353
00:48:58,360 --> 00:49:01,360
And agents combine both through a single reasoning pipeline.

1354
00:49:01,360 --> 00:49:03,880
The practical workflow for an architect looks like this.

1355
00:49:03,880 --> 00:49:06,520
You identify the gaps in your current co-pilot agents.

1356
00:49:06,520 --> 00:49:09,600
What questions do users ask that the agents can't answer?

1357
00:49:09,600 --> 00:49:12,600
What actions do users request that require back-end system access?

1358
00:49:12,600 --> 00:49:13,880
You catalog these gaps.

1359
00:49:13,880 --> 00:49:15,960
You prioritize them by business impact.

1360
00:49:15,960 --> 00:49:18,720
And for each priority gap, you build an MCP tool.

1361
00:49:18,720 --> 00:49:20,800
Then you deploy the MCP server to Azure.

1362
00:49:20,800 --> 00:49:22,600
You register it in co-pilot studio.

1363
00:49:22,600 --> 00:49:24,920
You test the agent's behavior with the new tools.

1364
00:49:24,920 --> 00:49:28,440
You refine the tool descriptions so the agent knows when to invoke them.

1365
00:49:28,440 --> 00:49:30,320
You tune the parameter schemas so the agent

1366
00:49:30,320 --> 00:49:31,840
provides the right inputs.

1367
00:49:31,840 --> 00:49:34,480
And you monitor the tool usage to see which ones deliver value.

1368
00:49:34,480 --> 00:49:36,040
This is an iterative cycle.

1369
00:49:36,040 --> 00:49:37,800
Not a big bang integration project.

1370
00:49:37,800 --> 00:49:40,240
You start with one tool, one server, one agent.

1371
00:49:40,240 --> 00:49:41,640
You prove the patent works.

1372
00:49:41,640 --> 00:49:42,720
Then you expand.

1373
00:49:42,720 --> 00:49:44,560
The configuration details in co-pilot studio

1374
00:49:44,560 --> 00:49:47,520
are worth understanding because they're not obvious from the documentation.

1375
00:49:47,520 --> 00:49:51,000
When you register an MCP server, you provide the endpoint URL.

1376
00:49:51,000 --> 00:49:53,600
This is the URL of your Azure Function, Container App,

1377
00:49:53,600 --> 00:49:55,200
or API Management Gateway.

1378
00:49:55,200 --> 00:49:58,120
Not the direct back end server URL if you're using a gateway.

1379
00:49:58,120 --> 00:49:59,560
The agent talks to the gateway.

1380
00:49:59,560 --> 00:50:01,200
The gateway talks to the server.

1381
00:50:01,200 --> 00:50:03,600
You also provide the authentication configuration.

1382
00:50:03,600 --> 00:50:04,720
There are two common patterns.

1383
00:50:04,720 --> 00:50:07,080
The first is Microsoft Entra Service Principle.

1384
00:50:07,080 --> 00:50:08,560
You register an app in Entra.

1385
00:50:08,560 --> 00:50:09,560
You granted permissions.

1386
00:50:09,560 --> 00:50:12,000
You create a client secret or a certificate.

1387
00:50:12,000 --> 00:50:15,920
And you configure co-pilot studio to acquire tokens using that service principle.

1388
00:50:15,920 --> 00:50:17,520
The second pattern is API key.

1389
00:50:17,520 --> 00:50:19,800
You generate a key in Azure API Management

1390
00:50:19,800 --> 00:50:21,240
or in your server's key store.

1391
00:50:21,240 --> 00:50:25,160
And you configure co-pilot studio to send that key in the authorization header.

1392
00:50:25,160 --> 00:50:27,240
The service principle pattern is more secure.

1393
00:50:27,240 --> 00:50:28,680
The API key pattern is simpler.

1394
00:50:28,680 --> 00:50:30,600
For production, use service principles.

1395
00:50:30,600 --> 00:50:34,600
For prototyping, API keys are acceptable if you rotate them before going live.

1396
00:50:34,600 --> 00:50:36,360
You also set the protocol version.

1397
00:50:36,360 --> 00:50:39,240
Co-pilot studio supports multiple protocol versions.

1398
00:50:39,240 --> 00:50:41,560
You set the version that matches your server.

1399
00:50:41,560 --> 00:50:45,160
If your server implements 2025, 1125, you set that in co-pilot studio.

1400
00:50:45,160 --> 00:50:48,920
If your server implements 2025, 0618, you set that.

1401
00:50:48,920 --> 00:50:52,560
The client and server negotiate capabilities within that version.

1402
00:50:52,560 --> 00:50:55,640
But the version setting tells co-pilot studio what message format to expect.

1403
00:50:55,640 --> 00:50:58,760
After registration, co-pilot studio performs a discovery call.

1404
00:50:58,760 --> 00:51:00,720
It sends an initialized request to your server.

1405
00:51:00,720 --> 00:51:05,920
It requests the tool catalog and it populates the agent's reasoning context with the available tools.

1406
00:51:05,920 --> 00:51:09,680
This discovery happens at agent startup or when you manually refresh the connection.

1407
00:51:09,680 --> 00:51:11,920
If discovery fails, the tools don't appear.

1408
00:51:11,920 --> 00:51:14,240
And the agent behaves as if the server doesn't exist.

1409
00:51:14,240 --> 00:51:16,040
This is usually an authentication problem.

1410
00:51:16,040 --> 00:51:18,160
The service principle might not have permission.

1411
00:51:18,160 --> 00:51:19,520
The API key might be wrong.

1412
00:51:19,520 --> 00:51:23,120
The network firewall might block the connection or the server might be down.

1413
00:51:23,120 --> 00:51:27,480
The bugging discovery failure requires checking three things, the network path, the authentication

1414
00:51:27,480 --> 00:51:30,720
token, and the server's initialization response.

1415
00:51:30,720 --> 00:51:33,840
Application insights, logs on the server side show the incoming requests.

1416
00:51:33,840 --> 00:51:36,880
Entra sign-in logs show the token acquisition attempts.

1417
00:51:36,880 --> 00:51:39,920
And co-pilot studio's connection test shows the discovery result.

1418
00:51:39,920 --> 00:51:42,200
Once discovery succeeds, testing is straightforward.

1419
00:51:42,200 --> 00:51:45,840
You open the agent in test mode, you ask a question that requires the new tool.

1420
00:51:45,840 --> 00:51:49,600
You watch the agent's reasoning trace, you see which tools it considers, you see which

1421
00:51:49,600 --> 00:51:53,080
tool it selects, you see the parameters it provides, and you see the response.

1422
00:51:53,080 --> 00:51:54,080
It receives.

1423
00:51:54,080 --> 00:51:57,520
If the agent selects the wrong tool, your tool description is probably too vague.

1424
00:51:57,520 --> 00:52:01,720
If the agent provides wrong parameters, your parameter schema might be too complex or

1425
00:52:01,720 --> 00:52:02,880
poorly named.

1426
00:52:02,880 --> 00:52:06,520
If the agent ignores the tool entirely, it might not recognize that the user's question

1427
00:52:06,520 --> 00:52:08,520
maps to the tools capability.

1428
00:52:08,520 --> 00:52:09,840
Tuning is iterative.

1429
00:52:09,840 --> 00:52:13,800
You adjust the description, you test again, you rename a parameter, you test again, you add

1430
00:52:13,800 --> 00:52:17,600
an example to the description, you test again, each cycle takes minutes.

1431
00:52:17,600 --> 00:52:21,200
And after a few cycles, the agent invokes the tool reliably.

1432
00:52:21,200 --> 00:52:24,760
This tuning process is one of the most important skills for MCP architects.

1433
00:52:24,760 --> 00:52:29,440
Because a perfectly built server is useless if the agent doesn't know when to use it.

1434
00:52:29,440 --> 00:52:30,440
Work IQ.

1435
00:52:30,440 --> 00:52:32,680
The intelligence layer and MCP server.

1436
00:52:32,680 --> 00:52:35,160
But co-pilot studio is only half the story.

1437
00:52:35,160 --> 00:52:38,440
The real power is what your agents can understand about your business.

1438
00:52:38,440 --> 00:52:39,840
And that's where Work IQ comes in.

1439
00:52:39,840 --> 00:52:43,240
Work IQ is Microsoft's intelligence layer for the agentic era.

1440
00:52:43,240 --> 00:52:47,320
It's the semantic engine that reads everything happening across your Microsoft 365 environment

1441
00:52:47,320 --> 00:52:50,640
and turns it into context that agents can reason over.

1442
00:52:50,640 --> 00:52:56,600
PowerPoint documents, one drive files, Teams conversations, email threads, meeting transcripts,

1443
00:52:56,600 --> 00:52:59,960
calendar events, planner tasks, loop pages.

1444
00:52:59,960 --> 00:53:02,840
Work IQ understands the relationships between all of these.

1445
00:53:02,840 --> 00:53:06,840
It knows that a Teams conversation is about a project that has a share point site that

1446
00:53:06,840 --> 00:53:10,160
contains a document that was discussed in a meeting that was scheduled by someone who

1447
00:53:10,160 --> 00:53:12,680
reports to a manager who approved the budget.

1448
00:53:12,680 --> 00:53:15,440
That's not keyword search, that's semantic understanding.

1449
00:53:15,440 --> 00:53:19,160
And Microsoft opensource the Work IQ MCP server on GitHub at GitHub.

1450
00:53:19,160 --> 00:53:20,960
And Microsoft Work IQ.

1451
00:53:20,960 --> 00:53:25,840
This means any agent that speaks MCP can access Work IQ context, not just co-pilot, not

1452
00:53:25,840 --> 00:53:28,800
just Microsoft agents, any MCP compatible client.

1453
00:53:28,800 --> 00:53:31,560
The Work IQ MCP server exposes six core tools.

1454
00:53:31,560 --> 00:53:33,800
It can retrieve organizational context.

1455
00:53:33,800 --> 00:53:34,880
Who works on which team?

1456
00:53:34,880 --> 00:53:35,920
Who reports to whom?

1457
00:53:35,920 --> 00:53:37,120
What projects are active?

1458
00:53:37,120 --> 00:53:38,520
What goals are being tracked?

1459
00:53:38,520 --> 00:53:42,720
It can pull document content from SharePoint and OneDrive with full semantic understanding.

1460
00:53:42,720 --> 00:53:46,560
It can read Teams conversations and email threads and extract the key decisions and action

1461
00:53:46,560 --> 00:53:47,560
items.

1462
00:53:47,560 --> 00:53:50,720
It can access meeting transcripts and identify who committed to what.

1463
00:53:50,720 --> 00:53:54,120
It can query calendar data and understand availability patterns.

1464
00:53:54,120 --> 00:53:58,600
And it can draft word documents that carry your existing sensitivity labels and compliance

1465
00:53:58,600 --> 00:53:59,800
metadata.

1466
00:53:59,800 --> 00:54:02,200
This last point is critical for enterprise deployments.

1467
00:54:02,200 --> 00:54:06,280
When an agent drafts a document through Work IQ, the resulting file inherits the sensitivity

1468
00:54:06,280 --> 00:54:08,440
label from the template or the parent folder.

1469
00:54:08,440 --> 00:54:12,560
If the document contains financial data, it gets the confidential label automatically.

1470
00:54:12,560 --> 00:54:15,520
If it contains public marketing content, it gets the public label.

1471
00:54:15,520 --> 00:54:18,880
The agent doesn't need to understand your data classification scheme.

1472
00:54:18,880 --> 00:54:22,200
Work IQ applies it through the existing Microsoft purview policies.

1473
00:54:22,200 --> 00:54:24,480
Work IQ also supports multiple protocols.

1474
00:54:24,480 --> 00:54:26,320
The rest API gives you raw access.

1475
00:54:26,320 --> 00:54:30,160
The A2A protocol lets agents delegate tasks to work IQ as a peer.

1476
00:54:30,160 --> 00:54:35,640
And the MCP protocol lets agents discover work IQ capabilities as tools and invoke them

1477
00:54:35,640 --> 00:54:38,040
through the standard JSON RPC contract.

1478
00:54:38,040 --> 00:54:42,280
For architects, the MCP integration is the most important because it means Work IQ becomes

1479
00:54:42,280 --> 00:54:44,800
just another MCP server in your architecture.

1480
00:54:44,800 --> 00:54:47,160
For agents don't need custom code to talk to Work IQ.

1481
00:54:47,160 --> 00:54:49,680
They use the same protocol they use for every other server.

1482
00:54:49,680 --> 00:54:52,800
They discover work IQ tools during initialization.

1483
00:54:52,800 --> 00:54:55,320
They invoke them through the same request pipeline.

1484
00:54:55,320 --> 00:54:58,920
And they receive structured responses through the same de-serialization logic.

1485
00:54:58,920 --> 00:55:02,280
This uniformity is what makes MCP powerful at scale.

1486
00:55:02,280 --> 00:55:07,280
Your agents don't care whether a tool talks to SharePoint, SQL Server or an internal line

1487
00:55:07,280 --> 00:55:08,440
of business application.

1488
00:55:08,440 --> 00:55:10,680
They see a capability catalog, they select a tool.

1489
00:55:10,680 --> 00:55:14,080
They provide parameters, they receive results.

1490
00:55:14,080 --> 00:55:17,640
Work IQ is the tool that gives your agents organizational memory.

1491
00:55:17,640 --> 00:55:19,920
Without Work IQ, your agents reason in isolation.

1492
00:55:19,920 --> 00:55:22,680
They answer based on the prompt and their training data.

1493
00:55:22,680 --> 00:55:25,320
They don't know what your team discussed in yesterday's meeting.

1494
00:55:25,320 --> 00:55:27,720
They don't know that the project charter was updated last week.

1495
00:55:27,720 --> 00:55:30,800
They don't know that the budget was reallocated in the quarterly review.

1496
00:55:30,800 --> 00:55:32,360
With Work IQ, they do.

1497
00:55:32,360 --> 00:55:36,680
And because Work IQ updates in real time, your agents are always working with current context.

1498
00:55:36,680 --> 00:55:39,160
When a document changes, Work IQ sees the change.

1499
00:55:39,160 --> 00:55:41,840
When a meeting ends, Work IQ processes the transcript.

1500
00:55:41,840 --> 00:55:44,840
When an email arrives, Work IQ extracts the action items.

1501
00:55:44,840 --> 00:55:47,640
Your agents don't just have access to your business data.

1502
00:55:47,640 --> 00:55:49,400
They have access to your business reality.

1503
00:55:49,400 --> 00:55:52,440
A to a protocol agent to agent orchestration.

1504
00:55:52,440 --> 00:55:54,960
But what happens when you need multiple agents to work together?

1505
00:55:54,960 --> 00:55:59,080
Because most real world problems don't fit inside a single agent, a customer service request

1506
00:55:59,080 --> 00:56:02,880
might require an agent that understands the customer's history, an agent that checks

1507
00:56:02,880 --> 00:56:07,040
inventory levels, an agent that verifies pricing rules, and an agent that generates a

1508
00:56:07,040 --> 00:56:08,040
quote.

1509
00:56:08,040 --> 00:56:11,560
Each agent has its own expertise, its own tools, its own context.

1510
00:56:11,560 --> 00:56:13,000
And they need to collaborate.

1511
00:56:13,000 --> 00:56:14,480
This is where A2A comes in.

1512
00:56:14,480 --> 00:56:16,880
A2A stands for Agent to Agent Protocol.

1513
00:56:16,880 --> 00:56:21,400
Google launched it in April 2025 as an open standard for AI agent communication.

1514
00:56:21,400 --> 00:56:24,920
Microsoft announced support for A2A in May 2025.

1515
00:56:24,920 --> 00:56:30,440
And in June 2025, Google donated A2A to the Linux Foundation, where it now lives as a vendor

1516
00:56:30,440 --> 00:56:34,240
neutral project with founding members, including AWS and Cisco.

1517
00:56:34,240 --> 00:56:36,200
A2A is not a competitor to MCP.

1518
00:56:36,200 --> 00:56:37,760
It solves a completely different problem.

1519
00:56:37,760 --> 00:56:39,600
MCP connects agents to tools.

1520
00:56:39,600 --> 00:56:41,200
A2A connects agents to agents.

1521
00:56:41,200 --> 00:56:42,200
You need both.

1522
00:56:42,200 --> 00:56:46,520
A2A defines three core concepts that enable agent collaboration.

1523
00:56:46,520 --> 00:56:49,600
Agent cards are how an agent advertises its capabilities.

1524
00:56:49,600 --> 00:56:53,800
When an A2A compatible agent starts up, it publishes an agent card that describes what

1525
00:56:53,800 --> 00:57:00,000
it can do, what inputs it accepts, what outputs it produces, and what authentication it requires.

1526
00:57:00,000 --> 00:57:03,720
Other agents can discover this card and decide whether to delegate work to it.

1527
00:57:03,720 --> 00:57:05,760
Tasks are the work units that agents exchange.

1528
00:57:05,760 --> 00:57:09,200
When one agent needs another agent to do something, it creates a task.

1529
00:57:09,200 --> 00:57:12,520
The task includes the goal, the context, and any constraints.

1530
00:57:12,520 --> 00:57:17,400
The receiving agent processes the task and returns updates, results, or requests for additional

1531
00:57:17,400 --> 00:57:18,400
information.

1532
00:57:18,400 --> 00:57:24,120
The transport layer uses HTTP and JSON RPC 2.0, which means it aligns with the same infrastructure

1533
00:57:24,120 --> 00:57:25,120
patterns as MCP.

1534
00:57:25,120 --> 00:57:30,200
In fact, as streamable HTTP becomes the standard transport for MCP, the two protocols may converge

1535
00:57:30,200 --> 00:57:32,600
on the same underlying connection model.

1536
00:57:32,600 --> 00:57:36,680
The relationship between MCP and A2A is complementary and hierarchical.

1537
00:57:36,680 --> 00:57:42,160
At the bottom you have your business systems, ERP, CRM, SharePoint, Databases, MCP servers

1538
00:57:42,160 --> 00:57:44,520
expose these systems as tools.

1539
00:57:44,520 --> 00:57:48,680
Individual agents consume those tools through MCP to perform their specialized functions.

1540
00:57:48,680 --> 00:57:53,000
And A2A enables those specialized agents to collaborate on complex tasks that span multiple

1541
00:57:53,000 --> 00:57:54,000
domains.

1542
00:57:54,000 --> 00:57:56,960
In a Microsoft environment, this pattern is emerging rapidly.

1543
00:57:56,960 --> 00:57:59,960
A co-pilot studio agent might receive a user request.

1544
00:57:59,960 --> 00:58:03,560
It uses MCP to query work IQ for organizational context.

1545
00:58:03,560 --> 00:58:06,880
It uses A2A to delegate sub tasks to specialized agents.

1546
00:58:06,880 --> 00:58:10,120
One specialized agent checks inventory through an MCP server.

1547
00:58:10,120 --> 00:58:13,160
Another verifies pricing through a different MCP server.

1548
00:58:13,160 --> 00:58:16,000
A third generates the quote document through work IQ.

1549
00:58:16,000 --> 00:58:18,120
The co-pilot studio agent orchestrates.

1550
00:58:18,120 --> 00:58:20,040
The specialized agents execute.

1551
00:58:20,040 --> 00:58:22,000
The MCP servers provide the tools.

1552
00:58:22,000 --> 00:58:24,400
And A2A provides the coordination language.

1553
00:58:24,400 --> 00:58:29,320
Microsoft's support for A2A, announced in May 2025, signals that this multi-agent pattern

1554
00:58:29,320 --> 00:58:31,240
is part of their long term vision.

1555
00:58:31,240 --> 00:58:33,800
They're not just building a single agent that does everything.

1556
00:58:33,800 --> 00:58:37,280
They're building an ecosystem where agents specialize, collaborate and compose their

1557
00:58:37,280 --> 00:58:39,400
capabilities through open protocols.

1558
00:58:39,400 --> 00:58:43,440
For architects, this means your connectivity layer needs to support both protocols.

1559
00:58:43,440 --> 00:58:46,800
You need MCP servers that expose your business capabilities as tools.

1560
00:58:46,800 --> 00:58:50,520
You need agents that consume those tools to perform specialized functions.

1561
00:58:50,520 --> 00:58:54,960
And you need A2A infrastructure that lets those agents discover each other, delegate tasks,

1562
00:58:54,960 --> 00:58:55,960
and share results.

1563
00:58:55,960 --> 00:58:59,880
The good news is that both protocols use the same foundational technologies.

1564
00:58:59,880 --> 00:59:05,360
HTTP, JSON, RPC 2.0, standard authentication, Azure hosting, entry identity.

1565
00:59:05,360 --> 00:59:08,920
The infrastructure you build for MCP is largely reusable for A2A.

1566
00:59:08,920 --> 00:59:13,320
The Linux Foundation governance of A2A is also important because it means A2A isn't controlled

1567
00:59:13,320 --> 00:59:15,880
by Google or Microsoft or any single vendor.

1568
00:59:15,880 --> 00:59:18,000
It's an open standard with a neutral governance model.

1569
00:59:18,000 --> 00:59:19,560
This reduces vendor lock-in risk.

1570
00:59:19,560 --> 00:59:21,080
It encourages broad adoption.

1571
00:59:21,080 --> 00:59:25,720
And it means the protocol will evolve based on community needs rather than a single company's

1572
00:59:25,720 --> 00:59:26,720
roadmap.

1573
00:59:26,720 --> 00:59:28,040
That's the emerging architecture.

1574
00:59:28,040 --> 00:59:29,560
MCP for tools.

1575
00:59:29,560 --> 00:59:31,240
A2A for agents.

1576
00:59:31,240 --> 00:59:34,480
Together, they form the connectivity fabric of the agentic era.

1577
00:59:34,480 --> 00:59:39,000
The practical implementation pattern for A2A in Microsoft environments is still emerging.

1578
00:59:39,000 --> 00:59:40,520
But the trajectory is clear.

1579
00:59:40,520 --> 00:59:43,000
Copilot Studio agents will act as orchestrators.

1580
00:59:43,000 --> 00:59:47,960
They will receive user requests, decompose them into sub tasks, and delegate those sub tasks

1581
00:59:47,960 --> 00:59:49,960
to specialized agents through A2A.

1582
00:59:49,960 --> 00:59:53,640
The specialized agents will execute their tasks using MCP tools.

1583
00:59:53,640 --> 00:59:57,840
And the results will flow back through A2A to the orchestrator, which synthesizes the

1584
00:59:57,840 --> 00:59:59,080
final response.

1585
00:59:59,080 --> 01:00:02,520
This means your architecture needs to support both protocols from day one.

1586
01:00:02,520 --> 01:00:06,160
Even if you only have one agent today, you need to design for the day when you have 10.

1587
01:00:06,160 --> 01:00:10,240
Because adding A2A to an architecture that was only designed for MCP is harder than designing

1588
01:00:10,240 --> 01:00:11,640
for both from the start.

1589
01:00:11,640 --> 01:00:12,960
The shared foundation helps.

1590
01:00:12,960 --> 01:00:17,800
Both protocols use HTTP, both use JSON, both authenticate through Entra, and both can

1591
01:00:17,800 --> 01:00:19,160
root through API management.

1592
01:00:19,160 --> 01:00:21,240
So the infrastructure investment is unified.

1593
01:00:21,240 --> 01:00:25,320
The protocol diversity is at the application layer, not the network layer.

1594
01:00:25,320 --> 01:00:26,640
Security and identity.

1595
01:00:26,640 --> 01:00:29,040
Entra, agent ID, and agent 365.

1596
01:00:29,040 --> 01:00:32,760
All of this connectivity is useless if it's not secured, and the old security model doesn't

1597
01:00:32,760 --> 01:00:33,760
fit.

1598
01:00:33,760 --> 01:00:35,960
Here's the problem that most organizations haven't confronted yet.

1599
01:00:35,960 --> 01:00:39,360
Your existing identity and access management was designed for humans.

1600
01:00:39,360 --> 01:00:42,960
A human user has a single identity in Microsoft Entra ID.

1601
01:00:42,960 --> 01:00:44,800
They sign in with a password or a passkey.

1602
01:00:44,800 --> 01:00:45,800
They get a token.

1603
01:00:45,800 --> 01:00:50,000
That token grants them access to SharePoint, Teams, Outlook, and whatever other resources

1604
01:00:50,000 --> 01:00:51,520
their role allows.

1605
01:00:51,520 --> 01:00:55,640
Conditional access policies check their location, their device compliance, and their risk score

1606
01:00:55,640 --> 01:00:57,160
before granting access.

1607
01:00:57,160 --> 01:00:59,320
This model works because humans are predictable.

1608
01:00:59,320 --> 01:01:00,680
They log in once per session.

1609
01:01:00,680 --> 01:01:02,520
They access resources at human speed.

1610
01:01:02,520 --> 01:01:05,160
They read documents, write emails, and attend meetings.

1611
01:01:05,160 --> 01:01:08,960
Their behavior follows patterns that security systems can baseline and monitor.

1612
01:01:08,960 --> 01:01:11,600
AI agents break every one of these assumptions.

1613
01:01:11,600 --> 01:01:13,680
An agent doesn't log in once per session.

1614
01:01:13,680 --> 01:01:16,160
It authenticates before every tool invocation.

1615
01:01:16,160 --> 01:01:17,920
It might make a hundred requests in a minute.

1616
01:01:17,920 --> 01:01:19,440
It doesn't read documents.

1617
01:01:19,440 --> 01:01:22,160
It extracts structured data and reasons over it.

1618
01:01:22,160 --> 01:01:24,920
It doesn't have a manager who can approve access requests.

1619
01:01:24,920 --> 01:01:28,720
And its behavior doesn't follow human patterns, so traditional anomaly detection flags it

1620
01:01:28,720 --> 01:01:29,720
as suspicious.

1621
01:01:29,720 --> 01:01:31,000
This is the identity gap.

1622
01:01:31,000 --> 01:01:33,000
And Microsoft recognized it.

1623
01:01:33,000 --> 01:01:37,120
Microsoft Entra Agent ID is the identity and security framework that Microsoft builds specifically

1624
01:01:37,120 --> 01:01:38,360
for AI agents.

1625
01:01:38,360 --> 01:01:40,240
It launched in early 2026.

1626
01:01:40,240 --> 01:01:42,920
And it's not an incremental update to existing Entra features.

1627
01:01:42,920 --> 01:01:47,560
It's a new layer designed from the ground up for non-human identities that operate at

1628
01:01:47,560 --> 01:01:49,840
machine speed and machine scale.

1629
01:01:49,840 --> 01:01:54,560
Agent ID lets you build, discover, govern, and protect agent identities at enterprise scale.

1630
01:01:54,560 --> 01:01:59,000
When you create an agent in co-pilot studio or register a custom agent, you assign it an

1631
01:01:59,000 --> 01:02:00,760
agent ID identity.

1632
01:02:00,760 --> 01:02:05,160
This identity is distinct from human user identities and distinct from traditional workload

1633
01:02:05,160 --> 01:02:07,200
identities like service principles.

1634
01:02:07,200 --> 01:02:11,640
It has its own life cycle, its own permissions, its own audit trail, and it can be governed.

1635
01:02:11,640 --> 01:02:13,760
Agent ID includes agent sprawl detection.

1636
01:02:13,760 --> 01:02:17,680
It scans your environment and identifies every agent that has been registered, including

1637
01:02:17,680 --> 01:02:21,560
the ones that were created for a pilot six months ago and never decommissioned.

1638
01:02:21,560 --> 01:02:23,800
It shows you what each agent can access.

1639
01:02:23,800 --> 01:02:26,920
It flags agents with excessive permissions.

1640
01:02:26,920 --> 01:02:30,240
And it alerts you when an agent's behavior deviates from its baseline.

1641
01:02:30,240 --> 01:02:33,320
This matters because abandoned agents are attack vectors.

1642
01:02:33,320 --> 01:02:38,280
An agent that was created for a summer interns project and forgotten about still has its credentials.

1643
01:02:38,280 --> 01:02:39,560
Still has its permissions.

1644
01:02:39,560 --> 01:02:42,600
And still has access to whatever data it was granted six months ago.

1645
01:02:42,600 --> 01:02:47,040
If an attacker discovers that agents credentials, they have a trusted identity with legitimate

1646
01:02:47,040 --> 01:02:48,800
access to your systems.

1647
01:02:48,800 --> 01:02:52,120
Agent sprawl detection finds these forgotten identities before attackers do.

1648
01:02:52,120 --> 01:02:54,320
And there's Microsoft Agent 365.

1649
01:02:54,320 --> 01:02:59,320
Agent 365 is the control plane for AI agents across your Microsoft 365 environment.

1650
01:02:59,320 --> 01:03:04,440
It extends the same Microsoft 365 and Microsoft Security controls you already use for human

1651
01:03:04,440 --> 01:03:06,120
users to the agentech layer.

1652
01:03:06,120 --> 01:03:07,120
Observe.

1653
01:03:07,120 --> 01:03:10,560
You see what every agent is doing, what tools it's invoking, what data it's accessing and

1654
01:03:10,560 --> 01:03:11,760
what decisions it's making.

1655
01:03:11,760 --> 01:03:12,760
Govern.

1656
01:03:12,760 --> 01:03:17,240
You set policies that control which agents can access, which MCP servers, which tools they

1657
01:03:17,240 --> 01:03:19,840
can invoke, and which data they can read.

1658
01:03:19,840 --> 01:03:20,840
Secure.

1659
01:03:20,840 --> 01:03:25,520
The same sensitivity labels, DLP policies and retention rules to agent actions that you apply

1660
01:03:25,520 --> 01:03:26,920
to human actions.

1661
01:03:26,920 --> 01:03:30,920
And in May 2026, Microsoft added conditional access for agents.

1662
01:03:30,920 --> 01:03:34,840
Conditional access is the zero trust engine that Microsoft has built over the past decade.

1663
01:03:34,840 --> 01:03:37,960
It evaluates every access request against the set of conditions.

1664
01:03:37,960 --> 01:03:39,920
Is the user coming from a managed device?

1665
01:03:39,920 --> 01:03:41,640
Are they in a trusted location?

1666
01:03:41,640 --> 01:03:43,360
Is their risk score acceptable?

1667
01:03:43,360 --> 01:03:45,520
Is multifactor authentication required?

1668
01:03:45,520 --> 01:03:46,800
For human users, this works.

1669
01:03:46,800 --> 01:03:48,800
For agents, it needed extension.

1670
01:03:48,800 --> 01:03:53,120
Additional access for agents extends the zero trust principles to non-human identities.

1671
01:03:53,120 --> 01:03:57,480
When an agent tries to invoke an MCP tool, conditional access evaluates the request.

1672
01:03:57,480 --> 01:03:59,400
Is the agent coming from an approved host?

1673
01:03:59,400 --> 01:04:01,280
Is it's agent ID valid and active?

1674
01:04:01,280 --> 01:04:03,720
Has it been flagged by agent sprawl detection?

1675
01:04:03,720 --> 01:04:06,120
Is the requested tool within its approved scope?

1676
01:04:06,120 --> 01:04:07,960
If any condition fails, access is blocked.

1677
01:04:07,960 --> 01:04:08,960
This isn't an afterthought.

1678
01:04:08,960 --> 01:04:13,000
It's a fundamental security layer because without it, your MCP servers are exposed to any

1679
01:04:13,000 --> 01:04:14,960
agent that can reach their endpoint.

1680
01:04:14,960 --> 01:04:18,760
And in a world where agents authenticate at machine speed, a compromised agent can

1681
01:04:18,760 --> 01:04:22,920
exfiltrate data at a rate that human attackers can't match.

1682
01:04:22,920 --> 01:04:26,200
The licensing model is also important for architects to understand.

1683
01:04:26,200 --> 01:04:30,840
Microsoft Entra Agent ID is part of the Entra ID suite, which is priced at $12 per

1684
01:04:30,840 --> 01:04:32,880
user per month as of 2026.

1685
01:04:32,880 --> 01:04:35,840
The suite includes nine services, an agent ID is one of them.

1686
01:04:35,840 --> 01:04:39,440
This means you're not buying a standalone security product for agents.

1687
01:04:39,440 --> 01:04:43,480
You're extending your existing identity investment to cover the agent layer.

1688
01:04:43,480 --> 01:04:48,360
For organizations already using Entra ID suite, agent ID is an incremental capability.

1689
01:04:48,360 --> 01:04:52,160
For organizations on lower tiers, it's a reason to evaluate the suite upgrade.

1690
01:04:52,160 --> 01:04:56,800
From an architectural perspective, the integration between agent ID and MCP is straightforward.

1691
01:04:56,800 --> 01:05:00,240
Your MCP server validates the agent ID token on every request.

1692
01:05:00,240 --> 01:05:03,760
It checks that the agent is authorized to invoke the requested tool.

1693
01:05:03,760 --> 01:05:05,520
It logs the invocation for auditing.

1694
01:05:05,520 --> 01:05:09,120
And it applies data classification rules based on the agent scope rather than a human

1695
01:05:09,120 --> 01:05:10,280
user's role.

1696
01:05:10,280 --> 01:05:13,600
This means you can have different security policies for different agents.

1697
01:05:13,600 --> 01:05:18,080
A customer facing chatbot agent might have read only access to product catalogs and

1698
01:05:18,080 --> 01:05:19,480
order history.

1699
01:05:19,480 --> 01:05:23,440
An internal procurement agent might have right access to purchase order systems, but no

1700
01:05:23,440 --> 01:05:24,920
access to customer PII.

1701
01:05:24,920 --> 01:05:30,040
A finance reporting agent might have access to aggregated data, but not to individual transactions.

1702
01:05:30,040 --> 01:05:34,720
Each agent has its own identity, its own permissions, its own conditional access policies.

1703
01:05:34,720 --> 01:05:37,520
And when an agent is no longer needed, you revoke its agent ID.

1704
01:05:37,520 --> 01:05:41,880
Its permissions disappear, its access tokens expire, and it becomes a non-entity in your

1705
01:05:41,880 --> 01:05:43,120
security posture.

1706
01:05:43,120 --> 01:05:44,440
That's the governance layer.

1707
01:05:44,440 --> 01:05:49,640
The MCP provides the connectivity, agent ID secures the connections, and agent 365 provides

1708
01:05:49,640 --> 01:05:51,120
the control plane.

1709
01:05:51,120 --> 01:05:54,680
Together they create an enterprise great architecture that doesn't just connect agents

1710
01:05:54,680 --> 01:05:57,400
to data, it connects them safely.

1711
01:05:57,400 --> 01:06:01,360
Architecting the complete MCP layer, reference architecture, architecting the complete MCP

1712
01:06:01,360 --> 01:06:02,960
layer, reference architecture.

1713
01:06:02,960 --> 01:06:06,120
Let's put all of this together into a reference architecture you can take to your team,

1714
01:06:06,120 --> 01:06:07,440
because theory is fine.

1715
01:06:07,440 --> 01:06:11,960
But what your organization needs is a diagram, a data flow, a decision tree, and a clear

1716
01:06:11,960 --> 01:06:14,120
picture of how all the pieces connect.

1717
01:06:14,120 --> 01:06:15,680
Here's the layered architecture.

1718
01:06:15,680 --> 01:06:17,200
At the bottom is the data layer.

1719
01:06:17,200 --> 01:06:18,800
This is where your business systems live.

1720
01:06:18,800 --> 01:06:23,760
Your Dynamics 365 ERP, your SharePoint sites, your SQL databases on Azure, your custom

1721
01:06:23,760 --> 01:06:25,560
line of business applications.

1722
01:06:25,560 --> 01:06:27,960
Your one drive files, your team's conversations.

1723
01:06:27,960 --> 01:06:29,360
This layer doesn't change.

1724
01:06:29,360 --> 01:06:32,440
These are the systems you've built and bought over the past decade.

1725
01:06:32,440 --> 01:06:33,720
They are your source of truth.

1726
01:06:33,720 --> 01:06:36,240
Above the data layer is the MCP server layer.

1727
01:06:36,240 --> 01:06:37,920
This is where the connectivity happens.

1728
01:06:37,920 --> 01:06:42,240
Each MCP server wraps one or more business systems and exposes their capabilities through

1729
01:06:42,240 --> 01:06:43,760
the standardized protocol.

1730
01:06:43,760 --> 01:06:48,560
You might have an ERP MCP server that exposes tools for inventory checks, order creation,

1731
01:06:48,560 --> 01:06:49,680
and supplier lookups.

1732
01:06:49,680 --> 01:06:54,400
You might have a SharePoint MCP server that exposes resources for project documents and policy

1733
01:06:54,400 --> 01:06:55,400
manuals.

1734
01:06:55,400 --> 01:06:59,200
You might have a custom application MCP server that exposes tools for your proprietary business

1735
01:06:59,200 --> 01:07:00,280
processes.

1736
01:07:00,280 --> 01:07:04,800
Each MCP server is a net application built with the official CESDK.

1737
01:07:04,800 --> 01:07:09,200
Each server registers its tools, resources, and prompts through the SDK's attribute system.

1738
01:07:09,200 --> 01:07:13,840
Each server handles the JSON RPC protocol, the initialization handshake, and the capability

1739
01:07:13,840 --> 01:07:15,040
negotiation.

1740
01:07:15,040 --> 01:07:19,120
And each server runs on Azure, either through Azure Functions for Event-driven workloads

1741
01:07:19,120 --> 01:07:22,240
or Azure Container Apps for persistent services.

1742
01:07:22,240 --> 01:07:24,640
Above the MCP server layer is the Intelligence layer.

1743
01:07:24,640 --> 01:07:25,640
This is Work IQ.

1744
01:07:25,640 --> 01:07:29,440
It sits alongside the MCP servers rather than replacing them because it serves a different

1745
01:07:29,440 --> 01:07:30,440
purpose.

1746
01:07:30,440 --> 01:07:35,360
MCP server's exposed business operations, Work IQ exposes organizational context, it knows

1747
01:07:35,360 --> 01:07:39,280
who works on what, it knows what meetings decided, it knows which documents changed.

1748
01:07:39,280 --> 01:07:44,320
And it provides this context through its own MCP server so that any agent can discover and

1749
01:07:44,320 --> 01:07:45,320
consume it.

1750
01:07:45,320 --> 01:07:47,480
Above the Intelligence layer is the protocol layer.

1751
01:07:47,480 --> 01:07:49,480
This is where MCP and A2A operate.

1752
01:07:49,480 --> 01:07:51,680
MCP handles agent tool communication.

1753
01:07:51,680 --> 01:07:54,160
A2A handles agent to agent communication.

1754
01:07:54,160 --> 01:07:58,680
Both protocols use HTTP, both use JSON RPC 2.0, both integrate with Microsoft Entra for

1755
01:07:58,680 --> 01:07:59,920
authentication.

1756
01:07:59,920 --> 01:08:03,320
And both can root through Azure API management for gateway services.

1757
01:08:03,320 --> 01:08:05,880
API management is the critical hub in this layer.

1758
01:08:05,880 --> 01:08:07,800
It receives all incoming protocol requests.

1759
01:08:07,800 --> 01:08:10,480
It validates baritokens against Entra agent ID.

1760
01:08:10,480 --> 01:08:12,880
It applies rate limiting based on the agent's tier.

1761
01:08:12,880 --> 01:08:17,640
It roots requests to the appropriate back end MCP server based on the tool name or the resource

1762
01:08:17,640 --> 01:08:18,640
URI.

1763
01:08:18,640 --> 01:08:21,000
And it logs every request for auditing and monitoring.

1764
01:08:21,000 --> 01:08:23,760
This means your MCP servers don't sit on the public internet.

1765
01:08:23,760 --> 01:08:25,160
They live in a private VNet.

1766
01:08:25,160 --> 01:08:28,200
API management has a private endpoint in that VNet.

1767
01:08:28,200 --> 01:08:30,000
All traffic flows through the gateway.

1768
01:08:30,000 --> 01:08:34,000
And your network security team applies the same policies to MCP traffic that they apply to

1769
01:08:34,000 --> 01:08:35,800
every other internal API.

1770
01:08:35,800 --> 01:08:37,640
Above the protocol layer is the agent layer.

1771
01:08:37,640 --> 01:08:38,920
This is where your agents live.

1772
01:08:38,920 --> 01:08:42,440
Copilot Studio agents that uses interact with through Teams chat.

1773
01:08:42,440 --> 01:08:44,960
Custom agents that run background processes.

1774
01:08:44,960 --> 01:08:48,760
Specialized agents that handle procurement, customer service or financial reporting.

1775
01:08:48,760 --> 01:08:51,400
Each agent has an agent ID identity in Entra.

1776
01:08:51,400 --> 01:08:53,520
Each agent discovers tools through MCP.

1777
01:08:53,520 --> 01:08:55,880
Each agent delegates tasks through A2A.

1778
01:08:55,880 --> 01:08:59,640
And each agent operates within the scope defined by its conditional access policies.

1779
01:08:59,640 --> 01:09:01,640
At the top is the presentation layer.

1780
01:09:01,640 --> 01:09:03,920
This is where users engage with the agents.

1781
01:09:03,920 --> 01:09:04,920
Teams chat.

1782
01:09:04,920 --> 01:09:09,720
Copilot in Outlook, Power Apps Interfaces, Custom Web Applications, the user asks a question.

1783
01:09:09,720 --> 01:09:11,120
The question flows to an agent.

1784
01:09:11,120 --> 01:09:12,120
The agent reasons.

1785
01:09:12,120 --> 01:09:13,400
The agent discovers tools.

1786
01:09:13,400 --> 01:09:15,240
The agent invokes tools through MCP.

1787
01:09:15,240 --> 01:09:17,080
The tools execute business logic.

1788
01:09:17,080 --> 01:09:18,400
The results flow back.

1789
01:09:18,400 --> 01:09:20,600
The agent synthesizes the answer.

1790
01:09:20,600 --> 01:09:24,320
And the user receives a response that is grounded in real-time business data.

1791
01:09:24,320 --> 01:09:25,560
That's the vertical stack.

1792
01:09:25,560 --> 01:09:27,560
Now let's look at the data flow horizontally.

1793
01:09:27,560 --> 01:09:31,560
A user asks their Copilot Studio agent, what's the status of the Phoenix project?

1794
01:09:31,560 --> 01:09:33,600
And are we on track to deliver by Friday?

1795
01:09:33,600 --> 01:09:34,880
The agent receives the question.

1796
01:09:34,880 --> 01:09:36,680
It initializes its MCP connections.

1797
01:09:36,680 --> 01:09:39,760
It discovers available tools from the registered MCP servers.

1798
01:09:39,760 --> 01:09:45,360
It sees a tool from the work IQ MCP server called GetProjectStatus with a project name parameter.

1799
01:09:45,360 --> 01:09:51,320
It sees a tool from the ERP MCP server called CheckDeliverySchedule with a project code parameter.

1800
01:09:51,320 --> 01:09:52,160
The agent reasons.

1801
01:09:52,160 --> 01:09:54,200
It decides to invoke both tools.

1802
01:09:54,200 --> 01:09:57,600
At first, conditional access evaluates the agent's identity.

1803
01:09:57,600 --> 01:09:59,360
API management receives the request.

1804
01:09:59,360 --> 01:10:00,840
It validates the bearer token.

1805
01:10:00,840 --> 01:10:03,320
It checks the agent ID against EntraAgentID.

1806
01:10:03,320 --> 01:10:06,520
It confirms the agent is authorized to invoke these specific tools.

1807
01:10:06,520 --> 01:10:07,720
It checks the rate limit.

1808
01:10:07,720 --> 01:10:08,720
And it roots the requests.

1809
01:10:08,720 --> 01:10:10,400
The work IQ tool executes.

1810
01:10:10,400 --> 01:10:12,440
It queries SharePoint for project documents.

1811
01:10:12,440 --> 01:10:15,040
It reads Teams conversations about the Phoenix project.

1812
01:10:15,040 --> 01:10:16,280
It checks planner tasks.

1813
01:10:16,280 --> 01:10:20,040
And it returns a structured summary of the project status, including risk flags identified

1814
01:10:20,040 --> 01:10:21,800
from recent meeting transcripts.

1815
01:10:21,800 --> 01:10:23,000
The ERP tool executes.

1816
01:10:23,000 --> 01:10:25,120
It queries the delivery schedule database.

1817
01:10:25,120 --> 01:10:27,600
It checks inventory levels for required components.

1818
01:10:27,600 --> 01:10:29,520
It verifies supplier lead times.

1819
01:10:29,520 --> 01:10:31,480
And it returns a structured delivery forecast.

1820
01:10:31,480 --> 01:10:32,960
The agent receives both results.

1821
01:10:32,960 --> 01:10:34,240
It synthesizes them.

1822
01:10:34,240 --> 01:10:38,280
It recognizes that while the project status is green, a supplier lead time has slipped

1823
01:10:38,280 --> 01:10:41,240
by two days, putting the Friday delivery at risk.

1824
01:10:41,240 --> 01:10:43,240
It drafts a response for the user.

1825
01:10:43,240 --> 01:10:46,680
And it optionally triggers a notification tool to alert the project manager.

1826
01:10:46,680 --> 01:10:51,160
The user sees a concise answer grounded in real project data and real supply chain

1827
01:10:51,160 --> 01:10:52,160
conditions.

1828
01:10:52,160 --> 01:10:53,160
Not a demo.

1829
01:10:53,160 --> 01:10:54,320
That's a production architecture.

1830
01:10:54,320 --> 01:10:55,440
And it scales.

1831
01:10:55,440 --> 01:10:58,720
When you have 10 users, this architecture works on a single Azure function.

1832
01:10:58,720 --> 01:11:01,720
When you have 10,000 users, API management distributes the load.

1833
01:11:01,720 --> 01:11:03,960
Azure Functions scale horizontally.

1834
01:11:03,960 --> 01:11:05,520
Container apps handle persistent state.

1835
01:11:05,520 --> 01:11:07,720
Cosmos DB caches session data.

1836
01:11:07,720 --> 01:11:09,760
Application insights monitors every request.

1837
01:11:09,760 --> 01:11:12,360
And Azure Front Door roots traffic across regions.

1838
01:11:12,360 --> 01:11:14,040
The scaling patterns are standard Azure.

1839
01:11:14,040 --> 01:11:15,880
The protocol is standard MCP.

1840
01:11:15,880 --> 01:11:17,720
The identity is standard Entra.

1841
01:11:17,720 --> 01:11:21,080
And the architecture is standard enterprise integration applied to a new domain.

1842
01:11:21,080 --> 01:11:23,200
Now let's talk about failure modes.

1843
01:11:23,200 --> 01:11:26,520
Because architects don't just design for success, they design for failure.

1844
01:11:26,520 --> 01:11:28,480
What happens when an MCP server is down?

1845
01:11:28,480 --> 01:11:32,800
The agent discovers the server is unavailable during initialization or receives an error during

1846
01:11:32,800 --> 01:11:33,800
tool invocation.

1847
01:11:33,800 --> 01:11:36,120
A well-designed agent handles this gracefully.

1848
01:11:36,120 --> 01:11:39,840
It informs the user that a specific data source is temporarily unavailable.

1849
01:11:39,840 --> 01:11:42,160
It falls back to alternative tools if they exist.

1850
01:11:42,160 --> 01:11:45,280
And it queues the request for retry if the operation is critical.

1851
01:11:45,280 --> 01:11:47,160
What happens when an MCP server is slow?

1852
01:11:47,160 --> 01:11:49,320
API management applies timeout policies.

1853
01:11:49,320 --> 01:11:53,600
If a tool execution exceeds the configured threshold, the gateway returns a timeout error.

1854
01:11:53,600 --> 01:11:57,840
The agent receives the error and decides whether to retry, to inform the user, or to proceed

1855
01:11:57,840 --> 01:11:59,240
with partial information.

1856
01:11:59,240 --> 01:12:01,320
What happens when an agent is compromised?

1857
01:12:01,320 --> 01:12:03,320
Entra agent ID detects the anomaly.

1858
01:12:03,320 --> 01:12:04,920
Conditional access blocks the request.

1859
01:12:04,920 --> 01:12:07,920
The agent 365 control plane alerts the security team.

1860
01:12:07,920 --> 01:12:12,280
And the compromised agent's credentials are revoked before significant damage occurs.

1861
01:12:12,280 --> 01:12:14,600
What happens when a tool returns unexpected data?

1862
01:12:14,600 --> 01:12:17,400
The agent's reasoning pipeline handles the structured response.

1863
01:12:17,400 --> 01:12:22,240
If the response doesn't match the expected schema, the agent flags the inconsistency rather

1864
01:12:22,240 --> 01:12:23,920
than hallucinating an answer.

1865
01:12:23,920 --> 01:12:24,920
The error is logged.

1866
01:12:24,920 --> 01:12:26,920
The MCP server operator is alerted.

1867
01:12:26,920 --> 01:12:28,200
And the schema is corrected.

1868
01:12:28,200 --> 01:12:29,720
These failure modes aren't hypothetical.

1869
01:12:29,720 --> 01:12:33,840
They are the standard resilience patterns that every enterprise architect already applies

1870
01:12:33,840 --> 01:12:35,680
to APIs and microservices.

1871
01:12:35,680 --> 01:12:37,640
MCP doesn't change the resilience model.

1872
01:12:37,640 --> 01:12:39,320
It extends it to the agent layer.

1873
01:12:39,320 --> 01:12:41,080
Finally, let's address the anti-patterns.

1874
01:12:41,080 --> 01:12:44,920
The most common mistake is putting business logic in the agent instead of the MCP server.

1875
01:12:44,920 --> 01:12:46,160
The agent should reason.

1876
01:12:46,160 --> 01:12:48,120
It should decide which tools to invoke.

1877
01:12:48,120 --> 01:12:49,440
It should synthesize results.

1878
01:12:49,440 --> 01:12:51,280
But it should not implement business rules.

1879
01:12:51,280 --> 01:12:56,080
Business rules belong in the MCP server where they can be versioned, tested and reused across

1880
01:12:56,080 --> 01:12:57,280
multiple agents.

1881
01:12:57,280 --> 01:13:00,160
The second common mistake is using SDDO transport and production.

1882
01:13:00,160 --> 01:13:01,720
SDDO is for development.

1883
01:13:01,720 --> 01:13:03,440
Streamable HTTP is for production.

1884
01:13:03,440 --> 01:13:07,720
Deploying a SDDO server to Azure and trying to connect remotely is a category error.

1885
01:13:07,720 --> 01:13:10,560
The third common mistake is hard coding authentication.

1886
01:13:10,560 --> 01:13:14,200
Every MCP server should validate tokens through Entra agent ID.

1887
01:13:14,200 --> 01:13:19,960
Encoded API keys, connection strings or credentials create security debt that will eventually cause

1888
01:13:19,960 --> 01:13:20,960
a breach.

1889
01:13:20,960 --> 01:13:24,960
The fourth common mistake is building one giant MCP server that exposes every tool in the

1890
01:13:24,960 --> 01:13:26,120
organization.

1891
01:13:26,120 --> 01:13:28,200
This creates a monolithic dependency.

1892
01:13:28,200 --> 01:13:31,520
When that server needs maintenance, every agent that depends on it stops working.

1893
01:13:31,520 --> 01:13:34,880
Instead, build focused MCP servers for specific domains.

1894
01:13:34,880 --> 01:13:38,200
One for ERP, one for SharePoint, one for Custom applications.

1895
01:13:38,200 --> 01:13:41,600
This limits blast radius and enables independent deployment.

1896
01:13:41,600 --> 01:13:44,080
The fifth common mistake is ignoring observability.

1897
01:13:44,080 --> 01:13:45,720
MCP servers are infrastructure.

1898
01:13:45,720 --> 01:13:48,400
They need monitoring, they need logging, they need alerting.

1899
01:13:48,400 --> 01:13:51,960
Without application insights or an equivalent observability platform, you'll be debugging

1900
01:13:51,960 --> 01:13:53,600
production issues in the dark.

1901
01:13:53,600 --> 01:13:56,120
A sixth mistake is skipping capacity planning.

1902
01:13:56,120 --> 01:14:01,320
An MCP server that handles 10 requests per minute during testing will collapse under 1000 requests

1903
01:14:01,320 --> 01:14:06,000
per minute when 1000 users start using the agent simultaneously.

1904
01:14:06,000 --> 01:14:07,400
Load test early.

1905
01:14:07,400 --> 01:14:09,120
Understand your latency distribution.

1906
01:14:09,120 --> 01:14:13,080
Identify the P9 response time and set your scaling rules based on real traffic patterns,

1907
01:14:13,080 --> 01:14:14,600
and set up optimistic estimates.

1908
01:14:14,600 --> 01:14:17,760
A seventh mistake is neglecting backward compatibility.

1909
01:14:17,760 --> 01:14:20,760
When you add a new parameter to a tool, older clients might not provide it.

1910
01:14:20,760 --> 01:14:24,800
When you rename a tool, existing agents lose access until they reinitialize.

1911
01:14:24,800 --> 01:14:29,160
When you change a response schema, agents that depend on specific field names break.

1912
01:14:29,160 --> 01:14:30,520
Version your tools carefully.

1913
01:14:30,520 --> 01:14:33,520
Add parameters as optional before making them required.

1914
01:14:33,520 --> 01:14:38,160
Deprecate tools before removing them and communicate changes to agent owners before deployment.

1915
01:14:38,160 --> 01:14:41,520
An eighth mistake is failing to document the server capabilities.

1916
01:14:41,520 --> 01:14:45,600
The MCP protocol provides tool descriptions and parameter schemas, but it doesn't provide

1917
01:14:45,600 --> 01:14:46,600
business context.

1918
01:14:46,600 --> 01:14:50,080
An agent developer needs to know what business process or tool supports.

1919
01:14:50,080 --> 01:14:51,960
They need to know what data quality to expect.

1920
01:14:51,960 --> 01:14:54,800
They need to know what error conditions to handle.

1921
01:14:54,800 --> 01:14:57,200
Write documentation that lives outside the protocol.

1922
01:14:57,200 --> 01:14:58,360
Share it with agent teams.

1923
01:14:58,360 --> 01:14:59,360
And keep it current.

1924
01:14:59,360 --> 01:15:01,880
A ninth mistake is deploying without a rollback plan.

1925
01:15:01,880 --> 01:15:05,400
When a new MCP server version breaks an agent, you need to revert quickly.

1926
01:15:05,400 --> 01:15:09,280
Blue Green deployment is the standard pattern, but it requires automation.

1927
01:15:09,280 --> 01:15:13,120
The rollbacks take too long, build a deployment pipeline before you need it.

1928
01:15:13,120 --> 01:15:17,160
Test the rollback procedure before you deploy to production and practice the failure recovery

1929
01:15:17,160 --> 01:15:19,360
during plant maintenance windows.

1930
01:15:19,360 --> 01:15:22,720
Avoid these mistakes and you'll have an architecture that lasts.

1931
01:15:22,720 --> 01:15:25,200
Implementation roadmap from POC to production.

1932
01:15:25,200 --> 01:15:27,760
Knowing the architecture isn't the same as knowing where to start.

1933
01:15:27,760 --> 01:15:31,240
So here's your 90 day roadmap from proof of concept to production.

1934
01:15:31,240 --> 01:15:36,160
Weeks 1 and 2 are about setting up your development environment and proving the pattern works.

1935
01:15:36,160 --> 01:15:40,880
Call the model context protocol, new get package in a new or a net console application.

1936
01:15:40,880 --> 01:15:43,800
Build a single tool that does something simple but real.

1937
01:15:43,800 --> 01:15:45,720
Maybe it queries your product catalog.

1938
01:15:45,720 --> 01:15:47,240
Maybe it checks a database record.

1939
01:15:47,240 --> 01:15:48,640
Maybe it reads a share point list.

1940
01:15:48,640 --> 01:15:50,160
The specific tool doesn't matter.

1941
01:15:50,160 --> 01:15:55,160
What matters is that it connects to a real data source and returns real structured data.

1942
01:15:55,160 --> 01:15:57,120
Test it locally using STDIO transport.

1943
01:15:57,120 --> 01:15:58,440
Connect an MCP client.

1944
01:15:58,440 --> 01:16:00,240
Verify that the client discovers the tool.

1945
01:16:00,240 --> 01:16:03,360
Verify that tool invocation returns the expected data.

1946
01:16:03,360 --> 01:16:05,760
Verify that the structured output matches your schema.

1947
01:16:05,760 --> 01:16:07,880
Verify that errors are handled gracefully.

1948
01:16:07,880 --> 01:16:09,480
This two week block proves the pattern.

1949
01:16:09,480 --> 01:16:13,120
If you can't get a single tool working locally, you don't have a foundation.

1950
01:16:13,120 --> 01:16:15,240
Fix the issues here before you try to scale.

1951
01:16:15,240 --> 01:16:19,120
Weeks 3 and 4 are about graduating to remote transport and Azure deployment.

1952
01:16:19,120 --> 01:16:21,680
Convert your console application to an ASP.

1953
01:16:21,680 --> 01:16:23,520
Netcore web application.

1954
01:16:23,520 --> 01:16:27,440
Add streamable HTTP transport using the SDKs hosting extensions.

1955
01:16:27,440 --> 01:16:30,680
Configure authentication with a Microsoft Entra Service principle.

1956
01:16:30,680 --> 01:16:32,240
Deploy to Azure Functions.

1957
01:16:32,240 --> 01:16:34,120
Add application insights for logging.

1958
01:16:34,120 --> 01:16:36,800
And test the same tool through the remote endpoint.

1959
01:16:36,800 --> 01:16:39,880
This is where most developers encounter their first real issues.

1960
01:16:39,880 --> 01:16:42,400
Authentication configuration is tricky.

1961
01:16:42,400 --> 01:16:45,840
Barer token validation requires the right middleware.

1962
01:16:45,840 --> 01:16:48,600
Cores policies need to allow your client origins.

1963
01:16:48,600 --> 01:16:53,360
And Azure Functions code start can add latency to the first request after idle periods.

1964
01:16:53,360 --> 01:16:55,320
Expect to spend time debugging these issues.

1965
01:16:55,320 --> 01:16:56,320
That's normal.

1966
01:16:56,320 --> 01:16:57,680
Document your configuration.

1967
01:16:57,680 --> 01:17:01,960
The patterns you establish here will be replicated across every MCP server you build.

1968
01:17:01,960 --> 01:17:05,200
These 5 and 6 are about integrating with co-pilot studio.

1969
01:17:05,200 --> 01:17:08,160
Register your MCP server endpoint in co-pilot studio.

1970
01:17:08,160 --> 01:17:09,560
Configure the authentication method.

1971
01:17:09,560 --> 01:17:10,920
Set the protocol version.

1972
01:17:10,920 --> 01:17:11,920
Test the connection.

1973
01:17:11,920 --> 01:17:14,640
Verify that your tools appear in the agent's tool catalog.

1974
01:17:14,640 --> 01:17:16,880
And then test end to end with real user queries.

1975
01:17:16,880 --> 01:17:18,840
This is where the human factor enters.

1976
01:17:18,840 --> 01:17:22,640
Your tool descriptions need to be clear enough that the agent knows when to invoke them.

1977
01:17:22,640 --> 01:17:26,560
If your description is vague, the agent will invoke the wrong tool or skip the right one.

1978
01:17:26,560 --> 01:17:30,760
If your parameter schema is too complex, the agent will provide incomplete or incorrect

1979
01:17:30,760 --> 01:17:31,760
inputs.

1980
01:17:31,760 --> 01:17:33,120
Your tool descriptions.

1981
01:17:33,120 --> 01:17:34,680
Test with real user questions.

1982
01:17:34,680 --> 01:17:36,520
Itterate on the parameter schemas.

1983
01:17:36,520 --> 01:17:40,040
And monitor the tool invocation logs to see which tools are being used and which are being

1984
01:17:40,040 --> 01:17:41,040
ignored.

1985
01:17:41,040 --> 01:17:45,360
Week 7 and 8 are about adding organizational context through work IQ.

1986
01:17:45,360 --> 01:17:48,080
Register the work IQ MCP server in your architecture.

1987
01:17:48,080 --> 01:17:49,800
Test the 6 core tools.

1988
01:17:49,800 --> 01:17:54,560
Verify that your agents can retrieve organizational context, read documents, access teams conversations

1989
01:17:54,560 --> 01:17:56,480
and draft label documents.

1990
01:17:56,480 --> 01:17:58,800
This is where your agents start feeling intelligent.

1991
01:17:58,800 --> 01:18:03,080
Work IQ, your agents answer based on the user's immediate query and whatever tool data they

1992
01:18:03,080 --> 01:18:04,080
can retrieve.

1993
01:18:04,080 --> 01:18:08,000
With work IQ, your agents understand the organizational context behind the query.

1994
01:18:08,000 --> 01:18:09,280
They know who's involved.

1995
01:18:09,280 --> 01:18:10,720
They know what decisions were made.

1996
01:18:10,720 --> 01:18:12,640
They know what documents are relevant.

1997
01:18:12,640 --> 01:18:17,680
The integration effort here is lighter than weeks 3 and 4 because work IQ MCP server is already

1998
01:18:17,680 --> 01:18:18,680
built.

1999
01:18:18,680 --> 01:18:20,320
You're configuring it, not coding it.

2000
01:18:20,320 --> 01:18:24,400
But the organizational impact is significant because it connects your agents to the institutional

2001
01:18:24,400 --> 01:18:27,080
knowledge that lives in Microsoft 365.

2002
01:18:27,080 --> 01:18:29,760
This 9 and 10 are about securing the architecture.

2003
01:18:29,760 --> 01:18:32,880
Implement Entra Agent ID for every agent in your architecture.

2004
01:18:32,880 --> 01:18:34,480
Configure Conditional Access Policies.

2005
01:18:34,480 --> 01:18:35,800
Set up agents Brawl Detection.

2006
01:18:35,800 --> 01:18:38,160
Define least privileged permissions for each agent.

2007
01:18:38,160 --> 01:18:39,600
And test the security boundaries.

2008
01:18:39,600 --> 01:18:41,080
This isn't a checkbox exercise.

2009
01:18:41,080 --> 01:18:43,680
Invite your security team to review the architecture.

2010
01:18:43,680 --> 01:18:45,400
Show them how agent ID works.

2011
01:18:45,400 --> 01:18:47,880
Show them how conditional access applies to agents.

2012
01:18:47,880 --> 01:18:50,080
Show them the audit logs in API management.

2013
01:18:50,080 --> 01:18:53,600
And get their approval before you open the system to production users.

2014
01:18:53,600 --> 01:18:55,080
Security team buy in is critical.

2015
01:18:55,080 --> 01:18:58,720
Because if the security team doesn't understand how agent authentication works, they will

2016
01:18:58,720 --> 01:18:59,720
block the deployment.

2017
01:18:59,720 --> 01:19:02,760
And if they block it after you've built everything, you've wasted 10 weeks.

2018
01:19:02,760 --> 01:19:03,760
Get them involved early.

2019
01:19:03,760 --> 01:19:05,760
Use this roadmap as a conversation starter.

2020
01:19:05,760 --> 01:19:07,560
Show them week 9 and 10 during week 1.

2021
01:19:07,560 --> 01:19:11,320
Let them shape the security architecture while you're still building the prototype.

2022
01:19:11,320 --> 01:19:13,760
Weeks 11 and 12 are about hardening for production.

2023
01:19:13,760 --> 01:19:15,400
Low test your MCP servers.

2024
01:19:15,400 --> 01:19:16,400
Find the bottlenecks.

2025
01:19:16,400 --> 01:19:18,400
Tune Azure Function Scaling Rules.

2026
01:19:18,400 --> 01:19:20,240
Configure API Management Caching.

2027
01:19:20,240 --> 01:19:22,560
Set up blue green deployment pipelines.

2028
01:19:22,560 --> 01:19:24,880
Write runbooks for common failure scenarios.

2029
01:19:24,880 --> 01:19:26,800
The architecture for operations teams.

2030
01:19:26,800 --> 01:19:30,160
And train your support staff on how to diagnose agent connectivity issues.

2031
01:19:30,160 --> 01:19:31,640
This is the operations phase.

2032
01:19:31,640 --> 01:19:33,440
And it's where many projects fall apart.

2033
01:19:33,440 --> 01:19:34,840
Because developers love building.

2034
01:19:34,840 --> 01:19:36,080
They don't love documenting.

2035
01:19:36,080 --> 01:19:37,560
They don't love writing runbooks.

2036
01:19:37,560 --> 01:19:38,800
They don't love load testing.

2037
01:19:38,800 --> 01:19:40,880
But operations teams need these artifacts.

2038
01:19:40,880 --> 01:19:45,280
When an MCP server fails at 2 in the morning, the on-call engineer needs a runbook.

2039
01:19:45,280 --> 01:19:47,320
They need to know how to check if the server is running.

2040
01:19:47,320 --> 01:19:49,880
They need to know how to check if Android is issuing tokens.

2041
01:19:49,880 --> 01:19:52,680
They need to know how to fail over to the green environment if the blue environment

2042
01:19:52,680 --> 01:19:53,680
is unhealthy.

2043
01:19:53,680 --> 01:19:56,960
Without these artifacts, your beautiful architecture becomes a black box that breaks

2044
01:19:56,960 --> 01:19:58,200
unpredictably.

2045
01:19:58,200 --> 01:19:59,560
Write the runbooks.

2046
01:19:59,560 --> 01:20:00,840
Document the architecture.

2047
01:20:00,840 --> 01:20:03,920
And test the failure scenarios before they happen in production.

2048
01:20:03,920 --> 01:20:07,120
Specifically, you need four operational artifacts before launch.

2049
01:20:07,120 --> 01:20:08,800
The first is a health check dashboard.

2050
01:20:08,800 --> 01:20:11,960
This dashboard shows the status of every MCP server.

2051
01:20:11,960 --> 01:20:12,960
Green means healthy.

2052
01:20:12,960 --> 01:20:14,200
Yellow means degraded.

2053
01:20:14,200 --> 01:20:15,320
Red means down.

2054
01:20:15,320 --> 01:20:18,400
It shows request rates, error rates, and latency percentiles.

2055
01:20:18,400 --> 01:20:20,560
It shows antrotoken acquisition success rates.

2056
01:20:20,560 --> 01:20:23,160
And it shows API management rate limit utilization.

2057
01:20:23,160 --> 01:20:26,760
The on-call engineer glances at this dashboard and knows immediately whether the problem is

2058
01:20:26,760 --> 01:20:29,920
in the MCP layer, the auth layer, or the network layer.

2059
01:20:29,920 --> 01:20:32,160
The second is an incident response runbook.

2060
01:20:32,160 --> 01:20:36,360
This document lists the common failure modes and the exact steps to diagnose and resolve

2061
01:20:36,360 --> 01:20:37,360
them.

2062
01:20:37,360 --> 01:20:39,960
What to do when an MCP server returns 500 errors?

2063
01:20:39,960 --> 01:20:41,760
What to do when antrotoken validation fails?

2064
01:20:41,760 --> 01:20:44,200
What to do when co-pilot studio can't discover tools?

2065
01:20:44,200 --> 01:20:46,120
What to do when response latency spikes?

2066
01:20:46,120 --> 01:20:49,200
Each scenario has a diagnosis flow chart and resolution steps.

2067
01:20:49,200 --> 01:20:50,960
The third is a deployment checklist.

2068
01:20:50,960 --> 01:20:54,840
This document lists every step required to deploy a new MCP server version.

2069
01:20:54,840 --> 01:20:55,840
Build the code.

2070
01:20:55,840 --> 01:21:00,600
Run unit tests, run integration tests, deploy to staging, run smoke tests, switch the

2071
01:21:00,600 --> 01:21:05,280
blue green routing, monitor for errors, and roll back if error rates exceed the threshold.

2072
01:21:05,280 --> 01:21:08,840
No deployment happens without this checklist and no deployment happens outside the maintenance

2073
01:21:08,840 --> 01:21:10,800
window unless it's an emergency.

2074
01:21:10,800 --> 01:21:12,240
The fourth is a capacity plan.

2075
01:21:12,240 --> 01:21:15,840
This document estimates request volumes, server capacity, and scaling triggers.

2076
01:21:15,840 --> 01:21:19,760
It says how many requests per second each MCP server handles at peak.

2077
01:21:19,760 --> 01:21:22,200
It says how many Azure Function instances are provisioned.

2078
01:21:22,200 --> 01:21:26,360
It says what the scale out trigger is and it says what the maximum capacity is before

2079
01:21:26,360 --> 01:21:28,280
the architecture needs redesign.

2080
01:21:28,280 --> 01:21:32,320
These four artifacts transform your project from a development experiment into enterprise

2081
01:21:32,320 --> 01:21:33,320
infrastructure.

2082
01:21:33,320 --> 01:21:36,600
Now let's talk about common pitfalls and how to avoid them at each stage.

2083
01:21:36,600 --> 01:21:40,640
In weeks one and two, the most common pitfall is building a toy example that doesn't connect

2084
01:21:40,640 --> 01:21:41,800
to real data.

2085
01:21:41,800 --> 01:21:44,920
A tool that returns hard coded JSON proves nothing.

2086
01:21:44,920 --> 01:21:48,800
Build against a real database, a real SharePoint list or a real API.

2087
01:21:48,800 --> 01:21:52,440
Even if the tool is simple, the connection to real data validates the pattern.

2088
01:21:52,440 --> 01:21:55,720
In weeks three and four, the most common pitfall is skipping authentication.

2089
01:21:55,720 --> 01:21:58,760
It's tempting to test without auth because it's faster.

2090
01:21:58,760 --> 01:22:01,640
But auth configuration is the hardest part of remote deployment.

2091
01:22:01,640 --> 01:22:05,280
If you defer it, you'll be scrambling to add it later while the rest of the architecture

2092
01:22:05,280 --> 01:22:07,240
is built around an insecure pattern.

2093
01:22:07,240 --> 01:22:11,280
In weeks five and six, the most common pitfall is expecting co-pilot studio to magically

2094
01:22:11,280 --> 01:22:12,600
understand your tools.

2095
01:22:12,600 --> 01:22:13,600
It won't.

2096
01:22:13,600 --> 01:22:14,600
Tool discovery is mechanical.

2097
01:22:14,600 --> 01:22:16,680
The agent reads the description and the schema.

2098
01:22:16,680 --> 01:22:20,240
If your description says handle stuff, the agent won't know when to invoke it.

2099
01:22:20,240 --> 01:22:23,160
Write tool descriptions as if you're explaining the tool to a new employee.

2100
01:22:23,160 --> 01:22:24,160
Be specific.

2101
01:22:24,160 --> 01:22:26,880
Be explicit and test with real queries.

2102
01:22:26,880 --> 01:22:31,960
In weeks seven and eight, the most common pitfall is exposing too much organizational context.

2103
01:22:31,960 --> 01:22:33,960
Work IQ has access to a lot of data.

2104
01:22:33,960 --> 01:22:36,080
Not all of it should be available to all agents.

2105
01:22:36,080 --> 01:22:37,240
Define scope boundaries.

2106
01:22:37,240 --> 01:22:41,240
Use conditional access to restrict which agents can query which work IQ tools.

2107
01:22:41,240 --> 01:22:45,480
And review the data classification of documents before agents start reading them at scale.

2108
01:22:45,480 --> 01:22:49,680
In weeks nine and ten, the most common pitfall is treating agent identity as an afterthought.

2109
01:22:49,680 --> 01:22:50,760
Your agents aren't users.

2110
01:22:50,760 --> 01:22:51,760
They don't have managers.

2111
01:22:51,760 --> 01:22:52,840
They don't have job titles.

2112
01:22:52,840 --> 01:22:54,720
They have capabilities and permissions.

2113
01:22:54,720 --> 01:22:56,880
Design the identity model from the start.

2114
01:22:56,880 --> 01:23:01,160
Map each agent to a specific business function and assign permissions based on that function

2115
01:23:01,160 --> 01:23:04,320
rather than copying a human user's role.

2116
01:23:04,320 --> 01:23:08,280
In weeks eleven and twelve, the most common pitfall is declaring victory after the first

2117
01:23:08,280 --> 01:23:09,880
successful deployment.

2118
01:23:09,880 --> 01:23:10,880
Production isn't a destination.

2119
01:23:10,880 --> 01:23:15,440
It's a state that requires continuous monitoring, continuous tuning and continuous improvement.

2120
01:23:15,440 --> 01:23:16,440
Setup dashboards.

2121
01:23:16,440 --> 01:23:17,440
Define SLAs.

2122
01:23:17,440 --> 01:23:20,320
Create alert rules and review the metrics weekly.

2123
01:23:20,320 --> 01:23:22,080
One more pitfall spans all twelve weeks.

2124
01:23:22,080 --> 01:23:25,560
It's the assumption that MCP is just a technical protocol.

2125
01:23:25,560 --> 01:23:27,960
That you can hand it to the integration team and forget about it.

2126
01:23:27,960 --> 01:23:29,560
MCP isn't just a protocol.

2127
01:23:29,560 --> 01:23:30,880
It's an architectural pattern.

2128
01:23:30,880 --> 01:23:32,760
It changes how your agents connect to systems.

2129
01:23:32,760 --> 01:23:35,240
It changes how your systems expose capabilities.

2130
01:23:35,240 --> 01:23:38,320
It changes how your security team thinks about identity.

2131
01:23:38,320 --> 01:23:41,560
And it changes how your business teams think about what AI can do.

2132
01:23:41,560 --> 01:23:43,880
Treat it as architecture, not as integration.

2133
01:23:43,880 --> 01:23:48,040
All of your security team in week one, involve your operations team in week three, involve

2134
01:23:48,040 --> 01:23:51,640
your business stakeholders in week five, and involve your executive sponsor throughout

2135
01:23:51,640 --> 01:23:55,680
because the connectivity layer your building will outlast your current AI strategy.

2136
01:23:55,680 --> 01:23:59,880
It will outlast your current co-pilot licenses and it will become the foundation for every

2137
01:23:59,880 --> 01:24:03,760
AI initiative your organization runs for the next decade.

2138
01:24:03,760 --> 01:24:04,760
That's the roadmap.

2139
01:24:04,760 --> 01:24:08,400
90 days from a single local tool to a production ready connectivity layer.

2140
01:24:08,400 --> 01:24:11,840
It's aggressive, but it's achievable if you follow the sequence and it's the difference

2141
01:24:11,840 --> 01:24:16,840
between running AI pilots that hit walls and running AI agents that transform how your organization

2142
01:24:16,840 --> 01:24:18,160
works.

2143
01:24:18,160 --> 01:24:20,760
That's the connectivity layer your agents have been missing.

2144
01:24:20,760 --> 01:24:22,880
MCP isn't an integration afterthought.

2145
01:24:22,880 --> 01:24:25,840
It's the structural foundation of your agentech architecture.

2146
01:24:25,840 --> 01:24:29,640
If this changed how you think about building AI in Microsoft environments, follow me,

2147
01:24:29,640 --> 01:24:33,200
Mirko Peters, on LinkedIn, and share this with your architecture team.

2148
01:24:33,200 --> 01:24:37,120
Because the organizations that build this layer now will define what their agents can do

2149
01:24:37,120 --> 01:24:38,080
for the next decade.