Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Chapter 11: The SDK Landscape

Ten Languages Walk Into a Protocol

MCP has official SDKs for ten programming languages. That’s not a typo. Ten. In roughly eighteen months since the protocol was released, the ecosystem went from “TypeScript and Python” to “basically every language anyone uses for production software.”

This chapter is a field guide to each SDK—what’s available, how mature it is, and when you might choose it.

The Official Ten

All official SDKs live under the modelcontextprotocol GitHub organization. They all support:

  • Creating MCP servers with tools, resources, and prompts
  • Building MCP clients
  • stdio and Streamable HTTP transports
  • Protocol compliance with type safety

TypeScript / JavaScript

Repository: github.com/modelcontextprotocol/typescript-sdk Package: @modelcontextprotocol/sdk on npm Maturity: The most mature SDK. First-party, battle-tested.

The TypeScript SDK is the reference implementation. When the spec changes, this SDK changes first. It provides:

  • McpServer — High-level server API with Zod schemas
  • Server — Low-level server with full control
  • Client — Client with automatic type inference
  • StdioServerTransport / StdioClientTransport
  • StreamableHTTPServerTransport / StreamableHTTPClientTransport
  • SSEServerTransport / SSEClientTransport (legacy)

Choose TypeScript when: You’re in a Node.js or Bun ecosystem, want the most documentation and examples, or want the fastest access to new protocol features.

Python

Repository: github.com/modelcontextprotocol/python-sdk Package: mcp on PyPI Maturity: Extremely mature. Co-developed alongside TypeScript.

The Python SDK features FastMCP, a decorator-based API inspired by FastAPI:

  • FastMCP — High-level decorator API
  • Server — Low-level server
  • ClientSession — Client API
  • stdio_server / stdio_client
  • StreamableHTTPServerTransport / streamablehttp_client

Choose Python when: You’re building AI/ML tools, data science integrations, or anything in the Python ecosystem. FastMCP’s decorator API is arguably the most elegant of all the SDKs.

Go

Repository: github.com/modelcontextprotocol/go-sdk Package: github.com/modelcontextprotocol/go-sdk

The Go SDK embraces Go’s conventions—typed structs, explicit error handling, and strongly-typed tool inputs/outputs:

package main

import (
    "context"
    "log"

    "github.com/modelcontextprotocol/go-sdk/mcp"
)

type GreetInput struct {
    Name string `json:"name" jsonschema:"the name of the person to greet"`
}

type GreetOutput struct {
    Greeting string `json:"greeting"`
}

func SayHi(ctx context.Context, req *mcp.CallToolRequest, input GreetInput) (
    *mcp.CallToolResult, GreetOutput, error,
) {
    return nil, GreetOutput{Greeting: "Hello, " + input.Name + "!"}, nil
}

func main() {
    server := mcp.NewServer(
        &mcp.Implementation{Name: "greeter", Version: "v1.0.0"}, nil,
    )
    mcp.AddTool(server, &mcp.Tool{Name: "greet", Description: "Say hi"}, SayHi)

    if err := server.Run(context.Background(), &mcp.StdioTransport{}); err != nil {
        log.Fatal(err)
    }
}

Choose Go when: You want fast, compiled servers with minimal resource usage. Great for infrastructure tools, CLI utilities, and servers that need to handle high concurrency.

C# / .NET

Repository: github.com/modelcontextprotocol/csharp-sdk Package: ModelContextProtocol on NuGet

The C# SDK provides attribute-based server definition:

using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = Host.CreateApplicationBuilder(args);
builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();
await builder.Build().RunAsync();

[McpServerToolType]
public static class MyTools
{
    [McpServerTool, Description("Greet someone by name")]
    public static string Greet(string name) => $"Hello, {name}!";
}

Integrates with:

  • ASP.NET Core for HTTP transports
  • Microsoft.Extensions.DependencyInjection for DI
  • Microsoft.Extensions.AI for LLM integration

Choose C# when: You’re in the .NET ecosystem, want excellent IDE support, or need to integrate with ASP.NET, Azure, or other Microsoft technologies.

Java

Repository: github.com/modelcontextprotocol/java-sdk Package: io.modelcontextprotocol.sdk:mcp on Maven Central

The Java SDK provides both synchronous and asynchronous APIs built on Reactive Streams:

var server = McpServer.sync(McpServerTransportProvider.stdio())
    .serverInfo("my-server", "1.0.0")
    .tool(
        new Tool("greet", "Greet someone",
            new JsonSchemaObject(Map.of(
                "name", new JsonSchemaProperty("string", "Name to greet")
            ), List.of("name"))),
        (exchange, request) -> {
            String name = request.arguments().get("name").toString();
            return new CallToolResult(List.of(
                new TextContent("Hello, " + name + "!")
            ));
        }
    )
    .build();
server.start();

Integrates with Spring AI for Spring Boot applications.

Choose Java when: You’re in the JVM ecosystem, have enterprise requirements, or want to use Spring Boot. The Spring AI integration makes it particularly good for enterprise deployments.

Kotlin

Repository: github.com/modelcontextprotocol/kotlin-sdk Maintained by: JetBrains

Kotlin-idiomatic API with coroutines:

val server = Server(
    ServerOptions(
        name = "my-server",
        version = "1.0.0",
    )
)

server.addTool(
    name = "greet",
    description = "Greet someone",
) { request ->
    val name = request.arguments["name"] as String
    CallToolResult(content = listOf(TextContent("Hello, $name!")))
}

Choose Kotlin when: You’re targeting JetBrains IDEs, Android, or prefer Kotlin’s syntax over Java’s.

Swift

Repository: github.com/modelcontextprotocol/swift-sdk

let server = MCPServer(name: "my-server", version: "1.0.0")

server.registerTool("greet", description: "Greet someone") { params in
    let name = params["name"] as! String
    return .text("Hello, \(name)!")
}

Choose Swift when: Building macOS or iOS applications with MCP support. Native Apple ecosystem integration.

Rust

Repository: github.com/modelcontextprotocol/rust-sdk Package: rmcp on crates.io

Uses Tokio async runtime and supports a #[tool] macro for boilerplate-free tool definitions.

Choose Rust when: You need maximum performance, memory safety guarantees, or are building systems-level tools. Excellent for high-throughput servers or embedding in native applications.

Ruby

Repository: github.com/modelcontextprotocol/ruby-sdk Package: On RubyGems

Choose Ruby when: You’re in the Rails ecosystem or want to expose Ruby application capabilities through MCP.

PHP

Repository: github.com/modelcontextprotocol/php-sdk Package: On Packagist

Choose PHP when: You’re integrating with PHP web applications, WordPress, Laravel, or other PHP frameworks.

SDK Tiers

The MCP project classifies SDKs into tiers based on feature completeness, protocol support, and maintenance commitment. While all are “official,” maturity levels vary:

Tier 1 (Most complete, regularly updated):

  • TypeScript
  • Python

Tier 2 (Full-featured, actively maintained):

  • Go
  • C#
  • Java
  • Kotlin

Tier 3 (Functional, evolving):

  • Swift
  • Rust
  • Ruby
  • PHP

This doesn’t mean Tier 3 SDKs are bad—it means they may not support every spec feature on day one. For most server-building use cases, all tiers work well.

Choosing an SDK

The decision tree is usually simple:

  1. What language does your team use? Use that SDK. The familiarity advantage outweighs almost everything else.

  2. What are you building?

    • Local CLI tools → Go, Rust (fast startup, small binaries)
    • Web services → TypeScript, Python, Java, C# (rich web frameworks)
    • Data/ML tools → Python (unbeatable ecosystem)
    • IDE plugins → TypeScript, Kotlin (depending on the IDE)
    • Mobile → Swift, Kotlin

  3. What clients will consume your server?

    • Claude Desktop → All SDKs work (stdio)
    • Remote clients → Ensure HTTP transport support
    • Browser-based → TypeScript (can run the client in the browser)

  4. What’s the team’s experience?

    • If half your team knows Go and half knows Python, pick the one that your MCP server’s domain expertise lives in. Wrapping a Python ML model? Use Python. Building a Kubernetes tool? Use Go.

The Community SDKs

Beyond the official ten, community members have built SDKs for:

  • Elixir — Leveraging BEAM for concurrent MCP servers
  • Scala — JVM alternative with functional programming
  • Dart — For Flutter/Dart applications
  • Zig — For the performance-obsessed
  • Lua — For embedding in game engines and scripted environments

These aren’t official but demonstrate MCP’s protocol-first design—if your language can parse JSON and open a socket, it can implement MCP.

Cross-Language Interoperability

One of MCP’s great strengths: a TypeScript client can talk to a Go server which calls back to a Python client for sampling. The protocol is the contract, not the implementation language.

This means:

  • Your team can use different languages for different servers
  • You can mix and match based on expertise and requirements
  • Servers written years apart in different languages just work together
  • The ecosystem grows without coordination

Summary

MCP has official SDKs for TypeScript, Python, Go, C#, Java, Kotlin, Swift, Rust, Ruby, and PHP. TypeScript and Python are the most mature; the rest are catching up fast.

Choose your SDK based on your team’s language, the problem domain, and the deployment target. The protocol guarantees interoperability, so the language choice is about developer productivity, not compatibility.

Next: configuring MCP in the tools you already use.