MCP

MCP-Tutorial: Von null bis Produktionsserver mit der 2026-07-28-Spezifikation

Von IdeaBosqueZuletzt aktualisiert: 2026年8月22日

Kernpunkte

97M+ monatliche MCP SDK-Downloads, aber nur 8,5% der Server verwenden OAuth — die Protokolladoption überholt die Sicherheitslage, was die Produktionshärtungsschritte in diesem Tutorial für jedes B2B-Deployment nicht optional macht.
MCP SDK v2 reduzierte die Paketgröße um 83% und verbesserte die Geschwindigkeit um 25% — die 2026-07-28-Spezifikation wurde zusammen mit neu gestalteten SDKs für TypeScript, Python, Go und C# veröffentlicht, mit Migrationsleitfäden für jedes.
Die 2026-07-28-Spezifikation entfernte Sessions und den Initialize-Handshake — jede Anfrage ist nun eigenständig und landet auf jeder Serverinstanz hinter einem einfachen Round-Robin-Load-Balancer ohne gemeinsamen Zustand.
Der MCP-Roadmap vom 22. August definiert fünf Prioritätsbereiche — Agent-Identität, HTTP-Transport-Vereinheitlichung, agentische Messaging-Primitive, verbesserte Tool-Primitive und SDK-Entwicklererfahrung — jeweils behandelt im Produktionspfad dieses Tutorials.
82% der MCP-Server sind anfällig für Path Traversal (laut Practical DevSecOps) — die Sandboxing- und Eingabevalidierungsschritte hier sind der Unterschied zwischen einer Demo und einem Deployment.

Das Model Context Protocol überschritt 97 Millionen monatliche SDK-Downloads im Jahr 2026, wobei die TypeScript- und Python-SDKs jeweils über 1 Milliarde Gesamt-Downloads erreichten. Die 2026-07-28-Spezifikation lieferte die größte Revision seit dem Launch: einen zustandslosen Protokollkern, erstklassige Erweiterungen und drei Deprecations, die die Deployment-Oberfläche vereinfachen. Drei Wochen später, am 22. August, veröffentlichten die MCP-Maintainer einen neuen Roadmap, der fünf Prioritätsbereiche für den nächsten Spezifikationszyklus definierte — Agent-Identität, HTTP-Transport-Vereinheitlichung, agentische Messaging-Primitive, verbesserte Tool-Primitive und SDK-Entwicklererfahrung.

Dieses Tutorial behandelt den Produktionspfad: den Aufbau eines MCP-Servers, der zustandslos, horizontal skalierbar, identitätsbewusst und bereit für die Enterprise-Prioritäten des Roadmaps ist. Der offizielle Quickstart führt durch einen Wetter-Server, der mit Claude Desktop verbunden ist. Dieser Artikel beginnt, wo dieser Quickstart endet — die Schritte zwischen einer funktionierenden Demo und einem Server, den Sie hinter einem B2B-Agentensystem in Produktion betreiben würden.

Schritt 1 — Projekteinrichtung mit SDK v2

Die 2026-07-28-Spezifikation wurde zusammen mit neu gestalteten SDKs veröffentlicht. Das TypeScript SDK v2 reduzierte die Paketgröße um etwa 83% und verbesserte die Leistung um 25% durch ein neues Client-Server-Split. Das Python SDK 2.0+, das Go SDK und das C# SDK v2.0 sprechen alle die Protokollversion 2026-07-28 ab Veröffentlichungstag, mit detaillierten Migrationshinweisen für die Breaking Changes.

Für dieses Tutorial verwenden wir Python 3.10+ mit uv:

uv init mcp-server
cd mcp-server
uv venv
source .venv/bin/activate
uv add "mcp[cli]"

Das mcp[cli]-Extra bringt die CLI-Werkzeuge zum Ausführen und Inspizieren von Servern. Das SDK verwendet Python-Type-Hints und Docstrings, um Tool-Definitionen automatisch zu generieren — Sie definieren eine Funktion, dekorieren sie, und die Protokollmetadaten werden aus der Signatur abgeleitet.

Schritt 2 — Definieren Sie Ihre ersten Tools

Ein MCP-Server bietet drei Fähigkeitstypen: Tools (Funktionen, die das Modell aufruft), Resources (Daten, die das Modell liest) und Prompts (vorlagenbasierte Workflows). Für einen B2B-Server sind Tools die primäre Oberfläche — sie sind, wie ein Agent einen Katalog durchsucht, ein Angebot erstellt oder Bestände reserviert.

from mcp.server import MCPServer

mcp = MCPServer("catalog-server")

@mcp.tool()
async def search_catalog(query: str, supplier_id: str | None = None) -> str:
    """Search the supplier catalog by keyword, optionally filtered by supplier.

    Args:
        query: Search keyword (SKU, product name, or category)
        supplier_id: Optional supplier filter (e.g., "s-12")
    """
    results = await catalog.search(query=query, supplier_id=supplier_id)
    return format_results(results)

@mcp.tool()
async def get_pricing(sku: str, quantity: int) -> str:
    """Get tiered pricing for a SKU at a given quantity.

    Args:
        sku: Supplier product identifier
        quantity: Order quantity (determines pricing tier)
    """
    price = await pricing_engine.get(sku=sku, quantity=quantity)
    return f"SKU {sku}: ${price.unit_price:.2f} (tier: {price.tier_name})"

Der Docstring jedes Tools wird zur Beschreibung, die das Modell in seiner Tool-Liste sieht. Die Type-Hints werden zum Eingabe-Schema. Dies ist das MCP Module Code Standard-Muster: Jedes Tool hat ein typisiertes Schema, einen klaren Docstring und eine einzige Verantwortlichkeit.

STDIO-Logging-Falle: Bei STDIO-basierten Servern niemals auf stdout schreiben — es korrumpiert den JSON-RPC-Nachrichtenstrom. Verwenden Sie das Standardmodul logging, das auf stderr schreibt:

import logging
logger = logging.getLogger(__name__)
logger.info("Catalog search: query=%s", query)  # stderr, safe

Schritt 3 — Transport: STDIO vs. Streamable HTTP

Die 2026-07-28-Spezifikation macht Remote-MCP-Server „nicht anders als jede andere HTTP-Workload" (Spezifikations-Changelog). Die zweite Priorität des Roadmaps — HTTP-native Transport-Vereinheitlichung — erweitert dies auf lokale Server, die Streamable HTTP über stdio sprechen, und vereinheitlicht auf einem Transportmodell.

Für lokale Entwicklung und Desktop-Clients ist STDIO die Standardeinstellung:

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

Für B2B-Produktions-Deployments — wo der Agent als Cloud-Workload läuft, nicht als Desktop-App — ist Streamable HTTP der Produktions-Transport. Der Server läuft hinter einem Load Balancer, akzeptiert HTTP-POST-Anfragen mit Mcp-Method- und Mcp-Name-Headern und antwortet mit JSON-RPC über HTTP:

if __name__ == "__main__":
    mcp.run(transport="http", host="0.0.0.0", port=8080)

Das Header-basierte Routing bedeutet, dass Ihr Gateway, Rate-Limiter oder WAF direkt auf Mcp-Method- und Mcp-Name-Headern routen und messen kann — kein JSON-Body-Parsing für Routing-Entscheidungen erforderlich. Dies ist die Deployment-Form, für die das zustandslose Protokoll entwickelt wurde: ein Pool zustandsloser Server-Instanzen hinter einem Round-Robin-Load-Balancer, ohne gemeinsame Session-Schicht.

Schritt 4 — Explizite Handles für zustandsbehaftete Workflows

Zustandslos bedeutet nicht, dass Zustand verschwindet. Die 2026-07-28-Spezifikation ersetzt versteckten Session-Zustand durch das explizite-Handle-Muster: Ein Tool erzeugt ein Handle (eine order_id, eine quote_id, eine basket_id) und das Modell gibt es als gewöhnliches Argument bei nachfolgenden Aufrufen zurück. Dies wird ausführlich in MCP 2026-07-28: Was das zustandslose Protokoll für B2B-Agenten-Deployments bedeutet behandelt.

Für einen Angebots-Workflow, der fünf Tool-Aufrufe umspannt — Anfrage erstellen, Katalog durchsuchen, Angebot erstellen, Verfügbarkeit reservieren, Preisstufe anwenden — fädeln sich die Handles durch jeden Aufruf:

@mcp.tool()
async def create_request(buyer_id: str, line_items: list[dict]) -> str:
    """Create an RFQ request and return a request_id handle."""
    request = await rfq_engine.create(buyer_id, line_items)
    return f"request_id={request.id}"

@mcp.tool()
async def generate_quote(request_id: str, supplier_ids: list[str]) -> str:
    """Generate a quote from specified suppliers. Returns quote_id."""
    quote = await rfq_engine.quote(request_id, supplier_ids)
    return f"quote_id={quote.id}"

Jeder Aufruf trägt das Handle, das er benötigt. Kein Server merkt sich etwas zwischen Aufrufen. Wenn der Load Balancer Aufruf 4 zu einer anderen Instanz weiterleitet als Aufruf 3, funktioniert es immer noch — das Handle ist in der Anfrage. Wenn das Audit-Team diesen Workflow eine Woche später rekonstruieren muss, erzählen die Handles in den Anfrage-Argumenten die vollständige Geschichte.

Schritt 5 — Agent-Identität: die Enterprise-Lücke

Die dritte Priorität des Roadmaps — Agent-Identität und Enterprise-Sicherheit — ist die bedeutendste für B2B-Deployments. Der Roadmap ist explizit: Die MCP-Autorisierung heute ist „um eine Person aufgebaut, die Zugriff in einem Browser genehmigt", aber „immer mehr der Aufrufer sind Agenten, die als Cloud-Workloads mit eigener Identität laufen, im Namen eines Benutzers handeln, der nicht anwesend ist, oder engere Autorität an Sub-Agenten delegieren."

Der Weg nach vorne, wie vom Roadmap definiert:

DPoP (RFC 9449) — Demonstrating Proof of Possession bindet ein OAuth-Token an einen Schlüssel, der vom Client gehalten wird. Ein gestohlenes Token allein kann Anfragen von einem anderen Prozess nicht wiedergeben. DPoP entscheidet nicht, was der Agent tun darf; es macht die Anmeldeinformation schwerer außerhalb ihres vorgesehenen Halters wiederzuverwenden.
Workload Identity Federation — die IETF WIMSE-Arbeitsgruppe entwickelt Architektur für Workload-Identität in Multi-System-Umgebungen. Ein Agent ist ein Workload, also erhält er eine Workload-Identität: benannt mit einer SPIFFE-ID, authentifiziert mit kurzlebigen Anmeldeinformationen, nicht mit einem gemeinsam genutzten API-Schlüssel.
Enterprise-Managed Authorization (EMA) — die EMA-Erweiterung verlagert die Zugriffsentscheidung zum Identitätsanbieter der Organisation. Der MCP-Client tauscht eine Benutzer-Identitäts-Assertion gegen einen Identity Assertion JWT Authorization Grant (ID-JAG) ein und tauscht dann diesen Grant gegen ein server-spezifisches Zugriffstoken. Dies unterstützt zentrale Zuweisung und Widerruf.

Für den Produktionsserver dieses Tutorials ist die Mindestbaseline:

Keine gemeinsam genutzten API-Schlüssel. Jeder Agent erhält ein kurzlebiges, audiencen-gebundenes Token.
OAuth mit DPoP. Der Bericht Practical DevSecOps MCP Security Statistics 2026 fand, dass nur 8,5% der MCP-Server OAuth verwenden — die restlichen 91,5% verlassen sich auf API-Schlüssel oder gar keine Authentifizierung.
Token-Austausch an jeder Vertrauensgrenze. Der CoSAI-Token-Austausch-Standard (veröffentlicht am 18. August) etabliert Token-Austausch als grundlegende Kontrolle für agentische Workflows. Jeder register_tools()-Einstiegspunkt sollte ein aufgabenbezogenes Token akzeptieren, keine persistente Anmeldeinformation.

Siehe die MCP Security Hardening Checklist für die 12 Kontrollen, die diese Standards vor der Produktion verifizieren, und den MCP Module Code Standard für die defensive Haltung auf Modulebene.

Schritt 6 — Progressive Tool-Entdeckung: das Hundert-Tools-Problem lösen

Die vierte Priorität des Roadmaps — verbesserte Primitive — adressiert ein konkretes Produktionsproblem: „Die Verbindung zu einem Server mit hundert Tools bedeutet, dass das Modell für die gesamte Oberfläche bezahlt, bevor der Benutzer eine einzige Frage gestellt hat, und die Tool-Auswahl tendiert dazu, schlechter zu werden, je länger die Liste wird."

Die Antwort des Roadmaps ist progressive Entdeckung: Ein Server bietet einen kleinen Einstiegspunkt und offenbart mehr seines Katalogs, wenn sich die Konversation verengt. Anstatt 100 Tool-Schemata in das Kontextfenster des Modells bei der Verbindung zu laden, exposes der Server eine Handvoll Top-Level-Tools und erweitert die Oberfläche dynamisch basierend darauf, was der Agent tut.

Die 2026-07-28-Spezifikation bietet bereits die Bausteine:

server/discover RPC — ein Client kann die Fähigkeiten eines Servers lernen, bevor es etwas anderes tut, ohne einen Session-Handshake.
tools/list mit ttlMs und cacheScope — Listen-Antworten tragen Cache-Hinweise, sodass Clients Tool-Kataloge cachen und Neu-Abfragen bei jeder Verbindung vermeiden.
_meta bei jeder Anfrage — Protokollversion, Client-Info und Fähigkeiten reisen pro-Anfrage, nicht in einer ausgehandelten Session.

Für einen Server mit 50+ Tools sieht das progressive Entdeckungsmuster so aus:

@mcp.tool()
async def discover_tools(category: str) -> str:
    """Discover available tools in a category. Start here for a guided tour.

    Args:
        category: Tool category — 'catalog', 'pricing', 'inventory', 'orders'
    """
    available = tool_registry.by_category(category)
    return format_tool_list(available)

Der Agent ruft zuerst discover_tools("catalog") auf, erhält einen fokussierten Satz von 5-8 Tools und erweitert nur dann auf andere Kategorien, wenn der Workflow es erfordert. Dies hält das Kontextfenster schlank und die Tool-Auswahl präzise — dasselbe Prinzip hinter dem Single-Responsibility-Tool-Design des MCP Module Code Standard.

Schritt 7 — Deployment: zustandslos, horizontal, hinter einem Load Balancer

Die Deployment-Form, für die die 2026-07-28-Spezifikation entwickelt wurde:

                    ┌──────────────────┐
                    │  Load Balancer   │
                    │  (round-robin)   │
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
     ┌────────┴────┐ ┌───────┴────┐ ┌───────┴────┐
     │ MCP Server  │ │ MCP Server  │ │ MCP Server  │
     │  Instance 1 │ │  Instance 2 │ │  Instance 3 │
     │ (stateless) │ │ (stateless) │ │ (stateless) │
     └─────────────┘ └─────────────┘ └─────────────┘
              │              │              │
              └──────────────┼──────────────┘
                             │
                    ┌────────┴─────────┐
                    │  Upstream Systems │
                    │  (NetSuite, etc.)  │
                    └──────────────────┘

Kein gemeinsamer Session-Store. Kein Sticky-Session-Load-Balancer. Keine Session-Replay-Infrastruktur. Jede Anfrage trägt, was sie braucht — Protokollversion, Client-Info, Fähigkeiten und Handles — im Anfrage-Body und in Headern, nicht im serverseitigen Zustand.

Für die Produktionshärtung:

Sandbox für jede Server-Instanz. Das MCP Project Sandboxing Baseline (veröffentlicht am 16. August) erfordert OS-Level-Sandboxing für gestartete Prozesse. Verwenden Sie Landlock (Linux), Seatbelt (macOS) oder Windows-ACLs, um Dateisystem- und Netzwerkzugriff einzuschränken. Die 82% Path-Traversal-Anfälligkeitsrate (laut Practical DevSecOps) ist der Beweis, dass Eingabevalidierung allein unzureichend ist.
Rate-Limit für jedes Tool. Der MCP Module Code Standard erfordert pro-Tool-Rate-Limits. Die MCP Ruby SDK DoS-Schwachstelle (offengelegt am 16. August) bestätigt, dass Ressourcenerschöpfungsangriffe eine reale Angriffsfläche sind.
Auf OpenTelemetry loggen, nicht auf den MCP-Logging-Kanal. Die 2026-07-28-Spezifikation hat das Logging-Feature deprecated zugunsten von stderr und OpenTelemetry. MCP-Server-Logs integrieren sich in bestehende Observability-Pipelines (Datadog, CloudWatch, Honeycomb) ohne einen benutzerdefinierten Transport.
Header-basiertes Routing für WAF und Rate-Limiting verwenden. Die Mcp-Method- und Mcp-Name-Header ermöglichen Ihrem Gateway das Routen und Autorisieren ohne JSON-Body-Parsing.

Der Roadmap voraus: fünf Prioritätsbereiche

Der Roadmap vom 22. August definiert die Richtung für den nächsten Spezifikationszyklus. Dieses Tutorial behandelt die produktionsbereiten Teile; der Roadmap benennt, was als Nächstes kommt:

Prioritätsbereich	Status	Tutorial-Abdeckung
Agent-Identität und Enterprise-Sicherheit	In Arbeit (DPoP, WIMSE, EMA)	Schritt 5 — Baseline etabliert; vollständige Implementierung ausstehend
HTTP-native Transport-Vereinheitlichung	Verschifft (Remote), in Arbeit (lokal)	Schritt 3 — Remote-HTTP ist Produktion; lokales Streamable HTTP über stdio ist das Roadmap-Ziel
Agentische Messaging-Primitive	Erweiterungen verschifft (Tasks, Subscriptions)	Nicht abgedeckt — server-initiierte Events (Webhooks, Kanäle) sind die nächste Grenze
Verbesserte Primitive (progressive Entdeckung)	Design-Phase	Schritt 6 — das Muster ist heute mit `discover_tools` implementierbar; Spezifikations-Support kommt
Verbesserte SDK-Entwicklererfahrung	Verschifft (SDK v2, Konformitätstests)	Schritt 1 — SDK v2 ist die aktuelle Produktions-Baseline

Der Roadmap ist Richtung, keine Kompatibilitätszusage. Die Juli-28-Spezifikation hat bereits den zustandslosen HTTP-Kern und die Tasks-Erweiterung geliefert. Push-Events, vereinheitlichte Entdeckung, Delegation und Cross-SDK-Konformität benötigen noch Implementierungsarbeit. Für B2B-Deployments ist die Agent-Identitäts-Priorität die zu beobachtende — sie adressiert genau die Lücke (API-Schlüssel und langlebige Tokens), die die MCP-Sicherheitsartikel und die Governance-Checkliste bereits signalisieren.

Der Produktionspfad des Tutorials deckt die Fünf-Schritte-Produktions-Checkliste ab:

Weiterführende Literatur

MCP 2026-07-28: Was das zustandslose Protokoll für B2B-Agenten-Deployments bedeutet — die Begleitanalyse, die das zustandslose Protokoll, das explizite-Handle-Muster und die Deprecations vertieft
MCP Module Code Standard — das strukturelle Muster, das jedes Modul produktionsreif macht: Verzeichnisstruktur, Tool-Registrierung, Fehlerbehandlung, Rate-Limiting und Audit-Logging
MCP Security Hardening Checklist: 1.467 exponierte Server und die Kontrollen, die sie schließen — die 12 Kontrollen, die einen Server vor der Produktion verifizieren und die 82%-Path-Traversal- und 8,5%-OAuth-Lücken adressieren

Bau-Vignette

Ein mittelständischer Distributor, der NetSuite betreibt, wollte seinem Vertriebsteam einen KI-Assistenten geben, der Lieferantenkataloge durchsuchen, Angebote erstellen und Bestandslevel prüfen konnte, ohne das CRM zu verlassen. Der erste Versuch verwendete einen einzigen API-Schlüssel, der über alle Agent-Instanzen geteilt wurde — die 91,5% der MCP-Server, die OAuth überspringen. Eine Aktualisierung der Lieferantenpreisliste legte den Schlüssel in einer Logdatei offen, und das Team verbrachte zwei Tage damit, Anmeldeinformationen über 15 Dienste zu rotieren.

Der Neuaufbau folgte dem Produktionspfad dieses Tutorials: SDK v2 mit typisierten Tool-Schemata, Streamable-HTTP-Transport hinter einem Round-Robin-Load-Balancer, DPoP-gebundene OAuth-Tokens mit 15-Minuten-Gültigkeit, explizite Handles für den fünfstufigen Angebots-Workflow und OS-Level-Sandboxing auf jeder Server-Instanz. Der Agent verbindet sich über ein MCP-Modul gemäß dem Code-Standard mit NetSuite, wobei progressive Entdeckung zuerst 8 Katalog-Tools freigibt und nur dann auf Preise und Bestand erweitert, wenn der Workflow es erfordert. Sechs Server-Instanzen laufen zustandslos hinter dem Load Balancer. Kein gemeinsamer Session-Store. Keine Sticky-Sessions. Jede Anfrage trägt ihr Handle, ihr Token und ihre Protokollversion.

Fordern Sie einen Bau mit festem Scope an

Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Mappe und einen festen Scope — ob Sie mit uns bauen oder nicht.

Möchten Sie dies für Ihre Systeme gebaut?

Jedes Dokument hier stammt aus echter Produktionsarbeit. Wenn Sie ein Zielsystem und einen Workflow im Sinn haben, können wir in einer Woche einen Build umreißen.

Build mit festem Umfang anfragen

Einwöchiges Discovery. Sie erhalten ein Systeminventar, eine Workflow-Mappe und einen festen Umfang — unabhängig davon, ob Sie mit uns bauen.