New MCP Schema types

[devcrocod]

Implement the last version of the mcp schema and complete restructuring of the mcp schema implementation from a monolithic types.kt file into separate files.

• Support resource links in tool result content #158
• Revisit schema. Generate Kotlin code from json-schema #185
• Nullable default properties must have null default value instead of EmptyJsonObject #353
• Support models from the latest MCP Spec #298
• Implement SEP-973: Icons and metadata support #248

Motivation and Context

The previous implementation of the mcp schema was outdated and contained several issues. In addition, it stored all mcp types in a single large file, which made maintenance and further development more difficult

How Has This Been Tested?

All tests passed

Breaking Changes

Yes. The new types are now located in a separate package. Additionally, many types have new parameters and modified constructors

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

to adopt the new structure:
Before:

  import io.modelcontextprotocol.kotlin.sdk.InitializeRequest
  import io.modelcontextprotocol.kotlin.sdk.Resource

After:

  import io.modelcontextprotocol.kotlin.sdk.types.InitializeRequest
  import io.modelcontextprotocol.kotlin.sdk.types.Resource

[Copilot]

Pull Request Overview

This PR implements the latest MCP schema version and restructures the codebase by moving all MCP types from a monolithic types.kt file into separate, organized files within a new io.modelcontextprotocol.kotlin.sdk.types package. This is a significant breaking change that requires users to update their import statements.

Key Changes:

• Updated to latest MCP protocol version (2025-03-26)
• Reorganized types into dedicated files (tools.kt, sampling.kt, resources.kt, etc.)
• Modified API structure with request params now nested (e.g., request.name → request.params.name)
• Renamed test files with "OldSchema" prefix for backward compatibility testing
• Updated server and client implementations to work with new type structure

Reviewed Changes

Copilot reviewed 99 out of 102 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
samples/weather-stdio-server/src/test/kotlin/.../ClientStdio.kt	Updated client to use simplified callTool API with direct map arguments instead of CallToolRequest wrapper
samples/weather-stdio-server/src/main/kotlin/.../McpWeatherServer.kt	Updated server tool handlers to access arguments via request.arguments?.get() pattern
samples/kotlin-mcp-server/src/test/kotlin/SseServerIntegrationTest.kt	Fixed type comparison to use lowercase conversion for content type assertion
samples/kotlin-mcp-server/src/main/kotlin/.../server.kt	Reordered GetPromptResult constructor to use named parameter for description
samples/kotlin-mcp-client/src/main/kotlin/.../MCPClient.kt	Added null-safe handling for tool.inputSchema.properties
kotlin-sdk-test/.../OldSchema*.kt	Renamed test files with OldSchema prefix and updated to use fully qualified type names from types package
kotlin-sdk-server/.../Server.kt	Updated Server class to access request parameters via nested params property
kotlin-sdk-server/.../ServerSession.kt	Updated to use new types package imports and nested params structure
kotlin-sdk-core/.../types/*.kt	New test files for comprehensive coverage of new type structure
kotlin-sdk-core/.../types/tools.kt	New tools.kt defining Tool, CallToolRequest/Result with updated structure

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kpavlov]

Thanks, @devcrocod! 👍🏻
These changes are great for making the SDK compatible with the latest MCP specification.

Here are the next steps:

• Update the tests for serialization, ensuring we cover all optional parameters and the required ones.
• Double-check the issues mentioned and confirm we have a test for each one before we close them.
• Take a look at the user API to avoid exposing transport-level classes directly to users (blog post). Instead, use interfaces and DSLs over concrete classes. This will help us keep different architecture levels separate.

Moving forward, let’s aim for incremental changes rather than trying to include too much in a single pull request.