Adds protocol layering section to architecture documentation to clarify design decisions and feature placement within MCP.

Motivation and Context

The current MCP architecture documentation focuses on components and design principles but doesn't necessarily explain where different features belong within the protocol's organizational structure.

Adding a layering diagram could provide clearer guidance for understanding architectural decisions, such as:

• Why can't Elicitation be used for API keys/credentials?
• Should authentication happen at the transport or application level?
• Where do new features belong when extending MCP?

While this only separates functionality into 2 broad categories, it seems like most MCP features do fall into either "business logic" vs "transport/auth," so this separation could still provide meaningful architectural guidance.

How Has This Been Tested?

Checked for alignment between this addition and the existing spec + security best practices.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Inspired by question from @calclavia about whether Elicitation should allow for passing secrets/API keys.