modelcontextprotocol · dsp-ant · Jan 22, 2026 · Jan 22, 2026
diff --git a/seps/1024-mcp-client-security-requirements-for-local-server-.md b/seps/1024-mcp-client-security-requirements-for-local-server-.md
@@ -0,0 +1,104 @@
+# SEP-1024: MCP Client Security Requirements for Local Server Installation
+
+- **Status**: Final
+- **Type**: Standards Track
+- **Created**: 2025-07-22
+- **Author(s)**: Den Delimarsky
+- **Issue**: #1024
+
+## Abstract
+
+This SEP addresses critical security vulnerabilities in MCP client implementations that support one-click installation of local MCP servers. The current MCP specification lacks explicit security requirements for client-side installation flows, allowing malicious actors to execute arbitrary commands on user systems through crafted MCP server configurations distributed via links or social engineering.
+
+This proposal establishes a best practice for MCP clients, requiring explicit user consent before executing any local server installation commands and complete command transparency.
+
+## Motivation
+
+The existing MCP specification does not address client-side security concerns related to streamlined ("one-click") local server configuration. Current MCP clients that implement these configuration experiences create significant attack vectors:
+
+1. **Silent Command Execution**: MCP clients can automatically execute embedded commands without user review or consent when installing local servers via one-click flows.
+
+2. **Lack of Visibility**: Users have no insight into what commands are being executed on their systems, creating opportunities for data exfiltration, system compromise, and privilege escalation.
+
+3. **Social Engineering Vulnerabilities**: Users become comfortable executing commands labeled as "MCP servers" without proper scrutiny, making them susceptible to malicious configurations.
+
+4. **Arbitrary Code Execution**: Attackers can embed harmful commands in MCP server configurations and distribute them through legitimate channels (repositories, documentation, social media).
+
+Visual Studio Code [addressed this](https://den.dev/blog/vs-code-mcp-install-consent/) by implementing consent dialogs. Similarly, Cursor also supports a consent dialog for one-click local MCP server installation.
+
+Without explicit security requirements in the specification, MCP client implementers may unknowingly create vulnerable installation flows, putting end users at risk of system compromise.
+
+## Specification
+
+### Client Security Requirements
+
+MCP clients that support one-click local MCP server configuration **MUST** implement the following security controls:
+
+#### Pre-Configuration Consent
+
+Before executing any command to install or configure a local MCP server, the MCP client **MUST**:
+
+1. Display a clear consent dialog that shows:
+   - The exact command that will be executed, without truncation
+   - All arguments and parameters
+   - A clear warning that this operation may be potentially dangerous
+2. Require explicit user approval through an affirmative action (button click, checkbox, etc.)
+
+3. Provide an option for users to cancel the installation
+
+4. Not proceed with installation if consent is denied or not provided
+
+## Rationale
+
+### Design Decisions
+
+**Mandatory Consent Dialogs**: The requirement for explicit consent dialogs balances security with usability. While this adds friction to the MCP server configuration process, it prevents potential breaches from silent command execution.
+
+## Backward Compatibility
+
+This SEP introduces new **requirements** for MCP client implementations but does not change the core MCP protocol or wire format.
+
+**Impact Assessment:**
+
+- **Low Impact**: Existing MCP servers and the core protocol remain unchanged
+- **Client Implementation Required**: MCP clients must update their local server installation flows to comply with new security requirements
+- **User Experience Changes**: Users will see consent dialogs where none existed before
+
+**Migration Path:**
+
+1. MCP clients can implement these changes in new versions without breaking existing functionality
+2. Existing installed MCP servers continue to work normally
+3. Only new installation flows require the consent mechanisms
+
+No protocol-level backward compatibility issues exist, as this SEP addresses client behavior rather than the MCP wire protocol.
+
+## Reference Implementation
+
+N/A
+
+## Security Implications
+
+### Security Benefits
+
+This SEP directly addresses:
+
+- **Arbitrary Code Execution**: Prevents silent execution of malicious commands
+- **Social Engineering**: Forces users to consciously review commands before execution
+- **Supply Chain Attacks**: Creates visibility into MCP server installation commands
+- **Privilege Escalation**: Users can identify and reject commands requesting elevated privileges
+
+### Residual Risks
+
+Even with these controls, risks remain:
+
+- **User Override**: Users may approve malicious commands despite warnings
+- **Sophisticated Obfuscation**: Advanced attackers may craft commands that appear legitimate
+- **Implementation Gaps**: Clients may implement controls incorrectly
+
+### Risk Mitigation
+
+These residual risks are addressed through:
+
+- Clear warning language in consent dialogs
+- Recommendation for additional security layers (sandboxing, signatures)
+- Ongoing security research and community awareness
diff --git a/seps/1034--support-default-values-for-all-primitive-types-in.md b/seps/1034--support-default-values-for-all-primitive-types-in.md
@@ -0,0 +1,143 @@
+# SEP-1034: Support default values for all primitive types in elicitation schemas
+
+- **Status**: Final
+- **Type**: Standards Track
+- **Created**: 2025-07-22
+- **Author(s)**: Tapan Chugh (chugh.tapan@gmail.com)
+- **Issue**: #1034
+
+## Abstract
+
+This SEP recommends adding support for default values to all primitive types in the MCP elicitation schema (StringSchema, NumberSchema, and EnumSchema), extending the existing support that only covers BooleanSchema.
+
+## Motivation
+
+Elicitations in MCP offer a way to mitigate complex API designs: tools can request information on-demand rather than resorting to convoluted parameter handling. The challenge however is that users must manually enter obvious information that could be pre-populated for more natural interactions. Currently, only `BooleanSchema` supports default values in elicitation requests. This limitation prevents servers from providing sensible defaults for text inputs, numbers, and enum selections leading to more user overhead.
+
+### Real-World Example
+
+Consider implementing an email reply function. Without elicitation, the tool becomes unwieldy:
+
+```python
+def reply_to_email_thread(
+    thread_id: str,
+    content: str,
+    recipient_list: List[str] = [],
+    cc_list: List[str] = []
+) -> None:
+    # Ambiguity: Does empty list mean "no recipients" or "use defaults"?
+    # Complex logic needed to handle different combinations
+```
+
+With elicitation, the tool signature itself can be much simpler
+
+```python
+def reply_to_email_thread(
+    thread_id: str,
+    content: Optional[str] = ""
+) -> None:
+    # Code can lookup the participants from the original thread
+    # and prepare an elicitation request with the defaults setup
+```
+
+```typescript
+const response = await client.request("elicitation/create", {
+  message: "Configure email reply",
+  requestedSchema: {
+    type: "object",
+    properties: {
+      recipients: {
+        type: "string",
+        title: "Recipients",
+        default: "alice@company.com, bob@company.com"  // Pre-filled
+      },
+      cc: {
+        type: "string",
+        title: "CC",
+        default: "john@company.com"  // Pre-filled
+      },
+      content: {
+        type: "string",
+        title: "Message"
+        default: "" // If provided in the tool above
+      }
+    }
+  }
+});
+```
+
+### Implementation
+
+A working implementation demonstrating clients require minimal changes to display defaults (~10 lines of code):
+
+- Implementation PR: https://github.com/chughtapan/fast-agent/pull/2
+- A demo with the above email reply workflow: https://asciinema.org/a/X7aQZjT2B5jVwn9dJ9sqQVkOM
+
+## Specification
+
+### Schema Changes
+
+Extend the elicitation primitive schemas to include optional default values:
+
+```typescript
+export interface StringSchema {
+  type: "string";
+  title?: string;
+  description?: string;
+  minLength?: number;
+  maxLength?: number;
+  format?: "email" | "uri" | "date" | "date-time";
+  default?: string; // NEW
+}
+
+export interface NumberSchema {
+  type: "number" | "integer";
+  title?: string;
+  description?: string;
+  minimum?: number;
+  maximum?: number;
+  default?: number; // NEW
+}
+
+export interface EnumSchema {
+  type: "string";
+  title?: string;
+  description?: string;
+  enum: string[];
+  enumNames?: string[];
+  default?: string; // NEW - must be one of enum values
+}
+
+// BooleanSchema already has default?: boolean
+```
+
+### Behavior
+
+1. The `default` field is optional, maintaining full backward compatibility
+2. Default values must match the schema type
+3. For EnumSchema, the default must be one of the valid enum values
+4. Clients that support defaults SHOULD pre-populate form fields. Clients that don't support defaults MAY ignore the field entirely.
+
+## Rationale
+
+1. The high-level rationale is to follow the precedent set by BooleanSchema rather than creating new mechanisms.
+2. Making defaults optional ensures backward compatibility.
+3. This maintains the high-level intuition of keeping the client implementation simple.
+
+### Alternatives Considered
+
+1. **Server-side Templates**: Servers could maintain templates separately, but this adds complexity
+2. **New Request Type**: A separate request type for forms with defaults would fragment the API
+3. **Required Defaults**: Making defaults required would break existing implementations
+
+## Backwards Compatibility
+
+This change is fully backward compatible with no breaking changes. Clients that don't understand defaults will ignore them, and existing elicitation requests continue to work unchanged. Clients can adopt default support at their own pace
+
+## Security Implications
+
+No new security concerns:
+
+1. **No Sensitive Data**: The existing guidance against requesting sensitive information still applies
+2. **Client Control**: Clients retain full control over what data is sent to servers
+3. **User Visibility**: Default values are visible to users who can modify them before submission