Merge branch 'main' into nbarbettini/errata-1

nbarbettini · web-flow · commit 3a7f93476d40 · 2025-07-05T10:08:07.000-07:00
diff --git a/docs/clients.mdx b/docs/clients.mdx
diff --git a/docs/introduction.mdx b/docs/introduction.mdx
@@ -20,19 +20,22 @@ At its core, MCP follows a client-server architecture where a host application c
 ```mermaid
 flowchart LR
     subgraph "Your Computer"
-        Host["Host with MCP Client\n(Claude, IDEs, Tools)"]
+        Host["Host with MCP Client<br/>(Claude, IDEs, Tools)"]
         S1["MCP Server A"]
         S2["MCP Server B"]
-        S3["MCP Server C"]
+        D1[("Local<br/>Data Source A")]
         Host <-->|"MCP Protocol"| S1
         Host <-->|"MCP Protocol"| S2
-        Host <-->|"MCP Protocol"| S3
-        S1 <--> D1[("Local\nData Source A")]
-        S2 <--> D2[("Local\nData Source B")]
+        S1 <--> D1
     end
     subgraph "Internet"
-        S3 <-->|"Web APIs"| D3[("Remote\nService C")]
+        S3["MCP Server C"]
+        D2[("Remote<br/>Service B")]
+        D3[("Remote<br/>Service C")]
+        S2 <-->|"Web APIs"| D2
+        S3 <-->|"Web APIs"| D3
     end
+    Host <-->|"MCP Protocol"| S3
 ```
 
 - **MCP Hosts**: Programs like Claude Desktop, IDEs, or AI tools that want to access data through MCP
diff --git a/docs/quickstart/user.mdx b/docs/quickstart/user.mdx
@@ -39,7 +39,7 @@ Click on "Developer" in the left-hand bar of the Settings pane, and then click o
 
 This will create a configuration file at:
 
-- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
+- macOS: `~/Library/Application\ Support/Claude/claude_desktop_config.json`
 - Windows: `%APPDATA%\Claude\claude_desktop_config.json`
 
 if you don't already have one, and will display the file in your file system.
diff --git a/docs/specification/2025-06-18/client/elicitation.mdx b/docs/specification/2025-06-18/client/elicitation.mdx
@@ -37,7 +37,7 @@ Applications **SHOULD**:
 
 - Provide UI that makes it clear which server is requesting information
 - Allow users to review and modify their responses before sending
-- Respect user privacy and provide clear reject and cancel options
+- Respect user privacy and provide clear decline and cancel options
 
 </Warning>
 
@@ -158,7 +158,7 @@ To request information from a user, servers send an `elicitation/create` request
   "jsonrpc": "2.0",
   "id": 2,
   "result": {
-    "action": "reject"
+    "action": "decline"
   }
 }
 ```
@@ -289,7 +289,7 @@ Elicitation responses use a three-action model to clearly distinguish between di
   "jsonrpc": "2.0",
   "id": 1,
   "result": {
-    "action": "accept", // or "reject" or "cancel"
+    "action": "accept", // or "decline" or "cancel"
     "content": {
       "propertyName": "value",
       "anotherProperty": 42
@@ -305,7 +305,7 @@ The three response actions are:
    - The `content` field contains the submitted data matching the requested schema
    - Example: User clicked "Submit", "OK", "Confirm", etc.
 
-2. **Reject** (`action: "reject"`): User explicitly rejected the request
+2. **Decline** (`action: "decline"`): User explicitly declined the request
 
    - The `content` field is typically omitted
    - Example: User clicked "Reject", "Decline", "No", etc.
@@ -317,7 +317,7 @@ The three response actions are:
 Servers should handle each state appropriately:
 
 - **Accept**: Process the submitted data
-- **Reject**: Handle explicit rejection (e.g., offer alternatives)
+- **Decline**: Handle explicit decline (e.g., offer alternatives)
 - **Cancel**: Handle dismissal (e.g., prompt again later)
 
 ## Security Considerations
@@ -326,6 +326,6 @@ Servers should handle each state appropriately:
 2. Clients **SHOULD** implement user approval controls
 3. Both parties **SHOULD** validate elicitation content against the provided schema
 4. Clients **SHOULD** provide clear indication of which server is requesting information
-5. Clients **SHOULD** allow users to reject elicitation requests at any time
+5. Clients **SHOULD** allow users to decline elicitation requests at any time
 6. Clients **SHOULD** implement rate limiting
 7. Clients **SHOULD** present elicitation requests in a way that makes it clear what information is being requested and why
diff --git a/docs/specification/draft/client/elicitation.mdx b/docs/specification/draft/client/elicitation.mdx
@@ -37,7 +37,7 @@ Applications **SHOULD**:
 
 - Provide UI that makes it clear which server is requesting information
 - Allow users to review and modify their responses before sending
-- Respect user privacy and provide clear reject and cancel options
+- Respect user privacy and provide clear decline and cancel options
 
 </Warning>
 
@@ -158,7 +158,7 @@ To request information from a user, servers send an `elicitation/create` request
   "jsonrpc": "2.0",
   "id": 2,
   "result": {
-    "action": "reject"
+    "action": "decline"
   }
 }
 ```
@@ -290,7 +290,7 @@ Elicitation responses use a three-action model to clearly distinguish between di
   "jsonrpc": "2.0",
   "id": 1,
   "result": {
-    "action": "accept", // or "reject" or "cancel"
+    "action": "accept", // or "decline" or "cancel"
     "content": {
       "propertyName": "value",
       "anotherProperty": 42
@@ -306,7 +306,7 @@ The three response actions are:
    - The `content` field contains the submitted data matching the requested schema
    - Example: User clicked "Submit", "OK", "Confirm", etc.
 
-2. **Reject** (`action: "reject"`): User explicitly rejected the request
+2. **Decline** (`action: "decline"`): User explicitly declined the request
 
    - The `content` field is typically omitted
    - Example: User clicked "Reject", "Decline", "No", etc.
@@ -318,7 +318,7 @@ The three response actions are:
 Servers should handle each state appropriately:
 
 - **Accept**: Process the submitted data
-- **Reject**: Handle explicit rejection (e.g., offer alternatives)
+- **Decline**: Handle explicit decline (e.g., offer alternatives)
 - **Cancel**: Handle dismissal (e.g., prompt again later)
 
 ## Security Considerations
@@ -327,6 +327,6 @@ Servers should handle each state appropriately:
 2. Clients **SHOULD** implement user approval controls
 3. Both parties **SHOULD** validate elicitation content against the provided schema
 4. Clients **SHOULD** provide clear indication of which server is requesting information
-5. Clients **SHOULD** allow users to reject elicitation requests at any time
+5. Clients **SHOULD** allow users to decline elicitation requests at any time
 6. Clients **SHOULD** implement rate limiting
 7. Clients **SHOULD** present elicitation requests in a way that makes it clear what information is being requested and why
diff --git a/schema/draft/schema.json b/schema/draft/schema.json
diff --git a/schema/draft/schema.ts b/schema/draft/schema.ts
@@ -1371,10 +1371,10 @@ export interface ElicitResult extends Result {
   /**
    * The user action in response to the elicitation.
    * - "accept": User submitted the form/confirmed the action
-   * - "reject": User explicitly rejected the action
+   * - "decline": User explicitly decline the action
    * - "cancel": User dismissed without making an explicit choice
    */
-  action: "accept" | "reject" | "cancel";
+  action: "accept" | "decline" | "cancel";
 
   /**
    * The submitted form data, only present when action is "accept".
