Merge branch 'main' into add-meeting-info

Author: olaservo

docs/clients.mdx

@@ -62,6 +62,7 @@ This page provides an overview of applications that support the Model Context Pr
 | [Lutra][Lutra]                                   | ✅          | ✅        | ✅      | ❓                     | ❌         | ❌    | ❓            |
 | [mcp-agent][mcp-agent]                           | ✅          | ✅        | ✅      | ❓                     | ⚠️         | ✅    | ✅            |
 | [mcp-client-chatbot][mcp-client-chatbot]         | ❌          | ❌        | ✅      | ❌                     | ❌         | ❌    | ❓            |
+| [MCPJam][MCPJam]                                 | ✅          | ✅        | ✅      | ❓                     | ❌         | ❌    | ✅            |
 | [mcp-use][mcp-use]                               | ✅          | ✅        | ✅      | ✅                     | ✅         | ❌    | ✅            |
 | [modelcontextchat.com][modelcontextchat.com]     | ❌          | ❌        | ✅      | ❓                     | ❌         | ❌    | ❓            |
 | [MCPHub][MCPHub]                                 | ✅          | ✅        | ✅      | ❓                     | ❌         | ❌    | ❓            |
@@ -158,6 +159,7 @@ This page provides an overview of applications that support the Model Context Pr
 [Lutra]: https://lutra.ai
 [mcp-agent]: https://github.com/lastmile-ai/mcp-agent
 [mcp-client-chatbot]: https://github.com/cgoinglove/mcp-client-chatbot
+[MCPJam]: https://github.com/MCPJam/inspector
 [mcp-use]: https://github.com/pietrozullo/mcp-use
 [modelcontextchat.com]: https://modelcontextchat.com
 [MCPHub]: https://github.com/ravitemer/mcphub.nvim
@@ -782,6 +784,18 @@ Langflow is an open-source visual builder that lets developers rapidly prototype
 - All MCP tools are provided to the LLM by default, but the project also includes an optional `@toolname` mention feature to make tool invocation more explicit—particularly useful when connecting to multiple MCP servers with many tools.
 - Visual workflow builder that lets you create custom tools by chaining LLM nodes and MCP tools together. Published workflows become callable as `@workflow_name` tools in chat, enabling complex multi-step automation sequences.
 
+### MCPJam
+
+[MCPJam] is an open source testing and debugging tool for MCP servers - Postman for MCP servers.
+
+**Key features:**
+
+- Test your MCP server's tools, resources, prompts, and OAuth. MCP spec compliant.
+- LLM playground to test your server against different LLMs.
+- Tracing and logging error messages.
+- Connect and test multiple MCP servers simultaneously.
+- Supports all transports - STDIO, SSE, and Streamable HTTP.
+
 ### mcp-use
 
 [mcp-use] is an open source python library to very easily connect any LLM to any MCP server both locally and remotely.

docs/docs.json

@@ -371,10 +371,6 @@
       "source": "/docs/concepts",
       "destination": "/docs/learn/architecture"
     },
-    {
-      "source": "/docs/tools",
-      "destination": "/legacy/tools/inspector"
-    },
     {
       "source": "/docs/tutorials/use-remote-mcp-server",
       "destination": "/docs/develop/connect-remote-servers"

docs/docs/develop/build-server.mdx

@@ -1856,6 +1856,17 @@ tail -n 20 -f ~/Library/Logs/Claude/mcp*.log
 2. Make sure the path to your project is absolute and not relative
 3. Restart Claude for Desktop completely
 
+<Warning>
+
+To properly restart Claude for Desktop, you must fully quit the application:
+
+- **Windows**: Right-click the Claude icon in the system tray (which may be hidden in the "hidden icons" menu) and select "Quit" or "Exit".
+- **macOS**: Use Cmd+Q or select "Quit Claude" from the menu bar.
+
+Simply closing the window does not fully quit the application, and your MCP server configuration changes will not take effect.
+
+</Warning>
+
 **Tool calls failing silently**
 
 If Claude attempts to use the tools but they fail:

docs/docs/learn/architecture.mdx

@@ -55,13 +55,6 @@ graph TB
     Client1 ---|"One-to-one<br/>connection"| Server1
     Client2 ---|"One-to-one<br/>connection"| Server2
     Client3 ---|"One-to-one<br/>connection"| Server3
-
-    style Client1 fill:#e1f5fe
-    style Client2 fill:#e1f5fe
-    style Client3 fill:#e1f5fe
-    style Server1 fill:#f3e5f5
-    style Server2 fill:#f3e5f5
-    style Server3 fill:#f3e5f5
 ```
 
 Note that **MCP server** refers to the program that serves context data, regardless of

docs/docs/learn/client-concepts.mdx

@@ -14,7 +14,7 @@ In addition to making use of context provided by servers, clients may provide se
 | Feature         | Explanation                                                                                                                                                                                       | Example                                                                                                                                |
 | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
 | **Sampling**    | Sampling allows servers to request LLM completions through the client, enabling an agentic workflow. This approach puts the client in complete control of user permissions and security measures. | A server for booking travel may send a list of flights to an LLM and request that the LLM pick the best flight for the user.           |
-| **Roots**       | Roots allow clients to specify which files servers can access, guiding them to relevant directories while maintaining security boundaries.                                                        | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar.                     |
+| **Roots**       | Roots allow clients to specify which directories servers should focus on, communicating intended scope through a coordination mechanism.                                                          | A server for booking travel may be given access to a specific directory, from which it can read a user's calendar.                     |
 | **Elicitation** | Elicitation enables servers to request specific information from users during interactions, providing a structured way for servers to gather information on demand.                               | A server booking travel may ask for the user's preferences on airplane seats, room type or their contact number to finalise a booking. |
 
 ### Elicitation
@@ -108,7 +108,7 @@ Roots define filesystem boundaries for server operations, allowing clients to sp
 
 #### Overview
 
-Roots are a mechanism for clients to communicate filesystem access boundaries to servers. They consist of file URIs that indicate directories where servers can operate, helping servers understand the scope of available files and folders. Rather than giving servers unrestricted filesystem access, roots guide them to relevant working directories while maintaining security boundaries.
+Roots are a mechanism for clients to communicate filesystem access boundaries to servers. They consist of file URIs that indicate directories where servers can operate, helping servers understand the scope of available files and folders. Rather than giving servers unrestricted filesystem access, roots guide them to relevant working directories. While roots communicate intended boundaries, actual security is always maintained by the client's access controls.
 
 **Root structure:**
 
@@ -121,8 +121,6 @@ Roots are a mechanism for clients to communicate filesystem access boundaries to
 
 Roots are exclusively filesystem paths and always use the `file://` URI scheme. They help servers understand project boundaries, workspace organization, and accessible directories. The roots list can be updated dynamically as users work with different projects or folders, with servers receiving notifications through `roots/list_changed` when boundaries change.
 
-It's important to note that while roots provide guidance to servers about where to operate, the client is always in full control of file access. Roots simply communicate intended boundaries—actual file access is always mediated by the client's security policies.
-
 #### Example: Travel Planning Workspace
 
 A travel agent working with multiple client trips benefits from roots to organize filesystem access. Consider a workspace with different directories for various aspects of travel planning.
@@ -133,15 +131,23 @@ The client provides filesystem roots to the travel planning server:
 - `file:///Users/agent/travel-templates` - Reusable itinerary templates and resources
 - `file:///Users/agent/client-documents` - Client passports and travel documents
 
-When the agent creates a Barcelona itinerary, the server works within these boundaries—accessing templates, saving the new itinerary, and referencing client documents. It cannot access files outside these roots. Servers typically access files within roots by using relative paths from the root directories or by utilizing file search tools that respect the root boundaries.
+When the agent creates a Barcelona itinerary, well-behaved servers respect these boundaries—accessing templates, saving the new itinerary, and referencing client documents within the specified roots. Servers typically access files within roots by using relative paths from the root directories or by utilizing file search tools that respect the root boundaries.
 
 If the agent opens an archive folder like `file:///Users/agent/archive/2023-trips`, the client updates the roots list via `roots/list_changed`.
 
+For a complete implementation of a server that respects roots, see the [filesystem server](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem) in the official servers repository.
+
+#### Design Philosophy
+
+Roots serve as a coordination mechanism between clients and servers, not a security boundary. The specification requires that servers "SHOULD respect root boundaries," and not that they "MUST enforce" them, because servers run code the client cannot control. This design is pragmatic: clients enforce security while roots communicate intent.
+
+Roots work best when servers are trusted or vetted, users understand their advisory nature, and the goal is preventing accidents rather than stopping malicious behavior. They excel at context scoping (telling servers where to focus), accident prevention (helping well-behaved servers stay in bounds), and workflow organization (such as managing project boundaries automatically).
+
 #### User Interaction Model
 
 Roots are typically managed automatically by host applications based on user actions, though some applications may expose manual root management:
 
-**Automatic root detection**: When users open folders, clients automatically expose them as roots. Opening a travel workspace gives servers access to itineraries and documents within that directory.
+**Automatic root detection**: When users open folders, clients automatically expose them as roots. Opening a travel workspace allows the client to expose that directory as a root, helping servers understand which itineraries and documents are in scope for the current work.
 
 **Manual root configuration**: Advanced users can specify roots through configuration. For example, adding `/travel-templates` for reusable resources while excluding directories with financial records.
 

docs/style.css

@@ -578,7 +578,7 @@ body:has(#schema-reference) {
     border-radius: 9999px;
 
     border: 6px solid var(--highlight-color);
-    color: white
+    color: white;
 
     font-size: 1.5rem;
     font-weight: 700;