Skip to content

Commit 03b286f

Browse files
chughtapanchughtapan
authored
Merge branch 'main' into groups
2 parents 36b2b97 + 8d07c35 commit 03b286f

10 files changed

Lines changed: 2952 additions & 0 deletions

‎seps/1024-mcp-client-security-requirements-for-local-server-.md‎

Lines changed: 104 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
# SEP-1024: MCP Client Security Requirements for Local Server Installation
2+
3+
- **Status**: Final
4+
- **Type**: Standards Track
5+
- **Created**: 2025-07-22
6+
- **Author(s)**: Den Delimarsky
7+
- **Issue**: #1024
8+
9+
## Abstract
10+
11+
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.
12+
13+
This proposal establishes a best practice for MCP clients, requiring explicit user consent before executing any local server installation commands and complete command transparency.
14+
15+
## Motivation
16+
17+
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:
18+
19+
1. **Silent Command Execution**: MCP clients can automatically execute embedded commands without user review or consent when installing local servers via one-click flows.
20+
21+
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.
22+
23+
3. **Social Engineering Vulnerabilities**: Users become comfortable executing commands labeled as "MCP servers" without proper scrutiny, making them susceptible to malicious configurations.
24+
25+
4. **Arbitrary Code Execution**: Attackers can embed harmful commands in MCP server configurations and distribute them through legitimate channels (repositories, documentation, social media).
26+
27+
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.
28+
29+
Without explicit security requirements in the specification, MCP client implementers may unknowingly create vulnerable installation flows, putting end users at risk of system compromise.
30+
31+
## Specification
32+
33+
### Client Security Requirements
34+
35+
MCP clients that support one-click local MCP server configuration **MUST** implement the following security controls:
36+
37+
#### Pre-Configuration Consent
38+
39+
Before executing any command to install or configure a local MCP server, the MCP client **MUST**:
40+
41+
1. Display a clear consent dialog that shows:
42+
- The exact command that will be executed, without truncation
43+
- All arguments and parameters
44+
- A clear warning that this operation may be potentially dangerous
45+
2. Require explicit user approval through an affirmative action (button click, checkbox, etc.)
46+
47+
3. Provide an option for users to cancel the installation
48+
49+
4. Not proceed with installation if consent is denied or not provided
50+
51+
## Rationale
52+
53+
### Design Decisions
54+
55+
**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.
56+
57+
## Backward Compatibility
58+
59+
This SEP introduces new **requirements** for MCP client implementations but does not change the core MCP protocol or wire format.
60+
61+
**Impact Assessment:**
62+
63+
- **Low Impact**: Existing MCP servers and the core protocol remain unchanged
64+
- **Client Implementation Required**: MCP clients must update their local server installation flows to comply with new security requirements
65+
- **User Experience Changes**: Users will see consent dialogs where none existed before
66+
67+
**Migration Path:**
68+
69+
1. MCP clients can implement these changes in new versions without breaking existing functionality
70+
2. Existing installed MCP servers continue to work normally
71+
3. Only new installation flows require the consent mechanisms
72+
73+
No protocol-level backward compatibility issues exist, as this SEP addresses client behavior rather than the MCP wire protocol.
74+
75+
## Reference Implementation
76+
77+
N/A
78+
79+
## Security Implications
80+
81+
### Security Benefits
82+
83+
This SEP directly addresses:
84+
85+
- **Arbitrary Code Execution**: Prevents silent execution of malicious commands
86+
- **Social Engineering**: Forces users to consciously review commands before execution
87+
- **Supply Chain Attacks**: Creates visibility into MCP server installation commands
88+
- **Privilege Escalation**: Users can identify and reject commands requesting elevated privileges
89+
90+
### Residual Risks
91+
92+
Even with these controls, risks remain:
93+
94+
- **User Override**: Users may approve malicious commands despite warnings
95+
- **Sophisticated Obfuscation**: Advanced attackers may craft commands that appear legitimate
96+
- **Implementation Gaps**: Clients may implement controls incorrectly
97+
98+
### Risk Mitigation
99+
100+
These residual risks are addressed through:
101+
102+
- Clear warning language in consent dialogs
103+
- Recommendation for additional security layers (sandboxing, signatures)
104+
- Ongoing security research and community awareness

‎seps/1034--support-default-values-for-all-primitive-types-in.md‎

Lines changed: 143 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,143 @@
1+
# SEP-1034: Support default values for all primitive types in elicitation schemas
2+
3+
- **Status**: Final
4+
- **Type**: Standards Track
5+
- **Created**: 2025-07-22
6+
- **Author(s)**: Tapan Chugh (chugh.tapan@gmail.com)
7+
- **Issue**: #1034
8+
9+
## Abstract
10+
11+
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.
12+
13+
## Motivation
14+
15+
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.
16+
17+
### Real-World Example
18+
19+
Consider implementing an email reply function. Without elicitation, the tool becomes unwieldy:
20+
21+
```python
22+
def reply_to_email_thread(
23+
thread_id: str,
24+
content: str,
25+
recipient_list: List[str] = [],
26+
cc_list: List[str] = []
27+
) -> None:
28+
# Ambiguity: Does empty list mean "no recipients" or "use defaults"?
29+
# Complex logic needed to handle different combinations
30+
```
31+
32+
With elicitation, the tool signature itself can be much simpler
33+
34+
```python
35+
def reply_to_email_thread(
36+
thread_id: str,
37+
content: Optional[str] = ""
38+
) -> None:
39+
# Code can lookup the participants from the original thread
40+
# and prepare an elicitation request with the defaults setup
41+
```
42+
43+
```typescript
44+
const response = await client.request("elicitation/create", {
45+
message: "Configure email reply",
46+
requestedSchema: {
47+
type: "object",
48+
properties: {
49+
recipients: {
50+
type: "string",
51+
title: "Recipients",
52+
default: "alice@company.com, bob@company.com" // Pre-filled
53+
},
54+
cc: {
55+
type: "string",
56+
title: "CC",
57+
default: "john@company.com" // Pre-filled
58+
},
59+
content: {
60+
type: "string",
61+
title: "Message"
62+
default: "" // If provided in the tool above
63+
}
64+
}
65+
}
66+
});
67+
```
68+
69+
### Implementation
70+
71+
A working implementation demonstrating clients require minimal changes to display defaults (~10 lines of code):
72+
73+
- Implementation PR: https://github.com/chughtapan/fast-agent/pull/2
74+
- A demo with the above email reply workflow: https://asciinema.org/a/X7aQZjT2B5jVwn9dJ9sqQVkOM
75+
76+
## Specification
77+
78+
### Schema Changes
79+
80+
Extend the elicitation primitive schemas to include optional default values:
81+
82+
```typescript
83+
export interface StringSchema {
84+
type: "string";
85+
title?: string;
86+
description?: string;
87+
minLength?: number;
88+
maxLength?: number;
89+
format?: "email" | "uri" | "date" | "date-time";
90+
default?: string; // NEW
91+
}
92+
93+
export interface NumberSchema {
94+
type: "number" | "integer";
95+
title?: string;
96+
description?: string;
97+
minimum?: number;
98+
maximum?: number;
99+
default?: number; // NEW
100+
}
101+
102+
export interface EnumSchema {
103+
type: "string";
104+
title?: string;
105+
description?: string;
106+
enum: string[];
107+
enumNames?: string[];
108+
default?: string; // NEW - must be one of enum values
109+
}
110+
111+
// BooleanSchema already has default?: boolean
112+
```
113+
114+
### Behavior
115+
116+
1. The `default` field is optional, maintaining full backward compatibility
117+
2. Default values must match the schema type
118+
3. For EnumSchema, the default must be one of the valid enum values
119+
4. Clients that support defaults SHOULD pre-populate form fields. Clients that don't support defaults MAY ignore the field entirely.
120+
121+
## Rationale
122+
123+
1. The high-level rationale is to follow the precedent set by BooleanSchema rather than creating new mechanisms.
124+
2. Making defaults optional ensures backward compatibility.
125+
3. This maintains the high-level intuition of keeping the client implementation simple.
126+
127+
### Alternatives Considered
128+
129+
1. **Server-side Templates**: Servers could maintain templates separately, but this adds complexity
130+
2. **New Request Type**: A separate request type for forms with defaults would fragment the API
131+
3. **Required Defaults**: Making defaults required would break existing implementations
132+
133+
## Backwards Compatibility
134+
135+
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
136+
137+
## Security Implications
138+
139+
No new security concerns:
140+
141+
1. **No Sensitive Data**: The existing guidance against requesting sensitive information still applies
142+
2. **Client Control**: Clients retain full control over what data is sent to servers
143+
3. **User Visibility**: Default values are visible to users who can modify them before submission

0 commit comments

Comments
 (0)