MCP SDKs and Frameworks: how to choose your stack

TL;DR: Ten languages have an official MCP SDK under the modelcontextprotocol organization. Python remains the dominant choice for AI projects thanks to FastMCP (25,700 stars, roughly 70% of production servers), which cuts boilerplate by 80% compared to the low-level SDK. Go excels for performance and minimal containers. TypeScript covers Node.js applications. Java and Kotlin serve the enterprise JVM space. This article presents a working “hello tool” snippet for each main SDK, compares the low-level SDK and FastMCP side by side, and explains why Python + FastMCP is the stack of choice for the rest of the MCP-101 series.

Is MCP Python-only? No — and here is why that protocol choice matters

If you followed Part 1 of this series, you already know that MCP is built on JSON-RPC 2.0 transported over STDIO or HTTP. That protocol choice is deliberate: JSON-RPC 2.0 is a mature standard, readable by any machine, and implementable in any language capable of writing to stdout and reading from stdin. An MCP server is not a Python program — it is a process that responds to JSON messages structured according to an open specification.

In practice, that means your Claude Desktop agent can simultaneously drive an MCP server written in Go querying a PostgreSQL database, a Python server generating images, and a TypeScript server integrated into your existing Node.js application. The MCP host does not know, and does not care, what language the server is written in. It sees tools, resources, and prompts defined in a standardized JSON schema.

Because the MCP specification is open, anyone can implement it in any language. But writing a JSON-RPC parser, handling STDIO and HTTP transports, validating the input schema for each tool, and correctly implementing the initialization handshake can represent several days of work. That is precisely what the official SDKs and high-level frameworks eliminate. The modelcontextprotocol organization maintains ten official SDKs covering the most widely used languages, and frameworks like FastMCP and Google ADK have emerged to cut boilerplate even further.

This article covers the four main official SDKs with a working code snippet for each, presents FastMCP and Google ADK in their respective roles, and then gives a clear decision guide by use case. The section concludes with the justification for choosing Python + FastMCP for the rest of this series.

What official MCP SDKs are available today?

Python SDK — the most widely adopted

The Python SDK (pip install mcp, or uv add mcp with uv) is by far the most used in the ecosystem with 23,400 GitHub stars as of June 2026. Maintained by Anthropic under the modelcontextprotocol organization, it implements the full MCP specification: STDIO, SSE, and Streamable HTTP transports, tools/resources/prompts primitives, OAuth 2.1 authentication, and the sampling protocol. It works on Python 3.10+.

The SDK offers two API levels. The low-level API gives full control over every protocol message, at the cost of significant boilerplate. FastMCP (included in the package as mcp.server.fastmcp) covers common use cases with decorators. The official modelcontextprotocol quickstart uses FastMCP — not by accident, as I show in the next section.

Here is a complete “hello” tool using the low-level API, to understand what FastMCP replaces:

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

server = Server("demo")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="hello",
            description="Returns a welcome message",
            inputSchema={"type": "object", "properties": {}},
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "hello":
        return [types.TextContent(type="text", text="Hello, World!")]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

This code is correct and works. But it reveals the friction points of the low-level SDK: each tool requires two separate handlers (list_tools to announce the tool to the host, call_tool to execute it), the JSON Schema is written manually, and the STDIO transport is explicitly managed. For a server exposing ten tools, the code surface becomes significant to maintain. That is what FastMCP addresses.

Python SDK v2.0 is currently in alpha, with the client API stabilization as the main priority. For production and for this series, the v1.x stable branch applies.

TypeScript SDK — for Node.js applications and multi-runtime environments

The TypeScript SDK (npm install @modelcontextprotocol/sdk) is the second most adopted official SDK with 12,700 GitHub stars. Maintained by Anthropic, it runs on Node.js, Deno, and Bun. The current stable release is v1.29.0 (March 2026). A v2 is in pre-alpha with no announced stabilization date.

The TypeScript API is explicit but consistent with language idioms. Types are strict, input schema validation relies on Zod. The SDK includes adapters for Express, Hono, and the native Node.js HTTP server, making it straightforward to integrate into existing web applications. A single TypeScript MCP server can run as a CLI stdio process or expose an HTTP endpoint depending on the transport instantiated.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new McpServer({ name: "demo", version: "1.0.0" });

server.registerTool(
  "hello",
  {
    description: "Returns a welcome message",
    inputSchema: {}
  },
  async () => ({
    content: [{ type: "text", text: "Hello, World!" }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

The TypeScript API unifies declaration and implementation in a single registerTool call, which is more concise than the Python low-level SDK. TypeScript types ensure the input schema and the handler are consistent at compile time. For a project already running on Node.js, adding an MCP server amounts to installing a package and writing a few files in the existing structure.

The TypeScript SDK is also the natural choice for editor plugins (VS Code, Cursor, Windsurf) and for services deployed on Node.js cloud-function platforms like Vercel or Cloudflare Workers, where Python runtimes are not available.

Go SDK — performance and zero-runtime deployment

The Go SDK (go get github.com/modelcontextprotocol/go-sdk), co-maintained with Google, is at v1.6.1 (May 2026) with 4,700 GitHub stars. It is the reference option for high-throughput MCP servers or constrained environments.

The Go API follows language idioms: typed structs with JSON Schema annotations, handler functions with explicit signatures, schema inference from Go types. The jsonschema annotation on struct fields automatically generates the JSON Schema that MCP expects to validate tool inputs on the client side.

package main

import (
    "context"
    "github.com/modelcontextprotocol/go-sdk/mcp"
)

type HelloInput struct{}

type HelloOutput struct {
    Message string `json:"message" jsonschema:"description=Welcome message"`
}

func hello(
    ctx context.Context,
    req *mcp.CallToolRequest,
    _ HelloInput,
) (*mcp.CallToolResult, HelloOutput, error) {
    return nil, HelloOutput{Message: "Hello, World!"}, nil
}

func main() {
    server := mcp.NewServer("demo", "1.0.0", nil)
    mcp.AddTool(
        server,
        &mcp.Tool{Name: "hello", Description: "Returns a welcome message"},
        hello,
    )
    server.Run()
}

The Go compiler validates types at compile time: if the handler returns a type incompatible with the declared schema, the error surfaces before deployment. That is a meaningful advantage for critical MCP servers running in production. The compiled binary runs without a Python or Node.js runtime installed, simplifying Docker containers: an Alpine Linux image of a few megabytes is sufficient.

Go goroutines are also much lighter than Python threads or Node.js Promises for concurrent request handling. If your server needs to handle hundreds of simultaneous MCP requests — rare for STDIO servers, more common for HTTP-exposed production servers — Go is the appropriate choice.

Java SDK — Spring Boot integration and the JVM ecosystem

The Java SDK (spring-ai-mcp via Maven or Gradle), developed in collaboration with the Spring AI team at VMware Broadcom, is at v2.0.0 (June 2026) with 3,500 GitHub stars. It integrates natively with Spring Boot via annotations, making it familiar for enterprise Java teams that already have Spring microservices in production.

// Service exposing MCP tools
public class HelloService {

    @Tool(description = "Returns a welcome message")
    public String hello() {
        return "Hello, World!";
    }
}

// Spring Boot configuration
@SpringBootApplication
public class McpDemoApplication {

    @Bean
    public ToolCallbackProvider helloTool() {
        return MethodToolCallbackProvider.builder()
            .toolObjects(new HelloService())
            .build();
    }
}

Spring Boot integration is the Java SDK’s main strength: dependency injection, centralized configuration via application.yml, Spring Security for authentication, and Micrometer for metrics. For teams already on Spring, exposing an existing service as an MCP tool amounts to adding the @Tool annotation and a configuration bean. Migrating a Spring Boot REST service to MCP is often a matter of hours.

The Kotlin SDK (modelcontextprotocol/kotlin-sdk, v0.13.0, co-maintained with JetBrains) offers the same functionality with idiomatic Kotlin conciseness. Lambdas and language extensions reduce boilerplate compared to Java:

// Kotlin SDK
val server = Server(
    ServerInfo(name = "demo", version = "1.0.0"),
    ServerOptions(capabilities = ServerCapabilities(tools = ServerCapabilities.Tools()))
)

server.addTool(
    name = "hello",
    description = "Returns a welcome message"
) { _ ->
    CallToolResult(
        content = listOf(TextContent(text = "Hello, World!"))
    )
}

Kotlin is the recommended choice for new JVM projects. The null safety built into the type system prevents a whole class of runtime bugs that occur in Java. Kotlin coroutines integrate naturally with MCP’s async model. JetBrains co-maintains the SDK, ensuring compatibility with new Kotlin and IntelliJ versions.

Comparison table for the five main SDKs

SDK	Stable version	GitHub stars	Co-maintainer	Boilerplate	Deployment	Typical use case
Python	v1.x	23,400	Anthropic	Low (with FastMCP)	pip + venv / uv	AI, data, scripting, rapid prototyping
TypeScript	v1.29.0	12,700	Anthropic	Medium	npm + Node.js / Deno	Web apps, IDE plugins, cloud functions
Go	v1.6.1	4,700	Google	Medium	Static binary	High throughput, minimal containers
Java	v2.0.0	3,500	Spring AI / VMware	Low (annotations)	JVM + Spring Boot	Enterprise microservices, REST-to-MCP migration
Kotlin	v0.13.0	1,400	JetBrains	Very low	JVM / Android	New JVM projects, Android

 

Do high-level frameworks like FastMCP really change the game?

FastMCP: from community contribution to de facto standard

FastMCP started as a personal project by Jerrod Linderman (alias jlowin on GitHub), with a stated goal: apply to MCP the same philosophy that FastAPI brought to REST APIs — Python decorators, native types, zero manual schema configuration. The project worked at a remarkable pace. Its v1 core was contributed to and integrated into the official MCP Python SDK maintained by Anthropic. Today, from mcp.server.fastmcp import FastMCP is part of Anthropic’s own mcp package.

Since then, the project has been transferred to the PrefectHQ organization (the company behind the Prefect orchestration framework). v3.4.2 was released in June 2026 with 25,700 GitHub stars — surpassing the official Python SDK itself (23,400 stars). It reports roughly one million downloads per day on PyPI, and the majority of MCP servers in production use it.

Direct comparison: low-level SDK vs FastMCP

The difference is immediately visible on a minimal example. Here is the same “hello” tool using the low-level API (already shown in the Python section) and using FastMCP, side by side:

Low-level SDK (26 lines):

from mcp.server import Server
from mcp.server.stdio import stdio_server
import mcp.types as types

server = Server("demo")

@server.list_tools()
async def list_tools() -> list[types.Tool]:
    return [
        types.Tool(
            name="hello",
            description="Returns a welcome message",
            inputSchema={"type": "object", "properties": {}},
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "hello":
        return [types.TextContent(type="text", text="Hello, World!")]

async def main():
    async with stdio_server() as (read, write):
        await server.run(read, write, server.create_initialization_options())

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

FastMCP via official SDK (8 lines):

from mcp.server.fastmcp import FastMCP  # included in pip install mcp

mcp = FastMCP("demo")

@mcp.tool()
def hello() -> str:
    """Returns a welcome message"""
    return "Hello, World!"

if __name__ == "__main__":
    mcp.run()

FastMCP infers the JSON Schema from the function signature and the docstring. The str return type tells the SDK the tool returns text. Native Python types (str, int, list[dict]), Pydantic models, and dataclasses are all automatically converted to JSON Schema. The STDIO transport handling is absorbed by mcp.run().

On a tool with parameters, the advantage becomes even clearer:

from mcp.server.fastmcp import FastMCP
from pydantic import BaseModel, Field

mcp = FastMCP("my-server")

class QueryParams(BaseModel):
    table: str = Field(description="Table name to query")
    limit: int = Field(default=10, description="Maximum number of results")
    filter: str | None = Field(default=None, description="Optional SQL WHERE filter")

@mcp.tool()
def query_database(params: QueryParams) -> list[dict]:
    """Query a database table"""
    # business logic here
    return [{"id": 1, "name": "example"}]

FastMCP automatically generates the JSON Schema of QueryParams from the Pydantic model, including default values, optional types, and descriptions from Field(description=...) annotations. The MCP host (Claude Desktop, Claude Code CLI) sees a well-documented tool with validated parameters. Without FastMCP, that JSON schema would be written manually in inputSchema — a nested object of 15 to 20 additional lines.

FastMCP v1 (official SDK) vs FastMCP v3 standalone: what is the practical difference?

Two versions coexist. The v1, integrated into the official SDK (import from mcp.server.fastmcp import FastMCP), is stable but “frozen”: it receives security fixes but few new features. The v3 standalone (pip install fastmcp, PrefectHQ organization) goes much further:

• Integrated MCP client: FastMCP v3 includes a Python client that lets you consume MCP servers from Python code, without going through a host like Claude Desktop.
• Server composition: multiple MCP servers can be mounted under a single parent server, with automatic tool routing.
• Proxying: FastMCP v3 can act as an MCP proxy, forwarding requests to other servers — useful for caching, rate-limiting, or adding middleware.
• OpenAPI/FastAPI integration: an existing FastAPI application can be automatically converted into an MCP server by passing the app object to FastMCP. Each FastAPI route becomes an MCP tool.

For the examples in this series through Part 6, the official SDK import is sufficient. Part 7, which covers Python client MCP servers and integration testing, will switch to pip install fastmcp to access the built-in client.

Google ADK and MCPToolset: orchestrating agents with existing MCP servers

Google ADK (Agent Development Kit, v1.0 stable, announced production-ready in May 2026) takes a different approach from FastMCP: ADK does not help you create MCP servers — it helps you consume existing MCP servers in complex agent pipelines. It is an agent orchestration framework, not a server SDK.

The MCPToolset class is the central interface. When added to an ADK agent, it connects to the MCP server, lists its tools via tools/list, converts JSON Schema definitions into ADK BaseTool objects, and transparently proxies the agent’s calls to the MCP server:

from google.adk.agents import LlmAgent
from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, StdioServerParameters

agent = LlmAgent(
    name="code-assistant",
    model="gemini-2.0-flash",
    tools=[
        MCPToolset(
            connection_params=StdioServerParameters(
                command="python",
                args=["my_mcp_server.py"]
            )
        )
    ]
)

ADK is the option to consider when your project is a multi-agent pipeline rather than an isolated MCP server: orchestration of several specialized agents, task routing, shared memory management between agents. MCP plays the role of a standardized tooling layer — any community MCP server can be plugged into an ADK agent via MCPToolset. The relationship between MCP and the A2A (Agent-to-Agent) protocol, which handles communication between agents in a pipeline, is covered in a dedicated article on this site.

LangChain MCP Adapters: bridging existing LangChain stacks

If your stack uses LangChain or LangGraph, the langchain-mcp-adapters package (maintained by the langchain-ai organization, v0.3.0 in June 2026) lets you connect a LangGraph agent to any MCP server without rewriting your code:

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent

async with MultiServerMCPClient({
    "filesystem": {
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/docs"]
    },
    "my-server": {
        "command": "python",
        "args": ["my_mcp_server.py"]
    }
}) as client:
    tools = await client.get_tools()
    agent = create_react_agent(model, tools)
    result = await agent.ainvoke({"messages": [("user", "Summarize the files in the docs directory")]})

The adapter converts MCP tools into LangChain BaseTool objects. All the MCP discovery (tools/list) and call (tools/call) logic is transparent to your agent. It is the lowest-friction solution for teams that have invested in LangChain but want access to community MCP servers — including the servers listed in the official modelcontextprotocol registry and popular ones like Brave Search, GitHub, Slack, and Notion.

Which language and framework should you choose for your MCP server?

The question deserves direct answers by use case, without evasive hedging. Here is my reading of the state of the art in June 2026.

Python + FastMCP: the default choice for 90% of projects

If you are a Python developer with no technical constraint forcing another language, Python + FastMCP is the right choice. Not for lack of better alternatives, but for three concrete reasons.

First reason: the AI ecosystem. Python has the most mature and most directly useful libraries for MCP projects: NumPy and Pandas for data manipulation, scikit-learn and PyTorch for models, Hugging Face Transformers for local LLMs, boto3 for AWS, the Python Ollama client, LangChain, LlamaIndex, and dozens of others. An MCP Python server can call any of them with a single import. In Go or TypeScript, you are creating bindings for functionality that Python has provided for years.

Second reason: development speed. FastMCP reduces a working server to about ten lines. With uv as the package manager, the environment is reproducible and installed in seconds on any machine. For prototyping a tool that calls an external API, analyzes a CSV file, or generates an image, the “write — test in Claude Desktop — iterate” cycle is extremely short.

Third reason: community and documentation. The Python SDK is the best documented, GitHub examples of MCP servers are predominantly in Python or TypeScript, and when you search for how to implement a specific pattern (resources, prompts, sampling, OAuth), someone has already solved it in Python and published the code. Part 2 of this series lists dozens of community MCP servers, almost all in Python or TypeScript.

Go: when performance and deployment are real constraints

Go is the right choice in three specific situations. First: your MCP server handles significant volumes of concurrent requests and latency needs to remain predictable. If you are exposing an MCP server over HTTP to multiple agents simultaneously — multi-agent architecture, shared MCP server across teams — Go goroutines handle concurrency natively with very low overhead compared to Python threads or asyncio workers.

Second situation: you are deploying in a minimal container where you do not want to ship a 50-100 MB Python runtime. A compiled Go binary of 10 MB runs on an Alpine Linux image with zero runtime dependencies. For large-scale Kubernetes deployments or AWS Lambda functions where each megabyte has a cost, that matters.

Third situation: your team is Go-first with existing Go services in production, along with established monitoring, testing, and CI/CD tooling. Staying in the same language reduces cognitive overhead and avoids maintaining two toolchains. Google’s co-maintenance signals the Go SDK will continue evolving at the same pace as the specification.

TypeScript: for web application integration or editor plugins

TypeScript is the right call when your MCP server is a component of an existing Node.js application. Integration with Express, Hono, or Fastify is native, existing authentication and rate-limiting middleware is reusable, and build tools (esbuild, tsx, tsc) are already in place. TypeScript is also the natural choice for VS Code, Cursor, and Windsurf extensions, which run inside the editor’s Node.js process.

Multi-runtime compatibility is an additional advantage: a single TypeScript MCP server can run on Deno Deploy for reduced global latency, or on Bun for superior I/O performance, without changing a line of code — provided you avoid Node.js-specific APIs.

Java/Kotlin: for enterprise JVM projects

If your organization runs Spring Boot for its microservices, the Java Spring AI SDK integrates MCP into the Spring ecosystem with familiar annotations. Monitoring tools (Micrometer, Spring Boot Actuator), centralized configuration (Spring Cloud Config), and Spring Security apply to your MCP server exactly as they would to any other Spring bean. Migrating an existing Spring Boot REST service to MCP often requires no major refactoring.

Kotlin is the recommended option for new JVM projects. Null safety built into the type system prevents a whole class of runtime bugs that occur in Java. Kotlin coroutines integrate naturally with MCP’s async model. JetBrains co-maintains the SDK, ensuring compatibility with new Kotlin and IntelliJ releases.

Decision table

Situation	Recommendation	Main reason
New project, no language constraint	Python + FastMCP	AI ecosystem, dev speed, community
High request volume, latency-critical	Go + go-sdk	Lightweight goroutines, static binary
Existing Node.js app or editor plugin	TypeScript SDK	Middleware reuse, multi-runtime compatibility
Spring Boot microservices already in place	Java SDK (Spring AI)	Familiar annotations, native Spring integration
New JVM project or Android	Kotlin SDK	Null safety, coroutines, JetBrains co-maintained
Google ADK multi-agent pipeline	ADK MCPToolset	Agent orchestration — MCP consumer, not creator
Existing LangChain/LangGraph stack	langchain-mcp-adapters	Zero rewrite, transparent bridge to MCP servers

 

Conclusion: Python + FastMCP as the foundation of MCP-101

The MCP SDK landscape is richer than it first appears. Ten languages, five different industrial maintainers (Anthropic, Google, Microsoft, JetBrains, VMware Broadcom), and high-level frameworks that have redefined the developer experience in a matter of months. That is the mark of a protocol that has found its place in the industry.

The choice of Python + FastMCP for the rest of this series is not arbitrary. It is the path of least friction for 90% of developers who want to expose tooling to an AI agent: an unmatched library ecosystem, FastMCP eliminating technical boilerplate, and a community that has already solved most integration problems. Part 8 will return to Go to build the same server in a direct comparison — same features, two languages, concrete measurement of the differences.

Before writing the first line of code for a real MCP server, the next part of the series covers security. MCP introduces attack vectors that classical security scanners do not yet detect: prompt injection via tool descriptions, credential exfiltration, privilege escalation between tools on the same server. These risks exist regardless of the language chosen — a malicious tool remains malicious whether written in Python, Go, or TypeScript. Part 4 lays the security foundations before we touch the first @mcp.tool() decorator.

FAQ

Are FastMCP standalone (pip install fastmcp) and FastMCP in the official SDK (mcp.server.fastmcp) interchangeable?

The base API is compatible: @mcp.tool(), @mcp.resource(), and @mcp.prompt() work identically in both versions. The difference lies in advanced features: the Python MCP client, server composition, proxying, and OpenAPI/FastAPI integration are only available in FastMCP v3 standalone. For the examples in this series through Part 6, the official SDK import is sufficient. Part 7 (Python client and integration testing) switches to pip install fastmcp.

Can you connect MCP servers written in different languages to the same agent?

Yes, with no constraints. A Claude Desktop agent can simultaneously connect to a Python server, a Go server, and a TypeScript server. The configuration in claude_desktop_config.json simply lists the startup command for each server, and the MCP host manages the connections in parallel over STDIO or HTTP. JSON-RPC 2.0 is the common denominator — the implementation language is invisible to the host.

Does the Python MCP SDK work with models other than Claude?

The Python SDK implements the MCP protocol, not the Claude API. Any MCP client can connect to a Python server: Claude Desktop, Claude Code CLI, Gemini CLI, Cursor, Windsurf, Continue, Cline. Since OpenAI adopted MCP in March 2025, OpenAI ecosystem tools also support the protocol. An MCP server you write in Python is accessible to any MCP-compatible agent, regardless of the model behind it.

Is Docker required to deploy a Python MCP server?

No, it is not mandatory for local development. A Python MCP server in STDIO mode can run directly in a virtualenv managed by uv, declared in your MCP client configuration (claude_desktop_config.json for Claude Desktop, .mcp.json for Claude Code CLI). Docker is useful if you want to deploy the server in HTTP mode in a cloud or Kubernetes environment, or if you want strict dependency isolation across several projects on the same machine.

Why do Go and TypeScript have fewer GitHub stars than FastMCP?

FastMCP (25,700 stars) surpasses the official Go (4,700) and TypeScript (12,700) SDKs because it solves an immediately visible developer experience problem: comparing low-level and FastMCP code samples is enough to convince. Official SDKs accumulate stars from developers using MCP in a specific language due to professional constraints — a smaller audience. That is not a signal of lower quality or weaker support: the Go SDK is co-maintained by Google, the TypeScript SDK by Anthropic, both are actively developed.

Do C and C++ have an official MCP SDK?

No. No official MCP SDK exists for C or C++ as of today. Both languages are absent from the modelcontextprotocol organization, despite their place in the TIOBE top 5. The target community for MCP — AI agent developers, LLM tooling builders, productivity application developers — codes predominantly in Python, TypeScript, and Go. C and C++ can implement MCP by manually parsing JSON-RPC 2.0 (the specification is public), but without an official SDK to absorb the boilerplate. If your project is in C++, the most pragmatic path remains exposing your logic through a Python binding or a Go microservice that speaks MCP.