feat: Add Enterprise Managed Authorization (SEP-990) support

.config/dotnet-tools.json

@@ -3,11 +3,11 @@
   "isRoot": true,
   "tools": {
     "docfx": {
-      "version": "2.78.4",
+      "version": "2.78.5",
       "commands": [
         "docfx"
       ],
       "rollForward": false
     }
   }
-}
+}

.devcontainer/devcontainer.json

@@ -19,5 +19,9 @@
 			}
 		}
 	},
-	"postCreateCommand": "dotnet dev-certs https --trust && dotnet --list-sdks && echo 'Available .NET SDKs installed successfully!'"
+	"postCreateCommand": {
+		"dev certs": "dotnet dev-certs https --trust",
+		"mono": "sudo apt-get update && sudo apt-get install -y mono-devel",
+		"list sdks": "dotnet --list-sdks && echo 'Available .NET SDKs installed successfully!'"
+	}
 }

.github/skills/breaking-changes/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: breaking-changes
+description: Audit pull requests for breaking changes in the C# MCP SDK. Examines PR descriptions, review comments, and diffs to identify API and behavioral breaking changes, then reconciles labels with user confirmation. Use when asked to audit breaking changes, check for breaking changes, or review a set of PRs for breaking impact.
+compatibility: Requires gh CLI with repo access and GitHub API access for PR details, review history, and labels.
+---
+
+# Breaking Change Audit
+
+Audit pull requests in the `modelcontextprotocol/csharp-sdk` repository for breaking changes. This skill examines a range of commits, identifies API and behavioral breaking changes, assesses their impact, reconciles `breaking-change` labels, and returns structured results.
+
+## Input
+
+The user provides a commit range in any of these forms:
+- `tag..HEAD` (e.g. `v0.8.0-preview.1..HEAD`)
+- `tag..tag` (e.g. `v0.8.0-preview.1..v0.9.0-preview.1`)
+- `sha..sha`
+- `tag..sha` or `sha..HEAD`
+
+If no range is provided, ask the user to specify one.
+
+Use the GitHub API to get the full list of PRs merged within the specified range.
+
+## Process
+
+### Step 1: Examine Every PR
+
+For each PR in the range, study:
+- PR description and linked issues
+- Full review and comment history
+- Complete code diff
+
+Look for both categories of breaking changes:
+- **API (compile-time)** — changes to public type signatures, parameter types, return types, removed members, sealed types, new obsoletion attributes, etc.
+- **Behavioral (runtime)** — new/changed exceptions, altered return values, changed defaults, modified event ordering, serialization changes, etc.
+
+See [references/classification.md](references/classification.md) for the full classification guide, including SDK-specific versioning policies (experimental APIs, obsoletion lifecycle, and spec-driven changes) that influence how breaks are assessed.
+
+### Step 2: Assess Impact
+
+For each identified breaking change, assess:
+- **Breadth** — how many consumers are likely affected (widely-used type vs. obscure API)
+- **Severity** — compile-time break (immediate build failure) vs. behavioral (subtle runtime difference)
+- **Migration** — straightforward fix vs. significant code changes required
+
+This assessment informs how breaking changes are ordered when presented (most impactful first).
+
+### Step 3: Reconcile Labels
+
+Compare findings against existing `breaking-change` labels on PRs.
+
+Present mismatches to the user interactively:
+
+- **Unlabeled but appears breaking** → explain why the PR appears breaking, ask user to confirm. If confirmed: apply the `breaking-change` label and ask the user whether to comment on the PR explaining the addition.
+- **Labeled but does not appear breaking** → explain why, ask user to confirm removal. If confirmed: remove the label and ask the user whether to comment on the PR explaining the removal.
+
+### Step 4: Present Results
+
+Present the final list of confirmed breaking changes, sorted from most impactful to least, with:
+- PR number and title
+- Classification (API or behavioral)
+- Impact assessment summary
+- 1-2 bullet description of what breaks and migration guidance
+
+## Output
+
+The audit produces a structured list of breaking changes that can be consumed by other skills (e.g. the **prepare-release** and **publish-release** skills) or presented directly to the user.
+
+Each entry contains:
+- PR number and description
+- Impact ranking (most → least impactful)
+- Detail bullets describing the break and migration path

.github/skills/breaking-changes/references/classification.md

@@ -0,0 +1,148 @@
+# Breaking Change Classification Guide
+
+This guide defines how to identify and classify breaking changes in the C# MCP SDK. It is derived from the [dotnet/runtime breaking change guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-changes.md).
+
+## Two Categories of Breaking Changes
+
+### API Breaking Changes (Compile-Time)
+Changes that alter the public API surface in ways that break existing code at compile time:
+
+- **Renaming or removing** a public type, member, or parameter
+- **Changing the return type** of a method or property
+- **Changing parameter types, order, or count** on a public method
+- **Sealing** a type that was previously unsealed (when it has accessible constructors)
+- **Making a virtual member abstract**
+- **Adding `abstract` to a member** when the type has accessible constructors and is not sealed
+- **Removing an interface** from a type's implementation
+- **Changing the value** of a public constant or enum member
+- **Changing the underlying type** of an enum
+- **Adding `readonly` to a field**
+- **Removing `params` from a parameter**
+- **Adding/removing `in`, `out`, or `ref`** parameter modifiers
+- **Renaming a parameter** (breaks named arguments and late-binding)
+- **Adding the `[Obsolete]` attribute** or changing its diagnostic ID
+- **Adding the `[Experimental]` attribute** or changing its diagnostic ID
+- **Removing accessibility** (making a public/protected member less visible)
+
+### Behavioral Breaking Changes (Runtime)
+Changes that don't break compilation but alter observable behavior:
+
+- **Throwing a new/different exception type** in an existing scenario (unless it's a more derived type)
+- **No longer throwing an exception** that was previously thrown
+- **Changing return values** for existing inputs
+- **Decreasing the range of accepted values** for a parameter
+- **Changing default values** for properties, fields, or parameters
+- **Changing the order of events** being fired
+- **Removing the raising of an event**
+- **Changing timing/order** of operations
+- **Changing parsing behavior** and throwing new errors
+- **Changing serialization format** or adding new fields to serialized types
+
+## Classification Buckets
+
+### Bucket 1: Clear Public Contract Violation
+Obvious breaking changes to the public API shape. **Always flag these.**
+
+### Bucket 2: Reasonable Grey Area
+Behavioral changes that customers would have reasonably depended on. **Flag and discuss with user.**
+
+### Bucket 3: Unlikely Grey Area
+Behavioral changes that customers could have depended on but probably wouldn't (e.g., corner case corrections). **Flag with lower confidence.**
+
+### Bug Fixes (Exclude)
+Changes that correct incorrect behavior, fix spec compliance, or address security issues are **not breaking changes** even if they alter observable behavior. Examples:
+- Fixing encoding to match a specification requirement
+- Correcting a logger category or metric name that was wrong
+- Fixing exception message leaks that were a security concern
+- Moving data to the correct location per protocol spec evolution
+- Setting a flag that should have been set automatically (e.g., `IsError` for error content)
+- Returning a more specific/informative exception for better diagnostics
+
+If a change is primarily a bug fix or spec compliance correction, exclude it from the breaking changes list even though the observable behavior changes.
+
+### Bucket 4: Clearly Non-Public
+Changes to internal surface or behavior (e.g., internal APIs, private reflection). **Generally not flagged** unless they could affect ecosystem tools.
+
+## SDK Versioning Policy
+
+The classification rules above are derived from the dotnet/runtime breaking change guidelines, but the MCP SDK has its own versioning policy (see `docs/versioning.md`) that provides additional context for classification decisions.
+
+### Experimental APIs
+
+APIs annotated with `[Experimental]` (using `MCP`-prefixed diagnostic codes) can change at any time, including within PATCH or MINOR updates. Changes to experimental APIs should still be **noted** in the audit, but classified as **Bucket 3 (Unlikely Grey Area)** or lower unless the API has been widely adopted despite its experimental status.
+
+#### APIs exclusively reachable through `[Experimental]` gates
+
+A change to a non-experimental public API is **not considered breaking** if it only affects consumers who have already opted into an `[Experimental]` code path. The key question is: *can a consumer reach the breaking impact without suppressing an experimental diagnostic?*
+
+For example, adding an abstract member to a public abstract class is normally a Bucket 1 break (anyone deriving from the class must implement the new member). However, if the class's only accessible constructor is marked `[Experimental]`, then deriving from it already requires suppressing the experimental diagnostic — meaning the consumer has explicitly accepted that the API is subject to change.
+
+**How to identify this pattern:**
+1. A change would normally be classified as a breaking change (e.g., CP0005 — adding abstract member to abstract type)
+2. Trace the code path a consumer must follow to be affected by the break
+3. If **every** such path requires the consumer to use an `[Experimental]`-annotated API (constructor, method, type, etc.), the break is dismissed
+
+### Obsoletion Lifecycle
+
+The SDK follows a three-step obsoletion process:
+
+1. **MINOR update**: API marked `[Obsolete]` producing _build warnings_ with migration guidance
+2. **MAJOR update**: API marked `[Obsolete]` producing _build errors_ (API throws at runtime)
+3. **MAJOR update**: API removed entirely (expected to be rare)
+
+When auditing, classify each step appropriately:
+- Step 1 (adding `[Obsolete]` warning) → API breaking change (new build warning)
+- Step 2 (escalating to error) → API breaking change (previously working code now fails)
+- Step 3 (removal) → API breaking change; migration guidance should note prior deprecation
+
+In exceptional circumstances, the obsoletion lifecycle may be compressed (e.g., marking obsolete and removing in the same MINOR release). This should still be flagged as a breaking change but the migration guidance should explain the rationale.
+
+### Spec-Driven Changes
+
+Breaking changes necessitated by MCP specification evolution should be flagged and documented normally, but the migration guidance should reference the spec change. If a spec change forces an incompatible API change, preference is given to supporting the most recent spec version.
+
+## Compatibility Switches
+
+When a breaking change includes an `AppContext` switch or other opt-in/opt-out mechanism, always note it in the migration guidance. Search for `AppContext.TryGetSwitch`, `DOTNET_` environment variables, and similar compat patterns in the diff. Include the switch name and the value that alters the behavior:
+
+```
+* Compat switch: `ModelContextProtocol.AspNetCore.AllowNewSessionForNonInitializeRequests` = `true` restores previous behavior
+```
+
+## Dismissing Potential Breaking Changes
+
+When a change appears to be breaking but is dismissed (e.g., as a bug fix, clearly non-public, or exclusively gated by `[Experimental]` APIs), the audit must present the full rationale to the user for verification.
+
+### Gathering Supporting Evidence
+
+Before dismissing a potential break, review the PR description and all PR comments (both review comments and general comments) for discussion about the breaking change. Authors and reviewers often explain *why* a change is acceptable — for example, noting that the affected type is gated by an experimental constructor, that the previous behavior was incorrect per the spec, that no external consumers exist yet, or that compatibility suppressions were added intentionally. This discussion serves as supporting evidence for the dismissal and should be cited in the audit findings.
+
+### Presenting Dismissals
+
+Every dismissed potential break must be reported to the user with enough detail for them to verify the conclusion. The audit must:
+
+1. **Identify what would normally be breaking and why** (e.g., "CP0005 — adding abstract member `Completion` to abstract class `McpClient`")
+2. **Explain the specific reason for dismissal** (e.g., "Bug fix correcting incorrect behavior per the MCP spec" or "`McpClient`'s only accessible constructor is `protected` and marked `[Experimental(MCPEXP002)]` with message 'Subclassing McpClient and McpServer is experimental and subject to change.'")
+3. **Cite any supporting discussion** from the PR description or comments (e.g., "Reviewers discussed the addition and did not flag it as a breaking concern; compatibility suppressions were added for CP0005")
+4. **Conclude with the dismissal and its category** (e.g., "Dismissed — bug fix correcting spec-non-compliant behavior" or "Dismissed — exclusively gated by `[Experimental]` API. Do not apply the `breaking-change` label.")
+
+This transparency allows the user to verify each dismissal rationale and override it if the justification is insufficient.
+
+## What to Study for Each PR
+
+For every PR in the range, examine:
+
+1. **PR description** — Authors often describe breaking changes here, or explain why a potentially breaking change is acceptable
+2. **Linked issues** — May contain discussion about breaking impact
+3. **Review comments** — Reviewers may have flagged breaking concerns or discussed why a change is acceptable despite appearing breaking (e.g., experimental gates, no external consumers, compatibility suppressions). These discussions are critical evidence when dismissing potential breaks.
+4. **General comments** — Authors and reviewers sometimes discuss breaking change justification in the PR conversation thread rather than in review comments
+5. **Code diff** — Look at changes to:
+   - Public type/member signatures
+   - Exception throwing patterns
+   - Default values and constants
+   - Return value changes
+   - Parameter validation changes
+   - Attribute changes (`[Obsolete]`, `[Experimental]`, etc.)
+   - `AppContext.TryGetSwitch` or environment variable compat switches
+   - Compatibility suppressions (e.g., `CompatibilitySuppressions.xml` for ApiCompat CP0005 etc.)
+6. **Labels** — Check if `breaking-change` is already applied

.github/skills/bump-version/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: bump-version
+description: Assess and bump the SDK version using Semantic Versioning 2.0.0. Evaluates queued changes to recommend PATCH/MINOR/MAJOR, updates src/Directory.Build.props, and creates a pull request. Owns the SemVer assessment logic shared by prepare-release and publish-release. Use when asked to bump the version, assess the version, or determine what the next version should be.
+compatibility: Requires gh CLI with repo access for creating branches and pull requests. GitHub API access for PR details when performing SemVer-informed assessment.
+---
+
+# Bump Version
+
+Assess and bump the SDK version in `src/Directory.Build.props` to prepare for the next release. This skill owns the [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) assessment logic — the [SemVer assessment guide](references/semver-assessment.md) is the single source of truth for version assessment criteria used across the release workflow by both the **prepare-release** and **publish-release** skills.
+
+> **Note**: For comprehensive release preparation — including ApiCompat/ApiDiff, documentation review, and release notes — use the **prepare-release** skill, which incorporates version assessment as part of its broader workflow.
+
+## Process
+
+### Step 1: Read Current Version and Previous Release
+
+Read `src/Directory.Build.props` on the default branch and extract:
+- `<VersionPrefix>` — the `MAJOR.MINOR.PATCH` version
+
+Display the current version to the user.
+
+Determine the previous release tag from `gh release list` (most recent **published** release). Draft releases must be ignored — they represent a pending release that has not yet shipped. Use `--exclude-drafts` or filter to only published releases when querying.
+
+### Step 2: Assess and Determine Next Version
+
+If the user provided a target version in their prompt, use it directly. Otherwise, determine the next version using one of two approaches:
+
+#### SemVer-Informed Assessment (Preferred)
+
+When context about queued changes is available or can be gathered, assess the version following the [SemVer assessment guide](references/semver-assessment.md):
+
+1. Get the list of PRs merged between the previous release tag and the target commit (typically HEAD).
+2. Classify the release level:
+   - **MAJOR** — if any confirmed breaking changes (API or behavioral), excluding `[Experimental]` APIs
+   - **MINOR** — if new public APIs, features, or obsoletion warnings are present
+   - **PATCH** — otherwise
+3. Compute the recommended version from the previous release tag (see the assessment guide for increment rules).
+4. Compare against the current version in `Directory.Build.props` and flag any discrepancy.
+5. Present the assessment with a summary table and rationale, then get user confirmation.
+
+#### Default Suggestion (Fallback)
+
+When a quick bump is needed without full change analysis, suggest the next **minor** version:
+
+- Current `1.0.0` → suggest `1.1.0`
+- Current `1.2.3` → suggest `1.3.0`
+
+Present the suggestion and let the user confirm or provide an alternative.
+
+Parse the confirmed version into its `VersionPrefix` component.
+
+### Step 3: Create Pull Request
+
+1. Create a new branch named `bump-version-to-{version}` (e.g. `bump-version-to-1.1.0`) from the default branch
+2. Update `src/Directory.Build.props`:
+   - Set `<VersionPrefix>` to the new version
+   - Update `<PackageValidationBaselineVersion>` if the MAJOR version has changed
+3. Commit with message: `Bump version to {version}`
+4. Push the branch and create a pull request:
+   - **Title**: `Bump version to {version}`
+   - **Label**: `infrastructure`
+   - **Base**: default branch
+
+### Step 4: Confirm
+
+Display the pull request URL to the user.