DEV Community

Yigit Konur
Yigit Konur

Posted on

Building MCP Servers for Any Language (including Kotlin / Ruby / Rust / Java / Go / Typescript / Python / Swift / C# Based MCPs)

#mcp

This report provides a definitive, expert-level analysis of production-grade Model Context Protocol (MCP) server implementations across a matrix of nine programming languages and three core transport protocols. It is synthesized from extensive research into official documentation, reference implementations, and mature community projects to serve as a comprehensive guide for architects and engineers building on this foundational AI standard.

Section 1: Foundational Principles of the Model Context Protocol

This section establishes a firm understanding of the protocol's foundational principles, architecture, and strategic purpose, which are essential before dissecting specific implementations.

1.1. Defining MCP: The "USB-C for AI" and the M x N Problem

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, designed to universalize the integration between Large Language Models (LLMs) and external tools, data sources, and systems. It addresses what is often termed the "M x N" integration problem: without a standard, M AI clients (such as integrated development environments or chat applications) would need to build M custom integrations to connect with N distinct tools (like version control systems, databases, or project management APIs). MCP transforms this combinatorial explosion into a linear M + N problem by creating a standardized communication layer, much like USB-C provides a universal physical port for diverse peripherals.

The protocol's design is heavily influenced by the Language Server Protocol (LSP), which solved a similar M x N problem for developer tools. This strategic focus on developer tool integration is a primary and highly impactful use case, with major early adopters being developer-centric environments like Zed, Replit, Cursor, and Visual Studio Code.

1.2. MCP vs. Traditional APIs: A Paradigm for AI Consumption

A crucial distinction for system architects is the difference between a traditional Application Programming Interface (API) and an MCP server. An API is designed for consumption by human developers or programs with predefined logic; it is built for entities that know exactly what they want to do. In contrast, an MCP server is designed specifically for consumption by AI models. Instead of exposing rigid API endpoints, an MCP server provides a machine-readable manifest of its capabilities. This "plug-and-play" architecture allows an AI model to dynamically discover what actions are possible, what inputs they require, and how to use them, enabling it to plan and execute complex, multi-step tasks without hard-coded integrations.

1.3. The MCP Triumvirate: Host, Client, and Server Architecture

The MCP architecture is defined by three core participants that work in concert to facilitate communication between an AI and the outside world. Understanding the distinct roles of each component is essential for implementing and integrating MCP-based systems.

  • MCP Host: The primary AI-powered application where the end-user interaction occurs, such as Visual Studio Code with the GitHub Copilot extension, Zed, Cursor, or Claude Desktop. The host is responsible for coordinating and managing connections to one or more MCP servers.
  • MCP Server: The program that exposes the context—the tools, resources, and prompts—to the AI model. An MCP server can be a lightweight, standalone program running locally on a user's machine, like a filesystem server, or a remote service accessible over a network, such as the official Sentry MCP server.
  • MCP Client: A component, typically embedded within the host, that establishes and maintains a direct, one-to-one connection with a single MCP server. The host instantiates a separate client for each server connection, maintaining a strict one-client-per-server relationship. The client acts as the intermediary, translating the LLM's needs into structured MCP messages.

This architecture is built upon a two-layer protocol stack. The inner Data Layer is based on JSON-RPC 2.0 and defines the core message types and primitives, while the outer Transport Layer defines the mechanisms for data exchange. This separation ensures protocol semantics remain consistent across different communication channels.

1.4. Core Primitives: The Language of MCP

MCP defines a clear vocabulary of primitives that servers can expose to allow an LLM to discover, understand, and utilize external capabilities.

  • Tools: These are executable functions that allow an LLM to perform actions that may have side effects, such as sending a message via a Slack API, creating a file, or running a database query. Servers advertise their tools with a unique name, a natural language description, and a formal JSON Schema defining the required input arguments.
  • Resources: These are URI-addressable, read-only data sources that provide context to an LLM without causing side effects, analogous to a GET request in a REST API. Examples include reading the content of a file or fetching a database record. The distinction between action-oriented "Tools" and data-oriented "Resources" provides a crucial semantic hint to the LLM, promoting safer and more predictable interaction models.
  • Prompts: These are reusable, parameterized templates that guide and structure the LLM's interactions for specific, repetitive, or structured tasks, functioning much like well-designed API contracts.

1.5. The MCP Lifecycle: From Handshake to Shutdown

Every interaction between an MCP client and server follows a well-defined lifecycle based on the JSON-RPC 2.0 protocol, ensuring a shared understanding of capabilities and state.

  1. Connection and Initialization: The session begins when the client establishes a connection and sends an InitializeRequest. This message includes the protocol versions it supports and its own capabilities, such as whether it can handle "sampling" requests for the LLM to generate text.
  2. Capability Negotiation: The server responds with an InitializeResult, confirming the negotiated protocol version and advertising its own capabilities. These capabilities can include support for tools and whether it can send dynamic tools/list_changed notifications if its available tools change during a session.
  3. Operation: Once initialized, the client can discover available primitives (tools/list, resources/list) and invoke them to fulfill the LLM's objectives.
  4. Shutdown: The protocol specifies a graceful shutdown sequence to ensure no operations are left in an inconsistent state. For a local process, this often involves the client closing the server's input stream and waiting for the process to exit.

Section 2: The MCP Transport Layer: A Deep Dive

The choice of transport protocol is a critical architectural decision, directly impacting a server's deployment model, scalability, and security posture. The specification has evolved from a simple, local-only model to a robust, flexible standard for remote communication.

2.1. A Comparative Analysis of MCP Transport Protocols

Feature STDIO (Standard Input/Output) SSE (Server-Sent Events) - Legacy Streamable HTTP
Ideal Use Case Local tools, CLI integrations, desktop assistants (e.g., VS Code, Claude Desktop). Legacy remote systems, educational purposes to understand protocol evolution. All modern remote servers, scalable web services, public-facing tools.
Communication Model Direct, synchronous inter-process communication via stdin and stdout. Asynchronous, bidirectional. Uses two separate HTTP connections: a GET for server-to-client streaming (SSE) and a POST for client-to-server messages. Asynchronous, bidirectional. Uses a single HTTP endpoint. Can operate in a stateless request/response mode or be "upgraded" to a stateful streaming connection.
Network Accessibility None. Confined to the local machine. Yes. Accessible over any IP network. Yes. Accessible over any IP network.
Scalability Low. Limited to a single client connection per server process. Moderate. The dual-connection model adds complexity to infrastructure like load balancers. High. The single-endpoint model and support for stateless operation make it highly compatible with modern, scalable web infrastructure.
Authentication None required. Security is inherent through process isolation on the local machine. Custom implementation required. Typically handled via HTTP headers (e.g., Bearer tokens). Natively supports standard HTTP authentication methods (Bearer tokens, API keys, OAuth).
Implementation Complexity Low. The simplest transport to implement. High. The dual-endpoint architecture is complex and "awkward". Moderate. Simpler than legacy SSE due to the single endpoint.
Current Spec Status Active. The standard for local communication. Deprecated as of MCP specification version 2025-03-26. Active. The current recommended standard for all remote communication.

2.2. STDIO: For Secure, Local Process Integration

Standard Input/Output (STDIO) is the default and most fundamental transport, designed for inter-process communication (IPC) on a single machine. The MCP host launches the server as a local subprocess. The client writes newline-delimited JSON-RPC messages to the server's stdin stream, and the server writes responses to stdout. It is critical that any server-side logging is directed exclusively to the stderr stream to avoid interfering with the protocol.

This transport is ideal for integrating local tools where network overhead is unnecessary and security is paramount, such as a filesystem server or a CLI tool controlled by an AI agent. The operating system's process isolation provides a natural sandbox. This is the preferred method for command-line tools (like the Heroku CLI server) and integrations with desktop applications like Claude Desktop or VS Code. Its primary limitations are its confinement to the local machine, its lifecycle being bound to the parent process, and its single-client-per-process model.

2.3. The Evolution of Remote Transports

2.3.1. Legacy SSE: The "Architectural Awkwardness"

The original approach for remote servers was a standalone "HTTP with SSE" transport. Since Server-Sent Events (SSE) is inherently a one-way channel (server-to-client), the protocol had to be supplemented with a second, separate channel for client-to-server messages. This created what has been described as an "architectural awkwardness." The complex workflow involved a GET request to one endpoint (e.g., /sse) to establish the SSE stream and separate POST requests to another endpoint (e.g., /messages) for sending messages to the server. Due to this complexity and the superiority of the modern alternative, the standalone SSE transport was officially deprecated in the MCP specification version 2025-03-26. While the transport is deprecated, the SSE format (text/event-stream) remains a core component of the modern Streamable HTTP transport.

2.3.2. Streamable HTTP: The Modern Standard for Scalable, Remote Services

Streamable HTTP is the modern, recommended transport for all remote MCP servers, designed to overcome the limitations of the legacy SSE model and provide a robust foundation for enterprise-grade web services. It unifies all communication over a single HTTP endpoint (e.g., /mcp) and supports multiple HTTP methods for full session control: POST for client-to-server messages, GET to open a persistent stream for server-to-client notifications, and DELETE to terminate a session.

This transport offers immense flexibility by operating in two primary modes:

  • Stateless Request/Response: For simple, atomic tool calls, the client sends an HTTP POST with a JSON-RPC payload, and the server returns a single HTTP response with the result. This model is ideal for highly scalable, serverless deployments.
  • Stateful Streaming: For interactions requiring a persistent connection, the connection can be "upgraded." A server can respond to a POST request with a streaming response by using the text/event-stream content type, establishing a long-lived channel for bidirectional communication over the single initial connection. This enables the server to stream progress updates or multiple content blocks. Similarly, a GET request can be used to open a persistent stream for server-to-client notifications.

To manage stateful interactions, the server can issue a globally unique and secure session identifier via the Mcp-Session-Id response header. The client must include this header in all subsequent requests to maintain its session. For network reliability, the server can attach a unique ID to each event sent over a stream. If the connection is interrupted, a client can reconnect and include the Last-Event-ID header, allowing a compliant server to replay any missed messages.

2.4. Production Security Paradigms for Network Transports

MCP is designed with production security as a primary concern. The specification mandates several critical security practices for the network-exposed Streamable HTTP transport.

  • Authentication & Authorization: OAuth 2.1 is mandated as the default authorization framework for remote servers. A server should respond to unauthenticated requests with an HTTP 401 Unauthorized status and a WWW-Authenticate header, directing the client to an authorization server to obtain a token. This design allows MCP servers to integrate seamlessly with existing enterprise Identity and Access Management (IAM) systems.
  • Transport-Level Security:
    • DNS Rebinding Protection: Servers must validate the Origin header on all incoming HTTP requests to prevent this class of attack. Official SDKs typically provide built-in options to enable this protection.
    • Cross-Origin Resource Sharing (CORS): For browser-based clients, CORS headers must be configured correctly. It is crucial to expose the Mcp-Session-Id header to allow the client to read it and maintain sessions.
    • Secure Binding: When running a server with a network transport locally (e.g., for testing), it should bind only to the localhost interface (127.0.0.1) to prevent accidental network exposure.

Section 3: Production-Grade MCP Server Implementations: A Language-by-Language Analysis

This section presents a detailed analysis of MCP server implementations, organized by programming language. The selected examples are drawn from official reference implementations and mature community projects, chosen to represent production-ready architectural patterns and best practices.

3.1. Python

The Python ecosystem for MCP is among the most mature, anchored by the official SDK which provides the high-level FastMCP framework that simplifies and accelerates server development.

  • Protocol: STDIO

    • Server Identification & Use Case: The modelcontextprotocol/servers/filesystem is an official reference server providing secure, sandboxed access to the local filesystem for AI coding assistants. Another example, RGGH/mcp-client-x, is a well-structured project demonstrating both synchronous (calculate_bmi) and asynchronous (fetch_weather) tools.
    • Architectural Overview: Servers are typically implemented using the FastMCP class from the mcp Python SDK. This framework uses Python decorators (@mcp.tool(), @mcp.resource()) to seamlessly expose standard Python functions as MCP primitives. The SDK's mcp.run() method defaults to the STDIO transport.
    • Production-Ready Features: A critical feature of the filesystem server is its security sandbox, which restricts all file operations to root directories specified via command-line arguments, preventing malicious path traversal requests. FastMCP also leverages Pydantic for automatic type validation of tool arguments, generating structured JSON-RPC error responses without requiring manual validation code.

    • Configuration & Execution:

      # Install the official SDK and a server
pip install "mcp[cli]" mcp-server-filesystem
# Run the server, allowing access to the current directory
python -m mcp_server_filesystem .

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The modelcontextprotocol/servers/github (archived) and memory servers are official examples demonstrating remote gateways mounted within a Starlette ASGI application. The highly popular Crawl4AI RAG MCP Server (coleam00/mcp-crawl4ai-rag), with approximately 1.4k stars and 473 forks as of July 2025, exposes web-crawling and Retrieval-Augmented Generation capabilities over MCP, integrating with Crawl4AI, Supabase (PostgreSQL + pgvector), and optionally Neo4j. It uses FastMCP and can be run with either STDIO or SSE transports. Additionally, the OpenDevin autonomous AI software engineer project uses MCP as the communication layer between its agent core and its sandboxed Docker environment. For educational purposes, theailanguage/mcp_streamable_http demonstrates stateless servers, and ragieai/fastapi-sse-mcp provides tutorial code for FastAPI integration.
    • Architectural Overview: The best practice for high-performance services is to build with FastMCP and mount the server within a Starlette or FastAPI ASGI application. This allows deployment with a production-grade ASGI server like Uvicorn or Gunicorn for horizontal scaling.
    • Protocol Implementation: The mcp.streamable_http_app() method from the SDK generates a complete ASGI-compliant application, correctly handling POST, GET, and DELETE requests for the full Streamable HTTP lifecycle. The SSE capability is intrinsic to this transport; when a long-running tool is invoked or a client makes a GET request, the server can stream updates. For instance, long-running tools can use the Context object, passed by FastMCP, to send $/tool/progress notifications.

    • Configuration & Execution:

      # Install dependencies for a web server
pip install "mcp[cli]" uvicorn starlette
# In server.py, mount the FastMCP instance into a Starlette app
# Set environment variables for authentication (e.g., for the GitHub server)
export GITHUB_API_TOKEN="your_token"
# Run the server with Uvicorn
uvicorn server:app --host 0.0.0.0 --port 8000

3.2. TypeScript

The TypeScript SDK is a peer to the Python SDK in maturity and is the basis for many official reference servers, which are part of a bundle with over 62,000 stars and 7,000 forks. It commonly integrates with the Express.js framework.

  • Protocol: STDIO

    • Server Identification & Use Case: The official modelcontextprotocol/servers/git server is a production-ready example that exposes Git operations as MCP tools without requiring shell access. The TypeScript version of the filesystem server is another key reference. For learning purposes, joeBlockchain/mcp-server-client provides a more minimal example.
    • Architectural Overview: Servers are built using the McpServer class from the @modelcontextprotocol/sdk npm package. Tools are registered with handler functions and Zod schemas for robust validation. The implementation connects the server to an instance of StdioServerTransport.
    • Production-Ready Features: The Git server demonstrates advanced event-loop management, using child_process.execFile for non-blocking Git commands and setImmediate to yield the event loop during expensive scans of commit history, ensuring the server remains responsive.

    • Configuration & Execution:

      # Install and run a server directly using npx
npx -y @modelcontextprotocol/server-filesystem /path/to/project

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The heroku/mcp-server is a production-grade server for interacting with the Heroku platform. For serverless platforms, the Stateless Hono MCP Server (mhart/mcp-hono-stateless) is designed for environments like Cloudflare Workers. The boilingdata/mcp-server-and-gw project (84★) acts as a gateway, bridging local STDIO servers to remote clients by translating frames to Server-Sent Events. The Fillout MCP Server (danielma-tic/fillout-mcp-server) is notable as an early adopter of the low-level @modelcontextprotocol/core library. Reports on its function vary; it is generally described as a stateless server that wraps the Fillout.io form-management API, while its listing on Glama.ai describes it as a "DALL-E 3 image generation server." A clear template for Express is available in yunusemredilber/express-mcp-sse-server, and mcp-streamable-http-typescript-server serves as a template for stateful servers with session management.
    • Architectural Overview: Servers are typically built with the MCP SDK and a web framework like Express.js or Hono. The StreamableHTTPServerTransport is the primary mechanism.
    • Protocol Implementation: This requires setting up routes for POST, GET, and DELETE requests on an /mcp endpoint and passing the request to the transport's handleRequest() method. The implementation must manage sessions, typically by storing transport instances in a map keyed by the session ID provided in the Mcp-Session-Id header.

    • Configuration & Execution:

      # Install and run the Heroku server
npx -y @heroku/mcp-server
# Set auth token (or use `heroku mcp:start` to leverage existing login)
export HEROKU_API_KEY="your-auth-token"

3.3. C# / .NET

The C# SDK is developed with Microsoft's collaboration, featuring deep integration with the .NET ecosystem, including the generic host builder, dependency injection, ASP.NET Core, and a dotnet new template for rapid scaffolding.

  • Protocol: STDIO

    • Server Identification & Use Case: The Microsoft Official Quickstart, available via dotnet new mcpserver, is the canonical example, creating a minimal server with a random number tool. Community examples include servers for Azure Self-Help and MSBuild Binlog analysis.
    • Architectural Overview: A .NET console application using the generic host builder. The SDK provides convenient extension methods like .AddMcpServer(), .WithStdioServerTransport(), and .WithToolsFromAssembly(). Configuration is often passed via environment variables set within a host's JSON configuration, such as .vscode/mcp.json.
    • Protocol Implementation: Tools are defined in static classes, and methods are marked with attributes for discovery. Reports vary on the precise attribute names used; some documentation specifies [McpServerToolType] and [McpServerTool], while other sources refer to them as [MCPToolProvider] and [MCPTool]. The .WithStdioServerTransport() method registers the transport that manages JSON-RPC communication over the console streams.

    • Configuration & Execution:

      # Install the official template
dotnet new install Microsoft.Extensions.AI.Templates
# Create and run a new server project
dotnet new mcpserver -n MyMcpServer
cd MyMcpServer && dotnet run

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The Microsoft Official Azure Tutorial for .NET demonstrates adding MCP capabilities to an ASP.NET Core web app and deploying it to Azure App Service. Flagship production examples include the Azure MCP Server, Remote MCP Functions (.NET), and Azure DevOps MCP Server. A clear standalone example is iaspnetcore/MCPServer, which contains separate projects for STDIO and SSE transports.
    • Architectural Overview: An ASP.NET Core application. MCP services are registered via dependency injection (e.g., .AddMcpServer().WithHttpTransport()) and mapped to a route (e.g., app.MapMcp("/api/mcp")).
    • Protocol Implementation: The ModelContextProtocol.AspNetCore NuGet package provides an IMcpServerTransport implementation built on the ASP.NET Core request pipeline. This allows MCP servers to leverage the rich features of the ecosystem, including the Kestrel web server, authentication middleware, and efficient asynchronous streaming with IAsyncEnumerable<T> for SSE. The ExampleHttpServer from the SDK repository showcases a stateless server using Minimal APIs and delegating request handling to the SDK's HttpServer.HandleRequest static method.

    • Configuration & Execution:

      # In an ASP.NET Core project, add the NuGet package
dotnet add package ModelContextProtocol.AspNetCore --prerelease
# In Program.cs, add the services and map the endpoint, then run the application
dotnet run

3.4. Java

The Java MCP ecosystem is heavily integrated with the Spring Framework, particularly Spring AI, which provides powerful auto-configuration for building enterprise-grade servers. There are varying reports on the level of independent adoption in the Java ecosystem. Some analyses as of mid-2025 note a lack of discoverable, public production-grade applications. Conversely, other reports point to significant adoption within major frameworks, with projects like the Quarkiverse "quarkus-mcp-server" extension, Wanaku MCP Router, and Solon-AI cited as being used in production, alongside enterprise-focused examples from vendors like Microsoft and Alibaba. As of May 2025, Maven Central reported 106 published artifacts declaring a dependency on io.modelcontextprotocol.sdk:mcp, signaling growing adoption.

  • Protocol: STDIO

    • Server Identification & Use Case: The spring-ai-starter-mcp-server starter can configure a STDIO server when no web dependencies are present in a Spring Boot project. For a non-Spring example, the mcp-java-sdk-examples repository from codeboyzhou contains a canonical Filesystem server that demonstrates building with the core SDK.
    • Architectural Overview: In a Spring Boot application, including the starter without web dependencies defaults to a StdioServerTransportProvider. Tools are defined as standard Spring beans using @Tool annotations.
    • Protocol Implementation: The StdioServerTransportProvider from the core Java SDK (io.modelcontextprotocol.sdk:mcp) manages the communication over System.in and System.out, with Spring Boot auto-configuration abstracting the setup.

    • Configuration & Execution:

      # Build the executable JAR
./mvnw clean package
# Run the server
java -jar target/your-application-name.jar

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: For traditional servlet-based applications, the spring-ai-starter-mcp-server-webmvc starter is used. For high-performance, reactive services, the spring-ai-starter-mcp-server-webflux starter is used. The Alibaba and Spring team collaboration, spring-ai-alibaba, is presented as the "industry's first Streamable HTTP implementation solution" for Java, designed for enterprise use with Higress. A well-documented community example is kaifcoder/spring-demo-mcp-server-sse, a Spring Boot user service.
    • Architectural Overview: A Spring Boot web application. The McpWebMvcServerAutoConfiguration or McpWebFluxServerAutoConfiguration automatically exposes the necessary HTTP endpoints. The WebFlux version is built on Project Reactor and Netty for a fully non-blocking architecture.
    • Protocol Implementation: The WebMvcSseServerTransportProvider leverages Spring MVC's built-in support for SSE. The WebFlux transport is more advanced, allowing tool implementations to return reactive Mono or Flux objects, which the framework seamlessly integrates into the MCP streaming response flow.

    • Configuration & Execution:

      # Add appropriate web starter (webmvc or webflux) and MCP server starter
# Build and run the Spring Boot application
./mvnw spring-boot:run

3.5. Go

The official Go SDK is explicitly marked as unstable and pre-release as of mid-2025, with a stable version planned for August 2025. The authoritative examples are those within the SDK repository, though several mature community projects exist.

  • Protocol: STDIO

    • Server Identification & Use Case: The official SDK's stdio-server is the canonical reference. go-go-golems/go-go-mcp is a more feature-rich, production-grade server that can be installed via Homebrew and can dynamically reload tools from YAML files. BearHuddleston/go-mcp-server-example is another well-documented, production-oriented server with structured logging and graceful shutdown.
    • Architectural Overview: A standalone Go application. The official SDK example creates a server with mcp.NewServer, registers tools, and runs it with server.Run(ctx, mcp.NewStdioTransport()).
    • Protocol Implementation: The mcp.NewStdioTransport() function creates a transport that reads from os.Stdin and writes to os.Stdout. Go's strong typing is used by defining tool parameters in structs with JSON tags for safety.

    • Configuration & Execution:

      # Clone an example repository
git clone https://github.com/BearHuddleston/go-mcp-server-example.git
cd go-mcp-server-example
# Run the server (stdio is the default)
go run ./cmd/mcpserver

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: While the official SDK lacks a high-level abstraction for HTTP, its http-server example demonstrates integration with the standard net/http library by using protocol.NewHTTPHandler. Community SDKs like ThinkInAIXYZ/go-mcp provide a more mature implementation with a dedicated http.Handler for Streamable HTTP, including examples of integration with the Gin web framework. The MCP Registry service itself uses the Go SDK to create short-lived probe clients to validate server conformance over Streamable HTTP. Other projects include davidferlay/mcp-go-sse-server, a standalone example of the legacy SSE transport, and xk6-mcp, a k6 extension for load-testing MCP servers.
    • Architectural Overview: A Go web application using a framework like net/http or Gin. The community go-mcp SDK provides a handler that can be mounted into a router to manage all MCP traffic on a single endpoint.
    • Protocol Implementation: A manual implementation would use Go's net/http package, setting the Content-Type to text/event-stream and using an http.Flusher to incrementally write SSE-formatted messages to the response stream.

    • Configuration & Execution:

      # For a Gin server using a community SDK
go get github.com/ThinkInAIXYZ/go-mcp
go get github.com/gin-gonic/gin
# Run the server application
go run main.go

3.6. Ruby

The official Ruby SDK is maintained with Shopify and integrates well with the Ruby on Rails ecosystem.

  • Protocol: STDIO

    • Server Identification & Use Case: The SDK provides a clear example of using StdioTransport. A notable community project is maquina-app/rails-mcp-server (282 ★), a feature-rich gem that can analyze a host Rails application and run in STDIO mode. The mcp-rb gem provides a more lightweight, Sinatra-style DSL.
    • Architectural Overview: A Ruby script or gem executable. A server is created with MCP::Server.new, tools are registered, and the StdioTransport is run.
    • Protocol Implementation: The SDK's StdioTransport class handles the loop of reading from $stdin and writing to $stdout.

    • Configuration & Execution:

      # From within a Rails project with the maquina gem installed
bundle exec rails-mcp-server

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The seuros/action_mcp project (50 ⭐, 300+ commits) is a premier, production-grade Rails engine designed for large, network-based deployments, explicitly built for the modern Streamable HTTP transport. It notably drops STDIO support, considering it unsuitable for production Rails environments. The fast-mcp framework by yjacquin provides FastMcp::RackMiddleware for embedding an MCP server into any Rack-compatible application like Sinatra.
    • Architectural Overview: ActionMCP runs as a Rack engine within a Rails application, exposing a single endpoint. fast-mcp uses a middleware to embed the server into a Rack application.
    • Protocol Implementation: These frameworks handle the full HTTP lifecycle. ActionMCP is designed for production servers like Puma or Falcon and can use an :active_record session store for persistence. The core Ruby SDK's StreamableHTTPTransport uses a Mutex to protect session data and Open3.popen3 for non-blocking command execution within tools.

    • Configuration & Execution:

      # For an ActionMCP server, run via a rack-up file
# (after installing and configuring the gem in a Rails app)
bin/rails s -c mcp.ru -p 62770

3.7. Rust

The Rust ecosystem is emerging, focused on performance and safety with the rmcp SDK on crates.io, which is built on Tokio and the Axum/Hyper stack.

  • Protocol: STDIO

    • Server Identification & Use Case: The rmcp SDK provides a StdioTransport example in counter_stdio.rs. A practical application is automataIA/mcp-rustdoc-parser, a server that makes Rust's documentation accessible to an AI assistant.
    • Architectural Overview: A standalone Rust binary using tokio as the async runtime. A transport is created with rmcp::transport::stdio, and a service is bound to it.
    • Protocol Implementation: The rmcp SDK handles the JSON-RPC parsing and I/O.

    • Configuration & Execution:

      # Add rmcp and tokio to Cargo.toml
# Build the release binary
cargo build --release
# Run the server
./target/release/my_mcp_server

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: There are conflicting reports regarding the maturity of Streamable HTTP support in the official rmcp SDK. Some sources state it is "in progress and not yet available," and the official documentation notes its finalization is underway. However, other reports point to the existence of a counter_streamhttp.rs example within the SDK and note that community projects like mcp-proxy already depend on the rmcp::transport::streamable_http module. For the legacy SSE transport, the SDK provides a clear counter_sse.rs example built with axum. Projects like mcp-ectors are designed as enterprise-ready, actor-based servers using SSE, and mcp-containerd exposes Containerd's CRI as MCP tools over both STDIO and SSE.
    • Architectural Overview: An Axum web server. An SseServer is created from the SDK, and the MCP service logic is attached.
    • Protocol Implementation: The SDK uses axum::serve to bind a TCP listener and serve the Axum router, with graceful shutdown handled by a CancellationToken.

    • Configuration & Execution:

      # In a Rust project with axum and rmcp dependencies
cargo run --example counter_sse

3.8. Swift

The Swift ecosystem is maturing, with a focus on local, STDIO-based servers for integration with macOS and iOS applications. The community-driven Cocoanetics/SwiftMCP framework provides a rich, macro-based developer experience alongside the official SDK.

  • Protocol: STDIO

    • Server Identification & Use Case: The official SDK provides the devyhan/mcp-swift-example-server as a minimal "echo" tool provider tailored for Claude Desktop, with a compiled binary under 1 MB. The Cocoanetics/SwiftMCP framework is a more mature option.
    • Architectural Overview: A Swift command-line application.
    • Protocol Implementation: Cocoanetics/SwiftMCP uses modern Swift Macros (@MCPServer, @MCPTool) to automatically generate MCP metadata and boilerplate from native Swift function signatures. The official SDK's StdioTransport, used in the devyhan example, wraps file descriptors in non-blocking DispatchIO channels for efficient I/O.

    • Configuration & Execution:

      # Build the Swift executable
swift build -c release
# The client configuration must point to the compiled binary
# e.g., in claude_desktop_config.json:
# "command": "/path/to/.build/release/MySwiftServer"

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The official modelcontextprotocol/swift-sdk contains a reference HTTPServerTransport built on SwiftNIO that implements the chunked body pipeline for Streamable HTTP. The community project sebsto/mcpserverkit provides a façade over the official SDK, adding an HTTP and Server-Sent Events front-end using the Vapor 4 framework.
    • Architectural Overview: These servers are built on SwiftNIO, the high-performance networking framework that powers Vapor.
    • Protocol Implementation: The HTTPServerTransport is a self-contained HTTP server that listens on a port and handles the full Streamable HTTP lifecycle. sebsto/mcpserverkit uses an Actor for managing client fan-out. The Cocoanetics/SwiftMCP transport has built-in support for Bearer token and OAuth 2.1 authentication.

    • Configuration & Execution:

      # From the command line for a standalone server
swift run MyServer httpsse --port 8080 --token your-secret-token

3.9. Kotlin

The official Kotlin SDK is maintained with JetBrains and is notable for its Kotlin Multiplatform support. Conflicting reports exist on its adoption; some sources claim its dependency graph shows zero dependents, while others counter that while there is a lack of discoverable public production applications, the SDK itself is robust, with strong integrations into frameworks like Ktor and Spring.

  • Protocol: STDIO

    • Server Identification & Use Case: The official SDK's Weather STDIO Server sample is a key reference used by the Cursor IDE. A more minimal learning example is takahirom/mcp-kotlin-minimal-client-server-sample.
    • Architectural Overview: A standalone Kotlin application built on Coroutines for efficient, non-blocking I/O.
    • Protocol Implementation: The transport uses Okio for zero-copy buffered I/O and Dispatchers.IO for any blocking operations to avoid starving the reader loop.

    • Configuration & Execution:

      # Build a "fat JAR" with all dependencies
./gradlew shadowJar
# Run the server
java -jar build/libs/server-all.jar

  • Protocol: Streamable HTTP & SSE

    • Server Identification & Use Case: The SDK provides a Ktor plugin for Streamable HTTP. The Embabel Agent MCP Server (from a framework with 2.3k GitHub stars) is a prime example, turning any Embabel agent into an MCP server over SSE using Spring WebFlux. The http4k-ai module for the http4k toolkit also provides first-class support for MCP with HTTP streaming. The SDK includes an early-access File-Streamer sample that uses a suspending Ktor route to stream large files. gaplo917/kotlin-cyrpto-price-spring-mcp-server-demo is a complete Spring AI example for fetching crypto prices.
    • Architectural Overview: A Ktor or Spring Boot web application.
    • Protocol Implementation: In Ktor, the mcp { ... } plugin automatically sets up the required endpoints. In Spring WebFlux, the implementation returns a reactive Flux<ServerSentEvent<String>> for streaming.

    • Configuration & Execution:

      # For a Ktor or Spring application, run via the Gradle wrapper
./gradlew run

Section 4: The Developer Ecosystem and Operator's Handbook

This section provides strategic guidance on tooling, compatibility, and architectural decision-making for teams working with MCP.

4.1. The Toolkit: Debugging and Configuration

  • MCP Inspector: This is an indispensable utility that acts as a proxy to monitor the JSON-RPC message flow between a client and a server. It supports all transport types and is essential for diagnosing issues with message formatting, transport connections, and tool invocation.
  • Host Configuration: Host applications are typically configured via a JSON file, such as .vscode/mcp.json for Visual Studio Code or claude_desktop_config.json for Claude Desktop. These files define server properties, including the transport type, the command and args for stdio servers, and the url for remote servers. The env block is the standard and secure method for passing secrets like API keys.

4.2. Bridging the Transport Gap: The Proxy Pattern

A significant practical challenge is the fragmented or evolving support for different transports across host applications. A modern Streamable HTTP server may be incompatible with an older client that only supports STDIO. The proxy pattern is the essential solution to this problem.

Lightweight local proxies like mcp-remote, supergateway, and the Rust-based mcp-proxy serve as an essential compatibility layer. The proxy is configured in the host as a stdio server. The host launches the proxy locally, which in turn establishes the remote connection (SSE or Streamable HTTP) to the actual server, transparently translating messages between the two transports. This decouples the client's capability from the server's implementation, ensuring maximum compatibility.

{
  "mcpServers": {
    "remote-server-via-proxy": {
      "command": "npx",
      "args": [ "-y", "mcp-remote", "http://example.com/mcp" ]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Section 5: Strategic Insights and Recommendations

The Model Context Protocol is an actively evolving standard, transitioning from a niche protocol for developer tools into a foundational infrastructure layer for the broader AI agent economy.

5.1. A Decision Framework for Transport Protocol Selection

  • Choose STDIO when: The tool is a wrapper around a local CLI or is intrinsically tied to a local development environment (e.g., filesystem, Git). Security via process isolation is the highest priority, no network exposure is desired, and the primary client is a single-user desktop application.
  • Choose Streamable HTTP (Stateless) when: Building scalable, public-facing, or serverless services where each invocation is an independent, atomic transaction (e.g., a weather API or currency conversion tool). This is ideal for serverless deployments.
  • Choose Streamable HTTP (Stateful) when: The service must be accessible remotely, support multiple users, and requires maintaining context across multiple, sequential tool calls from a single client session (e.g., a multi-step database transaction or an interactive workflow that pushes progress updates). This mode is necessary for horizontally scalable architectures behind a load balancer that require session persistence.

5.2. Comparative Analysis of SDK Maturity and Ecosystems

  1. Tier 1 (Production-Ready): Python & TypeScript. These have the most mature official SDKs with high-level abstractions (FastMCP, McpServer) and are used to build the official reference servers. They represent the lowest-risk, highest-velocity path for new projects.
  2. Tier 2 (Enterprise-Focused): Java & C#. Backed by major corporate partners (Spring, Microsoft), these SDKs are robust and deeply integrated into their respective enterprise ecosystems, signaling a strong commitment to stability and long-term support.
  3. Tier 3 (In-Development): Go & Rust. The official SDKs are explicitly designated as unstable or incomplete. Choosing these languages is promising for high-performance needs but currently requires a willingness to work with low-level APIs and manage the risk of breaking changes.
  4. Tier 4 (Community-Driven): Ruby & Swift. While official SDKs exist, these ecosystems are heavily supplemented by strong community projects and framework integrations (Rails, Vapor, SwiftMCP) that provide mature, production-ready patterns.

5.3. Future Outlook and Protocol Trajectory

MCP is actively evolving. Recent updates to the specification have introduced advanced features like Elicitation, which allows a tool to pause its execution and interactively request more information from the user via the client. This, along with structured tool outputs and more flexible authentication, signals a clear move towards enabling more sophisticated and interactive agentic workflows.

The protocol's most critical feature for enterprise adoption is its robust, security-first design, particularly its standardization on OAuth 2.1. This deliberate choice differentiates MCP from ad-hoc tool-use protocols and makes it a trustworthy and auditable standard. This is palatable to the corporate security and compliance teams who are the ultimate gatekeepers for connecting powerful LLMs to sensitive enterprise systems, positioning MCP as a foundational infrastructure layer for the future of AI.

Top comments (0)