Fix the docs and make the more readable

[MikeAlhayek]

Motivation and Context

Fix the docs and make them more readable. Using new() { ... } syntax does not give the reader all the info in the documentation files.

How Has This Been Tested?

Breaking Changes

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

[eiriktsarpalis]

Using new() { ... } syntax does not give the reader all the info in the documentation files.

I can see how removing target typing makes things easier to read in the absence of intellisense, but it shouldn't prevent you from getting started if you just copied the code to an IDE. No strong opinions here, but I wonder if this should reflect a wider policy on target typing in documentation, cc @stephentoub @halter73 @gewarren

[gewarren]

For Learn, we tend to use the most modern syntax in code snippets, so we do use new() { .. }. Adding @BillWagner for comment.

[MikeAlhayek]

I’m not questioning the syntax used in the project code itself. However, for those of us reading the documentation—especially without diving into the source—it’s not immediately clear what object is being passed. The documentation would benefit from being more explicit, providing clear context and explanations to help readers understand what’s going on without needing to infer from modern syntax like the spread operator or other potentially less intuitive constructs.

For the project code, by all means, continue using modern patterns. But in the docs, clarity and completeness should take priority to support a broader range of readers.

[stephentoub]

it’s not immediately clear what object is being passed.

For most of the changes made in this PR, there's no information gained, e.g.
await builder.Build().RunAsync(); vs var app = builder.Build(); await app.RunAsync();
ChatOptions options = new() vs var options = new ChatOptions()
McpServerOptions options = new() vs var options = new McpServerOptions()

There's only a couple where the change actually conveys additional information, e.g.
ServerInfo = new() { Name = "MyServer", Version = "1.0.0" } vs ServerInfo = new Implementation() { Name = "MyServer", Version = "1.0.0" }
While I don't think that additional information is particularly valuable, I'd be ok with just those few additions.

The rest are stylistic preferences and I'd prefer we keep what we have.

[MikeAlhayek]

await builder.Build().RunAsync(); vs var app = builder.Build(); await app.RunAsync();
ChatOptions options = new() vs var options = new ChatOptions()
McpServerOptions options = new() vs var options = new McpServerOptions()

@stephentoub These changes are more for consistency between the documents. If you still don't think there is a value it making the documents consistent, please let me know and I'll revert the changes.

[stephentoub]

await builder.Build().RunAsync(); vs var app = builder.Build(); await app.RunAsync();
ChatOptions options = new() vs var options = new ChatOptions()
McpServerOptions options = new() vs var options = new McpServerOptions()

@stephentoub These changes are more for consistency between the documents. If you still don't think there is a value it making the documents consistent, please let me know and I'll revert the changes.

Thanks. Yeah, let's revert all but the few that actually add information.

[MikeAlhayek]

@stephentoub no problem. I undid the changes.