feat(dsl): add result DSL builders

[kpavlov]

Add result DSL builders and tests

• Introduced ToolsResultDslTest and PromptsResultDslTest to test result builders for tool and prompt operations.
• Added buildCompleteResult and buildInitializeResult for server-side result creation.
• Updated API surface to include result DSL functionality.
• Added new test cases for CallToolResult, ListResourcesResult, and ReadResourceResult to validate error handling, structured content, and metadata processing.
• Improved coverage for resource and template handling with additional edge cases for mixed-field resources and pagination
• Updated integration tests to use the buildCallToolResult DSL for constructing results, improving clarity and reducing boilerplate. Added @OptIn(ExperimentalMcpApi::class) annotations to test files requiring experimental API.
• Refactored delay handling in tests to streamline coroutine usage.

Motivation and Context

Build also results with DSL

How Has This Been Tested?

Unit test

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Tests update
• 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

[e5l]

The only thing I'm not sure about is having DSL functions on the top level. Users will receive the top-level functions buildListResourcesResult for the whole application. While it is fine for stdlib, doing this in other library will bloat top-level scope.

Should we think about scoping the DSL to specific use-sites or anchor classes?

@devcrocod, what do you think?

[kpavlov]

Should we think about scoping the DSL to specific use-sites or anchor classes?

Agree
But it might require merging #515 first where we introduce handler context object as a receiver. It will be a perfect place, but I am not sure about the visibility yet, as server handler context lives in the server module.

What if we try addressing it in the follow up PR, after #515?

[kpavlov]

Actually, I'm not sure we should be very restrictive in letting users to build data classes

[devcrocod]

The only thing I'm not sure about is having DSL functions on the top level. Users will receive the top-level functions buildListResourcesResult for the whole application. While it is fine for stdlib, doing this in other library will bloat top-level scope.

That’s true. Even in the stdlib this pattern is used rarely. Given that we already have quite a few objects, relying on a shared prefix would indeed make the api awkward to use

Should we think about scoping the DSL to specific use-sites or anchor classes?

I’ve thought about that as well, but introducing contextual scoping would require a more detailed design