Add a restricted json schema

Author: Abhimanyu Siwach

docs/specification/draft/client/elicitation.mdx

@@ -20,14 +20,15 @@ their needs—the protocol itself does not mandate any specific user interac
 model.
 
 <Warning>
-For trust & safety and security, there **SHOULD** always
-be a human in the loop with the ability to deny elicitation requests.
+For trust & safety and security:
+
+- Servers **MUST NOT** use elicitation to request sensitive information.
 
 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 cancel options
+- Respect user privacy and provide clear decline and cancel options
 </Warning>
 
 ## Capabilities
@@ -82,6 +83,7 @@ To request information from a user, servers send an `elicitation/create` request
   "jsonrpc": "2.0",
   "id": 1,
   "result": {
+    "action": "accept",
     "content": {
       "name": "octocat"
     }
@@ -131,6 +133,7 @@ To request information from a user, servers send an `elicitation/create` request
   "jsonrpc": "2.0",
   "id": 2,
   "result": {
+    "action": "accept",
     "content": {
       "name": "Monalisa Octocat",
       "email": "[email protected]",
@@ -140,6 +143,30 @@ To request information from a user, servers send an `elicitation/create` request
 }
 ```
 
+**Decline Response Example:**
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 2,
+  "result": {
+    "action": "decline"
+  }
+}
+```
+
+**Cancel Response Example:**
+
+```json
+{
+  "jsonrpc": "2.0",
+  "id": 2,
+  "result": {
+    "action": "cancel"
+  }
+}
+```
+
 ## Message Flow
 
 ```mermaid
@@ -163,14 +190,15 @@ sequenceDiagram
 
 ## Request Schema
 
-The `requestedSchema` field allows servers to define the structure of the expected response using JSON Schema. This follows the same pattern as the `inputSchema` field in the Tool interface:
+The `requestedSchema` field allows servers to define the structure of the expected response using a restricted subset of JSON Schema. To simplify implementation for clients, elicitation schemas are limited to flat objects with primitive properties only:
 
 ```json
 "requestedSchema": {
   "type": "object",
   "properties": {
     "propertyName": {
       "type": "string",
+      "title": "Display Name",
       "description": "Description of the property"
     },
     "anotherProperty": {
@@ -183,70 +211,106 @@ The `requestedSchema` field allows servers to define the structure of the expect
 }
 ```
 
-The schema can include:
-- Property definitions with types
-- Required field specifications
-- Validation constraints (min/max values, patterns, formats)
-- Descriptions for UI presentation
+### Supported Schema Types
+
+The schema is restricted to these primitive types:
+
+1. **String Schema**
+   ```json
+   {
+     "type": "string",
+     "title": "Display Name",
+     "description": "Description text",
+     "minLength": 3,
+     "maxLength": 50,
+     "pattern": "^[A-Za-z]+$",
+     "format": "email"
+   }
+   ```
+   Supported formats: `email`, `uri`, `date`, `date-time`
+
+2. **Number Schema**
+   ```json
+   {
+     "type": "number", // or "integer"
+     "title": "Display Name",
+     "description": "Description text",
+     "minimum": 0,
+     "maximum": 100
+   }
+   ```
+
+3. **Boolean Schema**
+   ```json
+   {
+     "type": "boolean",
+     "title": "Display Name",
+     "description": "Description text",
+     "default": false
+   }
+   ```
+
+4. **Enum Schema**
+   ```json
+   {
+     "type": "string",
+     "title": "Display Name",
+     "description": "Description text",
+     "enum": ["option1", "option2", "option3"],
+     "enumNames": ["Option 1", "Option 2", "Option 3"]
+   }
+   ```
 
 Clients can use this schema to:
 1. Generate appropriate input forms
 2. Validate user input before sending
 3. Provide better guidance to users
 
-## Response Content
+Note that complex nested structures, arrays of objects, and other advanced JSON Schema features are intentionally not supported to simplify client implementation.
 
-Responses to elicitation requests contain a content object with key-value pairs:
+## Response Actions
 
-```json
-"content": {
-  "propertyName": "value",
-  "anotherProperty": 42
-}
-```
-
-The structure of this object should match the schema provided in the request, if one was specified. If no schema was provided, the client can structure the response as appropriate for the use case.
-
-## Error Handling
-
-Clients **SHOULD** return standard JSON-RPC errors for common failure cases:
-
-Example when the user cancels:
+Elicitation responses use a three-action model to clearly distinguish between different user actions:
 
 ```json
 {
   "jsonrpc": "2.0",
   "id": 1,
-  "error": {
-    "code": -1,
-    "message": "User rejected the elicitation request"
+  "result": {
+    "action": "accept", // or "decline" or "cancel"
+    "content": {
+      "propertyName": "value",
+      "anotherProperty": 42
+    }
   }
 }
 ```
 
-Example when validation fails:
+The three response actions are:
 
-```json
-{
-  "jsonrpc": "2.0",
-  "id": 1,
-  "error": {
-    "code": -32602,
-    "message": "Invalid parameters",
-    "data": {
-      "validationErrors": {
-        "email": "Invalid email format"
-      }
-    }
-  }
-}
-```
+1. **Accept** (`action: "accept"`): User explicitly approved and submitted the form with data
+   - The `content` field contains the submitted data matching the requested schema
+   - Example: User clicked "Submit", "OK", "Confirm", etc.
+
+2. **Decline** (`action: "decline"`): User explicitly rejected the request
+   - The `content` field is typically omitted
+   - Example: User clicked "Decline", "Reject", "No", etc.
+
+3. **Cancel** (`action: "cancel"`): User dismissed without making an explicit choice
+   - The `content` field is typically omitted
+   - Example: User closed the dialog, clicked outside, pressed Escape, etc.
+
+Servers should handle each state appropriately:
+- **Accept**: Process the submitted data
+- **Decline**: Handle explicit rejection (e.g., offer alternatives)
+- **Cancel**: Handle dismissal (e.g., prompt again later)
 
 ## Security Considerations
 
-1. Clients **SHOULD** implement user approval controls
-2. Both parties **SHOULD** validate elicitation content against the provided schema
-3. Clients **SHOULD** provide clear indication of which server is requesting information
-4. Clients **SHOULD** allow users to reject elicitation requests at any time
-5. Clients **SHOULD** implement rate limiting
-6. Both parties **MUST** handle sensitive data appropriately
+1. Servers **MUST NOT** request sensitive information through elicitation
+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
+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