Add application_type to the Dynamic Client Registration request

[jayaraman-venkatesan]

Fixes #1545

Implements SEP-837 — adds application_type to the Dynamic Client Registration request when the C# SDK registers against an OIDC-flavored authorization server.

Summary

Without application_type, an OIDC AS applies its spec-mandated default. This PR makes the SDK supply the correct value.

What happens in the changes

When the caller does set DynamicClientRegistrationOptions.ApplicationType explicitly, the value is cross-checked against the inferred type at ClientOAuthProvider construction time. A conflict (for example "web" paired with a localhost redirect URI) throws ArgumentException synchronously, before any HTTP request is sent

What changed

src/ModelContextProtocol.Core/Authentication/

• DynamicClientRegistrationRequest.cs — adds the application_type field on the wire DTO.
• DynamicClientRegistrationOptions.cs — adds the ApplicationType setter so callers can opt out of inference and force a specific value.
• ClientOAuthProvider.cs — resolution happens once, in the constructor:
  • Reads the explicit value from options.
  • Calls a private static InferApplicationType(Uri redirectUri) helper (mirrors Go sdk's inferApplicationType`).
  • Throws ArgumentException on conflict; otherwise stores the resolved value and writes it back onto options.DynamicClientRegistration.ApplicationType so callers can observe what was selected.
  • The DCR request initializer just reads the stored value at HTTP time.

tests/ModelContextProtocol.Tests/Authentication/ClientOAuthProviderApplicationTypeTests.cs (new)

• 5 inferred-value tests — localhost, 127.0.0.1, [::1], custom scheme, https remote.
• 2 explicit-match-preserved tests — explicit value that agrees with inference is kept.
• 2 conflict-throws tests — exact full exception message asserted, including (Parameter 'options').

Contract changes

• New nullable property on DynamicClientRegistrationOptions: ApplicationType { get; set; }. Backwards-compatible — existing callers default to null and now get an inferred value where they previously got nothing on the wire.
• New throw at construction: ClientOAuthProvider (constructed via HttpClientTransport) now throws ArgumentException when an explicit ApplicationType conflicts with the redirect URI shape.
• Mutation of caller's options: the constructor writes the resolved ApplicationType back to options.DynamicClientRegistration.ApplicationType. This is documented in the xmldoc and mirrors Go's behavior.

Test plan

• dotnet build src/ModelContextProtocol.Core — 0 warnings, 0 errors.
• dotnet test tests/ModelContextProtocol.Tests (net10.0) — 1969 passed, 0 failed, 5 skipped
• New ClientOAuthProviderApplicationTypeTests — 9/9 pass, including exact-message assertion on the conflict throw.

[jayaraman-venkatesan]

@mikekistler - can you please help reviewing this PR

[mikekistler]

Looks good! 👍

Thank you for this contribution!

[jayaraman-venkatesan]

@mikekistler
If you are good with the changes can you help merging this? I don't have write access yet to do that.

[jeffhandley]

Thanks for getting this together, @jayaraman-venkatesan.

Before we merge, SEP-837's normative language ("MCP clients MUST be prepared to handle registration failures…", "SHOULD surface a meaningful error", "MAY retry with adjusted application_type or redirect URIs") is aimed at MCP clients. As the C# SDK those clients are built on, we don't have to implement the surfacing or retry behavior ourselves, but we do need to make sure a developer using the SDK is able to do those things, and we should prove it with tests in this PR before we close out #1545.

Two test scenarios I'd like added here:

1. DCR failure is recoverable from the consumer's perspective. When an OIDC AS rejects the DCR call (e.g. 400 invalid_redirect_uri), the failure should propagate to the SDK consumer with enough context: the HTTP status, the AS error body, and ideally the application_type / redirect_uri the SDK actually sent; so the consumer can produce a meaningful error. Please add a negative test that mocks an OIDC AS rejecting registration and asserts the thrown exception (or returned result) carries that information.
2. A consumer can retry registration with adjusted parameters. The SDK's resolved ApplicationType is fixed in the ClientOAuthProvider constructor today, so a retry implies the consumer constructing a new provider with a different ApplicationType (or different redirect URI). Please add a test that does exactly that: first DCR attempt rejected, second attempt succeeds after swapping ApplicationType; to (a) prove the surface supports the MAY behavior and (b) catch any subtle state-carryover bugs.

One related point worth thinking about while you're in here: the synchronous ArgumentException on conflict (e.g. "web" + localhost) is a nice guardrail, but it also blocks a consumer from retrying with a combination the AS happens to require; for example, if an AS demanded "web" paired with a localhost redirect, the SDK would refuse to even attempt that registration. Probably fine to leave the behavior as-is, but worth a sentence in the xmldoc noting that consumers who need that flexibility must set ApplicationType explicitly and that the inference will not override it. Up to you.

[jayaraman-venkatesan]

Thanks @jeffhandley, pushed 2643b0b addressing both test scenarios

1. DCR failure is recoverable.
   Added DcrFailureTests.DcrRejection_PropagatesToConsumer_WithStatusBodyAndSentParameters: Asserts the surfaced McpException carries the HTTP status, the AS error body, and the application_type the SDK sent. To make the last part possible, the DCR-failure throw in ClientOAuthProvider now appends the sent application_type/redirect_uri (status + body were already included).

2. Retry with adjusted parameters.
   Added ConsumerCanRetryRegistration_WithAdjustedRedirectUri_AfterRejection: proving the MAY-retry surface. TestOAuthServer now captures LastApplicationType so the retry's wire value is assertable.

The failure is build (windows-latest, Release), I suppose is pre-existing flake in McpServerBuilderExtensionsMessageFilterTests, a re-run should clear it, please help kick one off when you get a chance. Thanks!