SEP Number: [To be assigned]
Title: Server Profiles for Model Control Protocol (MCP)
Author(s): Atul Tulshibagwale (@tulshi), SGNL and Erik Gustavson (@goosetav), SGNL
Status: Draft
Type: Standards Track
Created: 2025-07-18

Abstract

Proposal to add server profiles to the Model Context Protocol (MCP) specification. Server profiles define sets of behaviors and capabilities that servers can advertise to clients, enabling more predictable and interoperable interactions between MCP components. It envisions a registry of standardized profiles within MCP but also allows third-party custom profiles. MCP Servers can use standardized or custom profiles.

Motivation

MCP clients will be better served by choosing profiles of a server that ascertain certain properties and behaviors of the server, e.g. security. This will allow for more capable clients, or clients in more empowered environments to operate at a higher level of sophistication (e.g., in security) and prevent use of MCP Servers that do not support such profiles.

Currently, MCP servers advertise their capabilities through individual feature flags in the InitializationResponse object. Adding a profile to this enables:

• Standardized Behavior Sets: Pre-defined combinations of capabilities with consistent semantics
• Simplified Discovery: Clients can quickly identify compatible servers by profile type
• Predictable Interactions: Profiles guarantee specific behavior patterns
• Ecosystem Growth: Common profiles can accelerate adoption and tooling development

Specification

Profile Specification

Each Profile MUST have a specification document that describes the profile in detail. This is a document written using normative specification language that unambiguously specifies the characteristics of a profile.

Profile URL

A profile MUST provide a profile specification at the URL that is used to uniquely identify the profile. The URL must have a version suffix as the last component in its path. For example:

https://mycompany.com/mycustomprofile/1.0

Version Numbering

Profiles MUST be numbered using a <Major>.<Minor> versioning scheme. Major versions MAY be incompatible with each other, but a higher Minor numbered profile MUST be backward compatible with lower Minor numbered versions if the Major version is the same.

Profile Governance

Profiles MAY be standardized, in that they are specified and defined officially in the MCP repository, or they MAY be custom, which can be specified by third-parties.

Standardized Profile Registry

The MCP repository SHALL define a "Profiles" folder containing standardized profile specifications. Each profile description MUST have a Profile Specification and a Profile Definition.

Governance Process

The MCP governance process SHALL define:

• Standardized Profile Registration Process: How new profiles are proposed and approved
• Versioning Strategy: How profile versions are managed
• Deprecation Policy: How obsolete profiles are handled
• Compatibility Requirements: Backward compatibility guarantees

Server Behavior

ProfileSpec Object

A ProfileSpec object has the following fields:

• The location of the profile specification
• Whether it is the default profile for the server
• The minimum MCP version required to use that profile.

interface ProfileSpec {
  "profileURL": string; // The location where the profile is specified.
  "default": boolean; // whether this is the default profile for the server.
  "minMcpVersion": string; // this is the date in YYYY-MM-DD format that identifies the MCP version.
}

Profile Declaration

An MCP Server MAY specify the profiles it supports through a document available at the well known location as described in RFC 8615

/.well-known/mcp-profiles

If this resource does not exist on the MCP Server, or if the document returned is empty, then the Client MUST assume that the MCP Server does not support Profiles. In all other cases, the returned document MUST be an JSON array containing ProfileSpec objects. The structure of the response is described in the schema below:

[ ProfileSpec, ProfileSpec, ...]

Note that since this document is fetched before the Client sends the InititalizeRequest, this is independent of the behavior of what happens when the Client requests a certain profile, and the Server doesn’t support it.

A default profile is one that the server uses if the client does not request a specific profile. If the server has a default profile, it MUST be the first one in the array. Any ProfileSpec object in the response other than the first one SHALL NOT have the default value set to true.

Client Behavior

Profile Discovery

The Client MAY fetch the Server’s Well Known URI to understand which profiles the server supports (if any).

Initialize Request / Response Extensions

InitializeRequest Extension

The InitializeRequest object is extended to have an optional requestedProfiles field, whose value is an array of profile URLs.

interface InitializeRequest extends Request {
  method: "initialize";
  params: {
    protocolVersion: string;
    capabilities: ClientCapabilities;
    clientInfo: Implementation;
    requestedProfiles?: [ URL, URL, ...];  // New optional field
  };
}

The Client specifies zero or more profiles that it wants to use with the Server when it sends the InitializeRequest. If it has no opinion of which profile to use, it omits the field from the request.

InitializeResult Extension

The InitializeResult interface is extended to include an optional profile field:

interface InitializeResult extends Result {
  protocolVersion: string;
  capabilities: ServerCapabilities;
  serverInfo: Implementation;
  instructions?: string;
  profile?: URL;  // New optional field
}

The value of the profile field is the Profile URL of the selected Profile.

Profile Negotiation

1. The Client discovers available profiles
2. The client sends the InitializeRequest with optional requestedProfiles value with all profiles it could use in this specific instance.
3. The server MUST choose one of the requested profiles, and include it in the InitializeResult response in the profile field (see below)
4. If the server cannot support any of the requestedProfile values, it MUST refuse the connection.

Fallback Behavior

If the client does not specify a requestedProfiles value in the InitializeRequest, then:

• If the Server did not specify any profiles in its Well Known URL, it accepts the InitializeRequest, as a Server that does not support Profiles would be expected to behave.
• If the Server specified profiles in its Well Known URL, then:
  • The server MUST use the default profile, if one of the profiles had the default flag set to true.
  • The server MUST refuse the connection otherwise.

Rationale

The Model Context Protocol currently employs a capability-based system where servers advertise individual features through discrete flags in the InitializationResponse. While this approach is free-form and flexible, it creates the following challenges that server profiles are designed to address:

• Complexity in Capability Management: As MCP grows, servers may support dozens of individual capabilities. Clients must understand complex combinations of these capabilities to determine if a server meets their requirements. This leads to verbose negotiation processes and increases the likelihood of compatibility issues.
• Inconsistent Behavior Patterns: Two servers advertising the same individual capabilities may implement them with subtle differences in behavior, security models, or performance characteristics. Without profiles, clients cannot distinguish between these implementation variations, leading to unpredictable interactions.
• Security and Trust Requirements: Different deployment environments have varying security requirements. Enterprise clients may require servers that adhere to specific security profiles (such as enhanced authentication, audit logging, or data handling practices), while development environments may accept more permissive configurations. The current capability system cannot express these behavioral guarantees.
• Ecosystem Fragmentation: Without standardized behavioral contracts, the MCP ecosystem risks fragmentation where servers implement similar functionality in incompatible ways. Profiles provide a mechanism for the community to converge on standard patterns while still allowing innovation through custom profiles.
• Client Sophistication Levels: Different clients operate with varying levels of sophistication and environmental constraints. A lightweight client may only support basic profiles, while an enterprise client may require advanced security and monitoring profiles. The profile system enables clients to declare their requirements upfront and ensures servers can meet those needs.
• Discovery and Tooling: The current system requires clients to perform complex analysis of capability combinations to determine server suitability. Profiles enable simplified discovery mechanisms and allow tooling to be built around well-defined behavioral contracts rather than ad-hoc capability combinations.

Server profiles address these challenges by providing a standardized way to group capabilities with consistent semantics, enabling predictable behavior patterns, and supporting the diverse needs of the MCP ecosystem while maintaining backward compatibility with existing implementations.

Backward Compatibility

The introduction of profiles as an optional feature of InitializeRequest and InitializeResponse is fully backward compatible. The behavior of MCP Servers when receiving requests that are missing the fields is also documented in this proposal.

Security Implications

One of the main motivations for introducing this feature is to strengthen the security of MCP by making it possible for clients and servers to support and negotiate well-specified properties and behaviors.

Open Issues

This proposal does not address the following issues:

• Can a server simultaneously support more than one profile with the same client?
• Can a profile refer to another profile in its definition (i.e. subclassing)?
• Should profiles have parameters that the client can specify while requesting a profile, and the server can specify in the response? (E.g., { “keySize”: [1024,2048]})