MCP obsługuje mechanizmy transportu do komunikacji między Bobem a serwerami MCP.

Przegląd

MCP oferuje trzy opcje transportu, każda odpowiednia dla różnych scenariuszy wdrożenia:

Transport STDIO (serwery lokalne)
Transport Streamable HTTP (nowoczesny standard dla serwerów zdalnych)
Transport SSE (przestarzała opcja zdalna)

Każdy transport ma odrębne cechy, zalety i przypadki użycia.

Transport STDIO

Transport STDIO działa lokalnie na twoim komputerze i komunikuje się poprzez standardowe strumienie wejścia/wyjścia.

Jak działa transport STDIO

Bob uruchamia serwer MCP jako proces potomny
Komunikacja odbywa się przez strumienie procesu: Bob pisze do STDIN serwera, serwer odpowiada do STDOUT
Każda wiadomość jest rozdzielona znakiem nowej linii
Wiadomości są sformatowane jako JSON-RPC 2.0

Klient                    Serwer
  |                         |
  |---- wiadomość JSON ---->| (przez STDIN)
  |                         | (przetwarza żądanie)
  |<---- wiadomość JSON ----| (przez STDOUT)
  |                         |

Charakterystyka STDIO

Lokalność: Działa na tym samym komputerze co Bob
Wydajność: Bardzo niskie opóźnienie i narzut (brak stosu sieciowego)
Prostota: Bezpośrednia komunikacja procesów bez konfiguracji sieciowej
Relacja: Relacja jeden-do-jednego między klientem a serwerem
Bezpieczeństwo: Inherentnie bardziej bezpieczne bez ekspozycji sieciowej

Kiedy używać STDIO

Transport STDIO jest idealny dla:

Lokalnych integracji i narzędzi działających na tym samym komputerze
Operacji wrażliwych na bezpieczeństwo
Wymagań niskiego opóźnienia
Scenariuszy z jednym klientem (jedna instancja Boba na serwer)
Narzędzi wiersza poleceń lub rozszerzeń IDE

Przykład implementacji STDIO


const server = new Server({name: 'local-server', version: '1.0.0'});
// Zarejestruj narzędzia...

// Użyj transportu STDIO
const transport = new StdioServerTransport(server);
transport.listen();

Transport Streamable HTTP jest nowoczesnym standardem dla zdalnej komunikacji serwera MCP, zastępując starszy transport HTTP+SSE. Działa przez HTTP/HTTPS i umożliwia bardziej elastyczne implementacje serwerów.

Jak działa transport Streamable HTTP

Serwer udostępnia pojedynczy punkt końcowy HTTP (punkt końcowy MCP), który obsługuje zarówno metody POST, jak i GET
Bob wysyła żądania do tego punktu końcowego MCP używając HTTP POST
Serwer przetwarza żądanie i wysyła odpowiedź
Opcjonalnie serwer może używać Server-Sent Events (SSE) przez to samo połączenie do strumieniowania wielu wiadomości lub powiadomień do Boba

To umożliwia podstawowe interakcje żądanie-odpowiedź, jak również bardziej zaawansowane strumieniowanie i komunikację inicjowaną przez serwer.

Klient                             Serwer
  |                                  |
  |---- HTTP POST /mcp_endpoint ---->| (żądanie klienta)
  |                                  | (przetwarza żądanie)
  |<--- Odpowiedź HTTP / Strumień SSE --| (odpowiedź serwera / strumień)
  |                                  |

Charakterystyka Streamable HTTP

Nowoczesny standard: Preferowana metoda dla nowych implementacji zdalnych serwerów MCP
Dostęp zdalny: Może być hostowany na innym komputerze niż Bob
Skalowalność: Może obsługiwać wiele połączeń klientów jednocześnie
Protokół: Działa przez standardowy HTTP/HTTPS
Elastyczność: Obsługuje proste żądanie-odpowiedź i zaawansowane strumieniowanie
Pojedynczy punkt końcowy: Używa pojedynczej ścieżki URL dla całej komunikacji MCP
Uwierzytelnianie: Może używać standardowych mechanizmów uwierzytelniania HTTP
Kompatybilność wsteczna: Serwery mogą utrzymywać kompatybilność ze starszymi klientami HTTP+SSE

Kiedy używać Streamable HTTP

Transport Streamable HTTP jest idealny dla:

Wszystkich nowych rozwojów zdalnych serwerów MCP
Serwerów wymagających solidnej, skalowalnej i elastycznej komunikacji
Integracji, które mogą obejmować strumieniowanie danych lub powiadomienia wysyłane przez serwer
Usług publicznych lub scentralizowanych narzędzi
Zastępowania przestarzałych implementacji transportu SSE

Przykład implementacji Streamable HTTP

Konfiguracja w settings.json:

{
  "mcpServers": {
    "StreamableHTTPMCPName": {
      "type": "streamable-http",
      "url": "http://localhost:8080/mcp"
    }
  }
}

Dla implementacji po stronie serwera, zapoznaj się z dokumentacją SDK MCP dla StreamableHTTPClientTransport.

Kompatybilność wsteczna z HTTP+SSE

Klienci i serwery mogą utrzymywać kompatybilność wsteczną z przestarzałym transportem HTTP+SSE.

Serwery chcące obsługiwać starszych klientów powinny nadal hostować zarówno punkty końcowe SSE (/events), jak i POST (/message) starego transportu, obok nowego punktu końcowego MCP zdefiniowanego dla transportu Streamable HTTP.

Transport SSE (przestarzały)

Transport Server-Sent Events (SSE) działa na zdalnym serwerze i komunikuje się przez HTTP/HTTPS. Dla nowych zdalnych serwerów użyj zamiast tego transportu Streamable HTTP.

Jak działa transport SSE

Bob łączy się z punktem końcowym SSE serwera przez żądanie HTTP GET
To ustanawia trwałe połączenie, przez które serwer może wysyłać zdarzenia do Boba
Dla komunikacji klient-serwer, Bob wykonuje żądania HTTP POST do oddzielnego punktu końcowego
Komunikacja odbywa się przez dwa kanały:
- Strumień zdarzeń (GET): Aktualizacje serwer-klient
- Punkt końcowy wiadomości (POST): Żądania klient-serwer

Klient                             Serwer
  |                                  |
  |---- HTTP GET /events ----------->| (ustanowienie połączenia SSE)
  |<---- strumień zdarzeń SSE --------| (trwałe połączenie)
  |                                  |
  |---- HTTP POST /message --------->| (żądanie klienta)
  |<---- zdarzenie SSE z odpowiedzią -| (odpowiedź serwera)
  |                                  |

Charakterystyka SSE

Dostęp zdalny: Może być hostowany na innym komputerze niż Bob
Skalowalność: Może obsługiwać wiele połączeń klientów jednocześnie
Protokół: Działa przez standardowy HTTP (nie są potrzebne specjalne protokoły)
Trwałość: Utrzymuje trwałe połączenie dla wiadomości serwer-klient
Uwierzytelnianie: Może używać standardowych mechanizmów uwierzytelniania HTTP

Kiedy używać SSE

Transport SSE jest odpowiedni dla:

Dostępu zdalnego przez sieci
Scenariuszy z wieloma klientami
Usług publicznych
Scentralizowanych narzędzi, do których wielu użytkowników potrzebuje dostępu
Integracji z usługami internetowymi

Przykład implementacji SSE

import express from 'express';

const app = express();
const server = new Server({name: 'remote-server', version: '1.0.0'});
// Zarejestruj narzędzia...

// Użyj transportu SSE
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
  console.log('MCP server listening on port 3000');
});

Rozważania dotyczące wdrożenia

Wybór między transportem STDIO a zdalnym (Streamable HTTP lub SSE) bezpośrednio wpływa na sposób wdrażania i zarządzania serwerami MCP.

STDIO: Wdrożenie lokalne

Serwery STDIO działają lokalnie na tym samym komputerze co Bob:

Instalacja: Plik wykonywalny serwera musi być zainstalowany na komputerze każdego użytkownika
Dystrybucja: Musisz dostarczyć pakiety instalacyjne dla różnych systemów operacyjnych
Aktualizacje: Każda instancja musi być aktualizowana osobno
Zasoby: Używa procesora, pamięci i dysku lokalnego komputera
Kontrola dostępu: Opiera się na uprawnieniach systemu plików lokalnego komputera
Integracja: Łatwa integracja z lokalnymi zasobami systemowymi (pliki, procesy)
Wykonanie: Uruchamia się i zatrzymuje z Bobem (cykl życia procesu potomnego)
Zależności: Wszelkie zależności muszą być zainstalowane na komputerze użytkownika

Przykładowy przypadek użycia:

Lokalne narzędzie wyszukiwania plików używające STDIO:

Działa na komputerze użytkownika
Ma bezpośredni dostęp do lokalnego systemu plików
Uruchamia się, gdy jest potrzebne przez Boba
Nie wymaga konfiguracji sieciowej
Musi być zainstalowane obok Boba lub przez menedżera pakietów

Zdalne: Wdrożenie hostowane

Serwery zdalne (Streamable HTTP lub SSE) mogą być wdrożone na zdalnych serwerach i dostępne przez sieć:

Instalacja: Instalowane raz na serwerze, dostępne dla wielu użytkowników
Dystrybucja: Pojedyncze wdrożenie obsługuje wielu klientów
Aktualizacje: Scentralizowane aktualizacje wpływają na wszystkich użytkowników natychmiast
Zasoby: Używa zasobów serwera, a nie lokalnego komputera
Kontrola dostępu: Zarządzana przez systemy uwierzytelniania i autoryzacji
Integracja: Bardziej złożona integracja z zasobami specyficznymi dla użytkownika
Wykonanie: Działa jako niezależna usługa (często ciągle)
Zależności: Zarządzane na serwerze, a nie na komputerach użytkowników