​

Abstract

​

Motivation

1. Sensitive data collection: API keys, passwords, and other credentials must never transit through intermediary systems.
2. External authorization: MCP servers often need to access third-party APIs on behalf of users. The MCP authorization specification only covers client-to-server authorization, not server-to-third-party authorization. The Security Best Practices document explicitly forbids token passthrough, requiring a secure mechanism for external (3rd-party) OAuth flows. This was a particularly important motivating factor emerging from discussions in #234 and #284.
3. Payment and Subscription Flows: Financial transactions require PCI compliance and secure payment processing that cannot be achieved through in-band data collection.

​

Specification

​

Overview

• Form mode (in-band): Servers can request structured data from users with optional JSON schemas to validate responses (no change here, other than adding a name to the existing capability)
• URL mode (out-of-band): Servers can direct users to external URLs for sensitive interactions that must not pass through the MCP client

​

Capabilities

{
  "capabilities": {
    "elicitation": {
      "form": {},
      "url": {}
    }
  }
}

{
  "capabilities": {
    "elicitation": {},
  },
}

​

Form Elicitation Requests

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "elicitation/create",
  "params": {
    "mode": "form", // New field
    "message": "Please provide your GitHub username",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        }
      },
      "required": ["name"]
    }
  }
}

​

URL Elicitation Requests

​

Example: OAuth Authorization Flow

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
    "url": "https://github.com/login/oauth/authorize?client_id=abc123&state=xyz789&scope=repo",
    "message": "Please authorize access to your GitHub repositories to continue."
  }
}

​

Response Actions

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "action": "accept" // or "decline" or "cancel"
  }
}

​

Completion Notifications

• The notification MUST only be sent to the client that initiated the elicitation request.
• The notification MUST include the elicitationId established in the original elicitation/create request.
• Clients MUST ignore notifications referencing unknown or already-completed IDs.
• If a completion notification never arrives, clients SHOULD provide a manual way for the user to continue the interaction.

{
  "jsonrpc": "2.0",
  "method": "notifications/elicitation/complete",
  "params": {
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

​

URL Elicitation Required Error

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32042,
    "message": "This request requires more information.",
    "data": {
      "elicitations": [
        {
          "mode": "url",
          "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
          "url": "https://oauth.example.com/authorize?client_id=abc123&response_type=code&...",
          "message": "Authorization is required to access your Example Co files."
        }
      ]
    }
  }
}

​

Rationale

​

Design Decisions

1. Both mechanisms serve the same fundamental purpose: gathering information from users
2. Having two similar-but-separate mechanisms for the same purpose is confusing and error-prone
3. The mode parameter cleanly separates the two interaction patterns

• If the MCP client obtains user tokens from a third-party authorization server, the MCP server becomes a token passthrough server, which is explicitly forbidden.
• Similarly, for payment-type flows, the MCP client would need to perform PCI-compliant payment processing, which is not a desired requirement for MCP clients.

​

Alternative Approaches Considered

1. Token Passthrough: Simply passing the MCP client’s token to external services was rejected due to security concerns documented in the Security Best Practices. Having the MCP client obtain additional tokens and passing those to the MCP server was rejected for the same reason.
2. OAuth-specific Capability: Creating a capability specific to external (3rd-party) authorization with OAuth was considered, but rejected in favor of the more general URL mode elicitation approach that supports multiple use cases.

​

Community Feedback

• Secure credential collection without client exposure
• External authorization patterns separate from MCP authorization
• Payment and subscription flow support
• Clear security boundaries and trust models

​

Backward Compatibility

1. Capability Declaration: Clients must now specify which elicitation modes they support:
   Copy

   {
     "capabilities": {
       "elicitation": {
         "form": {},
         "url": {}
       }
     }
   }
   
   Previously, clients only declared "elicitation": {} without mode specification.
2. Mode Parameter: All elicitation/create requests must now include a mode parameter ("form" or "url").

​

Migration Path

• Servers SHOULD check client capabilities before sending mode-specific requests
• Clients MAY initially support only form mode to maintain compatibility
• Existing form elicitation implementations continue to work with the addition of the mode parameter

​

Reference Implementation

​

Security Implications

​

URL Security Requirements

1. SSRF Prevention: Clients must validate URLs to prevent Server-Side Request Forgery attacks
2. Protocol Restrictions: Only HTTPS URLs are allowed for URL elicitation
3. Domain Validation: Clients must clearly display target domains to users

​

Trust Boundaries

• The MCP client never sees sensitive data obtained by the MCP server via URL elicitation
• The MCP server must independently verify user identity
• Third-party services interact directly with users through secure browser contexts

​

Identity Verification

​

Implementation Requirements

1. Clients must:
   • Use secure browser contexts that prevent inspection of user inputs
   • Validate URLs for SSRF protection
   • Obtain explicit user consent before opening URLs
   • Clearly display target domains
2. Servers must:
   • Bind elicitation state to authenticated user sessions
   • Verify user identity at the beginning and end of a URL elicitation flow
   • Implement appropriate rate limiting
3. Both parties should:
   • Log security events for audit purposes
   • Implement timeout mechanisms for elicitation requests
   • Provide clear error messages for security failures

​

Relationship to Existing Security Measures

• Works within the existing MCP authorization framework (MCP authorization is not affected by this proposal)
• Follows Security Best Practices regarding token handling
• Maintains separation of concerns between client-server and server-third-party authorization