Home Docs Model Context Protocol 20 Oct 2026

One change · mcp

Architecture overview changeddocs/2024-11-05/learn/architecture

Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 20:07 UTC.

Upstream edited 20 Oct 2026 20:02 UTC

Recorded here 20 Oct 2026 20:07 UTC

Lines+304added

Lines−312removed

From line 15 where the diff opens

First seen 26 Aug 2026 this site's first read of the page

Recorded edits2to this page, all time

#### Understanding the Initialization Exchange #### How This Works in AI Applications #### Understanding the Tool Discovery Request #### Understanding the Tool Discovery Response #### How This Works in AI Applications #### Understanding the Tool Execution Request #### Key Elements of Tool Execution #### Understanding the Tool Execution Response #### How This Works in AI Applications #### Understanding Tool List Change Notifications #### Key Features of MCP Notifications #### Client Response to Notifications #### Why Notifications Matter #### How This Works in AI Applications

The whole hunk

from line 15, old and new numbered

lines

The two sides of this change are more than 400 edits apart, too far apart to line up, so this is the differ's own diff of it and the words inside a line are not marked.

from line 15

1515* **MCP Development Tools**: Tools for developing MCP servers and clients, including the [MCP Inspector](https://github.com/modelcontextprotocol/inspector)

1616* [MCP Reference Server Implementations](https://github.com/modelcontextprotocol/servers): Reference implementations of MCP servers.

1717

18<Note>

19 MCP focuses solely on the protocol for context exchange—it does not dictate

20 how AI applications use LLMs or manage the provided context.

21</Note>

18> [!NOTE]

19>

20> MCP focuses solely on the protocol for context exchange—it does not dictate

21> how AI applications use LLMs or manage the provided context.

2222

2323## Concepts of MCP

2424

from line 104

104104

105105#### Lifecycle management

106106

107MCP is a stateful protocol that requires lifecycle management. The purpose of lifecycle management is to negotiate the <Tooltip tip="Features and operations that a client or server supports, such as tools, resources, or prompts">capabilities</Tooltip> that both client and server support. Detailed information can be found in the [specification](/specification/2024-11-05/basic/lifecycle), and the [example](#example) showcases the initialization sequence.

107MCP is a stateful protocol that requires lifecycle management. The purpose of lifecycle management is to negotiate the capabilities (Features and operations that a client or server supports, such as tools, resources, or prompts) that both client and server support. Detailed information can be found in the [specification](/specification/2024-11-05/basic/lifecycle), and the [example](#example) showcases the initialization sequence.

108108

109109#### Primitives

110110

from line 144

144144

145145This section provides a step-by-step walkthrough of an MCP client-server interaction, focusing on the data layer protocol. We'll demonstrate the lifecycle sequence, tool operations, and notifications using JSON-RPC 2.0 messages.

146146

147<Steps>

148 <Step title="Initialization (Lifecycle Management)">

149 MCP begins with lifecycle management through a capability negotiation handshake. As described in the [lifecycle management](#lifecycle-management) section, the client sends an `initialize` request to establish the connection and negotiate supported features.

150

151 <CodeGroup>

152 ```json Initialize Request theme={null}

147**1. Initialization (Lifecycle Management)**

148

149MCP begins with lifecycle management through a capability negotiation handshake. As described in the [lifecycle management](#lifecycle-management) section, the client sends an `initialize` request to establish the connection and negotiate supported features.

150

151```json Initialize Request theme={null}

152{

153 "jsonrpc": "2.0",

154 "id": 1,

155 "method": "initialize",

156 "params": {

157 "protocolVersion": "2024-11-05",

158 "capabilities": {

159 "sampling": {}

160 },

161 "clientInfo": {

162 "name": "example-client",

163 "version": "1.0.0"

164 }

165 }

166}

167```

168

169```json Initialize Response theme={null}

170{

171 "jsonrpc": "2.0",

172 "id": 1,

173 "result": {

174 "protocolVersion": "2024-11-05",

175 "capabilities": {

176 "tools": {

177 "listChanged": true

178 },

179 "resources": {}

180 },

181 "serverInfo": {

182 "name": "example-server",

183 "version": "1.0.0"

184 }

185 }

186}

187```

188

189#### Understanding the Initialization Exchange

190

191The initialization process is a key part of MCP's lifecycle management and serves several critical purposes:

192

1931. **Protocol Version Negotiation**: The `protocolVersion` field (e.g., "2024-11-05") ensures both client and server are using compatible protocol versions. This prevents communication errors that could occur when different versions attempt to interact. If a mutually compatible version is not negotiated, the connection should be terminated.

194

1952. **Capability Discovery**: The `capabilities` object allows each party to declare what features they support, including which [primitives](#primitives) they can handle (tools, resources, prompts) and whether they support features like [notifications](#notifications). This enables efficient communication by avoiding unsupported operations.

196

1973. **Identity Exchange**: The `clientInfo` and `serverInfo` objects provide identification and versioning information for debugging and compatibility purposes.

198

199In this example, the capability negotiation demonstrates how MCP primitives are declared:

200

201**Client Capabilities**:

202

203* `"sampling": {}` - The client declares it can handle server sampling requests (can receive `sampling/createMessage` method calls)

204

205**Server Capabilities**:

206

207* `"tools": {"listChanged": true}` - The server supports the tools primitive AND can send `tools/list_changed` notifications when its tool list changes

208* `"resources": {}` - The server also supports the resources primitive (can handle `resources/list` and `resources/read` methods)

209

210After successful initialization, the client sends a notification to indicate it's ready:

211

212```json Notification theme={null}

213{

214 "jsonrpc": "2.0",

215 "method": "notifications/initialized"

216}

217```

218

219#### How This Works in AI Applications

220

221During initialization, the AI application's MCP client manager establishes connections to configured servers and stores their capabilities for later use. The application uses this information to determine which servers can provide specific types of functionality (tools, resources, prompts) and whether they support real-time updates.

222

223```python Pseudo-code for AI application initialization theme={null}

224# Pseudo Code

225async with stdio_client(server_config) as (read, write):

226 async with ClientSession(read, write) as session:

227 init_response = await session.initialize()

228 if init_response.capabilities.tools:

229 app.register_mcp_server(session, supports_tools=True)

230 app.set_server_ready(session)

231```

232

233**2. Tool Discovery (Primitives)**

234

235Now that the connection is established, the client can discover available tools by sending a `tools/list` request. This request is fundamental to MCP's tool discovery mechanism — it allows clients to understand what tools are available on the server before attempting to use them.

236

237```json Tools List Request theme={null}

238{

239 "jsonrpc": "2.0",

240 "id": 2,

241 "method": "tools/list"

242}

243```

244

245```json Tools List Response theme={null}

246{

247 "jsonrpc": "2.0",

248 "id": 2,

249 "result": {

250 "tools": [

153251 {

154 "jsonrpc": "2.0",

155 "id": 1,

156 "method": "initialize",

157 "params": {

158 "protocolVersion": "2024-11-05",

159 "capabilities": {

160 "sampling": {}

252 "name": "calculator_arithmetic",

253 "title": "Calculator",

254 "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",

255 "inputSchema": {

256 "type": "object",

257 "properties": {

258 "expression": {

259 "type": "string",

260 "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"

261 }

161262 },

162 "clientInfo": {

163 "name": "example-client",

164 "version": "1.0.0"

165 }

263 "required": ["expression"]

264 }

265 },

266 {

267 "name": "weather_current",

268 "title": "Weather Information",

269 "description": "Get current weather information for any location worldwide",

270 "inputSchema": {

271 "type": "object",

272 "properties": {

273 "location": {

274 "type": "string",

275 "description": "City name, address, or coordinates (latitude,longitude)"

276 },

277 "units": {

278 "type": "string",

279 "enum": ["metric", "imperial", "kelvin"],

280 "description": "Temperature units to use in response",

281 "default": "metric"

282 }

283 },

284 "required": ["location"]

166285 }

167286 }

168 ```

169

170 ```json Initialize Response theme={null}

287 ]

288 }

289}

290```

291

292#### Understanding the Tool Discovery Request

293

294The `tools/list` request is simple, containing no parameters.

295

296#### Understanding the Tool Discovery Response

297

298The response contains a `tools` array that provides comprehensive metadata about each available tool. This array-based structure allows servers to expose multiple tools simultaneously while maintaining clear boundaries between different functionalities.

299

300Each tool object in the response includes several key fields:

301

302* **`name`**: A unique identifier for the tool within the server's namespace. This serves as the primary key for tool execution and should follow a clear naming pattern (e.g., `calculator_arithmetic` rather than just `calculate`)

303* **`title`**: A human-readable display name for the tool that clients can show to users

304* **`description`**: Detailed explanation of what the tool does and when to use it

305* **`inputSchema`**: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parameters

306

307#### How This Works in AI Applications

308

309The AI application fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access. This allows the LLM to understand what actions it can perform and automatically generates the appropriate tool calls during conversations.

310

311```python Pseudo-code for AI application tool discovery theme={null}

312# Pseudo-code using MCP Python SDK patterns

313available_tools = []

314for session in app.mcp_server_sessions():

315 tools_response = await session.list_tools()

316 available_tools.extend(tools_response.tools)

317conversation.register_available_tools(available_tools)

318```

319

320**3. Tool Execution (Primitives)**

321

322The client can now execute a tool using the `tools/call` method. This demonstrates how MCP primitives are used in practice: after discovering available tools, the client can invoke them with appropriate arguments.

323

324#### Understanding the Tool Execution Request

325

326The `tools/call` request follows a structured format that ensures type safety and clear communication between client and server. Note that we're using the proper tool name from the discovery response (`weather_current`) rather than a simplified name:

327

328```json Tool Call Request theme={null}

329{

330 "jsonrpc": "2.0",

331 "id": 3,

332 "method": "tools/call",

333 "params": {

334 "name": "weather_current",

335 "arguments": {

336 "location": "San Francisco",

337 "units": "imperial"

338 }

339 }

340}

341```

342

343```json Tool Call Response theme={null}

344{

345 "jsonrpc": "2.0",

346 "id": 3,

347 "result": {

348 "content": [

171349 {

172 "jsonrpc": "2.0",

173 "id": 1,

174 "result": {

175 "protocolVersion": "2024-11-05",

176 "capabilities": {

177 "tools": {

178 "listChanged": true

179 },

180 "resources": {}

181 },

182 "serverInfo": {

183 "name": "example-server",

184 "version": "1.0.0"

185 }

186 }

350 "type": "text",

351 "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"

187352 }

188 ```

189 </CodeGroup>

190

191 #### Understanding the Initialization Exchange

192

193 The initialization process is a key part of MCP's lifecycle management and serves several critical purposes:

194

195 1. **Protocol Version Negotiation**: The `protocolVersion` field (e.g., "2024-11-05") ensures both client and server are using compatible protocol versions. This prevents communication errors that could occur when different versions attempt to interact. If a mutually compatible version is not negotiated, the connection should be terminated.

196

197 2. **Capability Discovery**: The `capabilities` object allows each party to declare what features they support, including which [primitives](#primitives) they can handle (tools, resources, prompts) and whether they support features like [notifications](#notifications). This enables efficient communication by avoiding unsupported operations.

198

199 3. **Identity Exchange**: The `clientInfo` and `serverInfo` objects provide identification and versioning information for debugging and compatibility purposes.

200

201 In this example, the capability negotiation demonstrates how MCP primitives are declared:

202

203 **Client Capabilities**:

204

205 * `"sampling": {}` - The client declares it can handle server sampling requests (can receive `sampling/createMessage` method calls)

206

207 **Server Capabilities**:

208

209 * `"tools": {"listChanged": true}` - The server supports the tools primitive AND can send `tools/list_changed` notifications when its tool list changes

210 * `"resources": {}` - The server also supports the resources primitive (can handle `resources/list` and `resources/read` methods)

211

212 After successful initialization, the client sends a notification to indicate it's ready:

213

214 ```json Notification theme={null}

215 {

216 "jsonrpc": "2.0",

217 "method": "notifications/initialized"

218 }

219 ```

220

221 #### How This Works in AI Applications

222

223 During initialization, the AI application's MCP client manager establishes connections to configured servers and stores their capabilities for later use. The application uses this information to determine which servers can provide specific types of functionality (tools, resources, prompts) and whether they support real-time updates.

224

225 ```python Pseudo-code for AI application initialization theme={null}

226 # Pseudo Code

227 async with stdio_client(server_config) as (read, write):

228 async with ClientSession(read, write) as session:

229 init_response = await session.initialize()

230 if init_response.capabilities.tools:

231 app.register_mcp_server(session, supports_tools=True)

232 app.set_server_ready(session)

233 ```

234 </Step>

235

236 <Step title="Tool Discovery (Primitives)">

237 Now that the connection is established, the client can discover available tools by sending a `tools/list` request. This request is fundamental to MCP's tool discovery mechanism — it allows clients to understand what tools are available on the server before attempting to use them.

238

239 <CodeGroup>

240 ```json Tools List Request theme={null}

241 {

242 "jsonrpc": "2.0",

243 "id": 2,

244 "method": "tools/list"

245 }

246 ```

247

248 ```json Tools List Response theme={null}

249 {

250 "jsonrpc": "2.0",

251 "id": 2,

252 "result": {

253 "tools": [

254 {

255 "name": "calculator_arithmetic",

256 "title": "Calculator",

257 "description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",

258 "inputSchema": {

259 "type": "object",

260 "properties": {

261 "expression": {

262 "type": "string",

263 "description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"

264 }

265 },

266 "required": ["expression"]

267 }

268 },

269 {

270 "name": "weather_current",

271 "title": "Weather Information",

272 "description": "Get current weather information for any location worldwide",

273 "inputSchema": {

274 "type": "object",

275 "properties": {

276 "location": {

277 "type": "string",

278 "description": "City name, address, or coordinates (latitude,longitude)"

279 },

280 "units": {

281 "type": "string",

282 "enum": ["metric", "imperial", "kelvin"],

283 "description": "Temperature units to use in response",

284 "default": "metric"

285 }

286 },

287 "required": ["location"]

288 }

289 }

290 ]

291 }

292 }

293 ```

294 </CodeGroup>

295

296 #### Understanding the Tool Discovery Request

297

298 The `tools/list` request is simple, containing no parameters.

299

300 #### Understanding the Tool Discovery Response

301

302 The response contains a `tools` array that provides comprehensive metadata about each available tool. This array-based structure allows servers to expose multiple tools simultaneously while maintaining clear boundaries between different functionalities.

303

304 Each tool object in the response includes several key fields:

305

306 * **`name`**: A unique identifier for the tool within the server's namespace. This serves as the primary key for tool execution and should follow a clear naming pattern (e.g., `calculator_arithmetic` rather than just `calculate`)

307 * **`title`**: A human-readable display name for the tool that clients can show to users

308 * **`description`**: Detailed explanation of what the tool does and when to use it

309 * **`inputSchema`**: A JSON Schema that defines the expected input parameters, enabling type validation and providing clear documentation about required and optional parameters

310

311 #### How This Works in AI Applications

312

313 The AI application fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access. This allows the LLM to understand what actions it can perform and automatically generates the appropriate tool calls during conversations.

314

315 ```python Pseudo-code for AI application tool discovery theme={null}

316 # Pseudo-code using MCP Python SDK patterns

317 available_tools = []

318 for session in app.mcp_server_sessions():

319 tools_response = await session.list_tools()

320 available_tools.extend(tools_response.tools)

321 conversation.register_available_tools(available_tools)

322 ```

323 </Step>

324

325 <Step title="Tool Execution (Primitives)">

326 The client can now execute a tool using the `tools/call` method. This demonstrates how MCP primitives are used in practice: after discovering available tools, the client can invoke them with appropriate arguments.

327

328 #### Understanding the Tool Execution Request

329

330 The `tools/call` request follows a structured format that ensures type safety and clear communication between client and server. Note that we're using the proper tool name from the discovery response (`weather_current`) rather than a simplified name:

331

332 <CodeGroup>

333 ```json Tool Call Request theme={null}

334 {

335 "jsonrpc": "2.0",

336 "id": 3,

337 "method": "tools/call",

338 "params": {

339 "name": "weather_current",

340 "arguments": {

341 "location": "San Francisco",

342 "units": "imperial"

343 }

344 }

345 }

346 ```

347

348 ```json Tool Call Response theme={null}

349 {

350 "jsonrpc": "2.0",

351 "id": 3,

352 "result": {

353 "content": [

354 {

355 "type": "text",

356 "text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"

357 }

358 ]

359 }

360 }

361 ```

362 </CodeGroup>

363

364 #### Key Elements of Tool Execution

365

366 The request structure includes several important components:

367

368 1. **`name`**: Must match exactly the tool name from the discovery response (`weather_current`). This ensures the server can correctly identify which tool to execute.

369

370 2. **`arguments`**: Contains the input parameters as defined by the tool's `inputSchema`. In this example:

371 * `location`: "San Francisco" (required parameter)

372 * `units`: "imperial" (optional parameter, defaults to "metric" if not specified)

373

374 3. **JSON-RPC Structure**: Uses standard JSON-RPC 2.0 format with unique `id` for request-response correlation.

375

376 #### Understanding the Tool Execution Response

377

378 The response demonstrates MCP's flexible content system:

379

380 1. **`content` Array**: Tool responses return an array of content objects, allowing for rich, multi-format responses (text, images, resources, etc.)

381

382 2. **Content Types**: Each content object has a `type` field. In this example, `"type": "text"` indicates plain text content, but MCP supports various content types for different use cases.

383

384 3. **Structured Output**: The response provides actionable information that the AI application can use as context for language model interactions.

385

386 This execution pattern allows AI applications to dynamically invoke server functionality and receive structured responses that can be integrated into conversations with language models.

387

388 #### How This Works in AI Applications

389

390 When the language model decides to use a tool during a conversation, the AI application intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM as part of the conversation flow. This enables the LLM to access real-time data and perform actions in the external world.

391

392 ```python theme={null}

393 # Pseudo-code for AI application tool execution

394 async def handle_tool_call(conversation, tool_name, arguments):

395 session = app.find_mcp_session_for_tool(tool_name)

396 result = await session.call_tool(tool_name, arguments)

397 conversation.add_tool_result(result.content)

398 ```

399 </Step>

400

401 <Step title="Real-time Updates (Notifications)">

402 MCP supports real-time notifications that enable servers to inform clients about changes without being explicitly requested. This demonstrates the notification system, a key feature that keeps MCP connections synchronized and responsive.

403

404 #### Understanding Tool List Change Notifications

405

406 When the server's available tools change—such as when new functionality becomes available, existing tools are modified, or tools become temporarily unavailable—the server can proactively notify connected clients:

407

408 ```json Request theme={null}

409 {

410 "jsonrpc": "2.0",

411 "method": "notifications/tools/list_changed"

412 }

413 ```

414

415 #### Key Features of MCP Notifications

416

417 1. **No Response Required**: Notice there's no `id` field in the notification. This follows JSON-RPC 2.0 notification semantics where no response is expected or sent.

418

419 2. **Capability-Based**: This notification is only sent by servers that declared `"listChanged": true` in their tools capability during initialization (as shown in Step 1).

420

421 3. **Event-Driven**: The server decides when to send notifications based on internal state changes, making MCP connections dynamic and responsive.

422

423 #### Client Response to Notifications

424

425 Upon receiving this notification, the client typically reacts by requesting the updated tool list. This creates a refresh cycle that keeps the client's understanding of available tools current:

426

427 ```json Request theme={null}

428 {

429 "jsonrpc": "2.0",

430 "id": 4,

431 "method": "tools/list"

432 }

433 ```

434

435 #### Why Notifications Matter

436

437 This notification system is crucial for several reasons:

438

439 1. **Dynamic Environments**: Tools may come and go based on server state, external dependencies, or user permissions

440 2. **Efficiency**: Clients don't need to poll for changes; they're notified when updates occur

441 3. **Consistency**: Ensures clients always have accurate information about available server capabilities

442 4. **Real-time Collaboration**: Enables responsive AI applications that can adapt to changing contexts

443

444 This notification pattern extends beyond tools to other MCP primitives, enabling comprehensive real-time synchronization between clients and servers.

445

446 #### How This Works in AI Applications

447

448 When the AI application receives a notification about changed tools, it immediately refreshes its tool registry and updates the LLM's available capabilities. This ensures that ongoing conversations always have access to the most current set of tools, and the LLM can dynamically adapt to new functionality as it becomes available.

449

450 ```python theme={null}

451 # Pseudo-code for AI application notification handling

452 async def handle_tools_changed_notification(session):

453 tools_response = await session.list_tools()

454 app.update_available_tools(session, tools_response.tools)

455 if app.conversation.is_active():

456 app.conversation.notify_llm_of_new_capabilities()

457 ```

458 </Step>

459</Steps>

353 ]

354 }

355}

356```

357

358#### Key Elements of Tool Execution

359

360The request structure includes several important components:

361

3621. **`name`**: Must match exactly the tool name from the discovery response (`weather_current`). This ensures the server can correctly identify which tool to execute.

363

3642. **`arguments`**: Contains the input parameters as defined by the tool's `inputSchema`. In this example:

365 * `location`: "San Francisco" (required parameter)

366 * `units`: "imperial" (optional parameter, defaults to "metric" if not specified)

367

3683. **JSON-RPC Structure**: Uses standard JSON-RPC 2.0 format with unique `id` for request-response correlation.

369

370#### Understanding the Tool Execution Response

371

372The response demonstrates MCP's flexible content system:

373

3741. **`content` Array**: Tool responses return an array of content objects, allowing for rich, multi-format responses (text, images, resources, etc.)

375

3762. **Content Types**: Each content object has a `type` field. In this example, `"type": "text"` indicates plain text content, but MCP supports various content types for different use cases.

377

3783. **Structured Output**: The response provides actionable information that the AI application can use as context for language model interactions.

379

380This execution pattern allows AI applications to dynamically invoke server functionality and receive structured responses that can be integrated into conversations with language models.

381

382#### How This Works in AI Applications

383

384When the language model decides to use a tool during a conversation, the AI application intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM as part of the conversation flow. This enables the LLM to access real-time data and perform actions in the external world.

385

386```python theme={null}

387# Pseudo-code for AI application tool execution

388async def handle_tool_call(conversation, tool_name, arguments):

389 session = app.find_mcp_session_for_tool(tool_name)

390 result = await session.call_tool(tool_name, arguments)

391 conversation.add_tool_result(result.content)

392```

393

394**4. Real-time Updates (Notifications)**

395

396MCP supports real-time notifications that enable servers to inform clients about changes without being explicitly requested. This demonstrates the notification system, a key feature that keeps MCP connections synchronized and responsive.

397

398#### Understanding Tool List Change Notifications

399

400When the server's available tools change—such as when new functionality becomes available, existing tools are modified, or tools become temporarily unavailable—the server can proactively notify connected clients:

401

402```json Request theme={null}

403{

404 "jsonrpc": "2.0",

405 "method": "notifications/tools/list_changed"

406}

407```

408

409#### Key Features of MCP Notifications

410

4111. **No Response Required**: Notice there's no `id` field in the notification. This follows JSON-RPC 2.0 notification semantics where no response is expected or sent.

412

4132. **Capability-Based**: This notification is only sent by servers that declared `"listChanged": true` in their tools capability during initialization (as shown in Step 1).

414

4153. **Event-Driven**: The server decides when to send notifications based on internal state changes, making MCP connections dynamic and responsive.

416

417#### Client Response to Notifications

418

419Upon receiving this notification, the client typically reacts by requesting the updated tool list. This creates a refresh cycle that keeps the client's understanding of available tools current:

420

421```json Request theme={null}

422{

423 "jsonrpc": "2.0",

424 "id": 4,

425 "method": "tools/list"

426}

427```

428

429#### Why Notifications Matter

430

431This notification system is crucial for several reasons:

432

4331. **Dynamic Environments**: Tools may come and go based on server state, external dependencies, or user permissions

4342. **Efficiency**: Clients don't need to poll for changes; they're notified when updates occur

4353. **Consistency**: Ensures clients always have accurate information about available server capabilities

4364. **Real-time Collaboration**: Enables responsive AI applications that can adapt to changing contexts

437

438This notification pattern extends beyond tools to other MCP primitives, enabling comprehensive real-time synchronization between clients and servers.

439

440#### How This Works in AI Applications

441

442When the AI application receives a notification about changed tools, it immediately refreshes its tool registry and updates the LLM's available capabilities. This ensures that ongoing conversations always have access to the most current set of tools, and the LLM can dynamically adapt to new functionality as it becomes available.

443

444```python theme={null}

445# Pseudo-code for AI application notification handling

446async def handle_tools_changed_notification(session):

447 tools_response = await session.list_tools()

448 app.update_available_tools(session, tools_response.tools)

449 if app.conversation.is_active():

450 app.conversation.notify_llm_of_new_capabilities()

451```

460452