Kostenloses Tool

REST-API zu MCP-Server in Python

Was wirklich dazugehört, eine REST-API als MCP-Server in Python bereitzustellen — das SDK, ein funktionierendes Tool und der Teil, der entscheidet, ob ein Agent es richtig nutzt.

Offizielles SDK modelcontextprotocol/python-sdk (FastMCP)
Installation
pip install mcp
Ein funktionierendes MCP-Tool in Python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def get_order(order_id: str) -> str:
    """Look up one order by its id and return its current status."""
    return fetch_order(order_id)

mcp.run(transport="streamable-http")

Er läuft. Nur sehen kann das sonst niemand.

Ein funktionierender Server ist der Punkt, an dem die Arbeit endet und das Verkaufen beginnt. Richte MCP Showcase darauf und erhalte ein Live-Playground, das deine Kunden ausprobieren können — mit generierter Doku für jedes Tool.

So funktioniert es

link
SDK installieren

Steht oben, zusammen mit der Info, ob es offiziell gepflegt wird oder ein Community-Projekt ist — was in manchen Sprachen mehr zählt als in anderen.

play_circle
Einen Endpunkt kapseln

Fang mit einem einzigen Tool an, nicht mit deiner ganzen API. Tool-Definitionen gehen bei jeder Anfrage ans Modell, und die Treffsicherheit bei der Auswahl sinkt, je länger die Liste wird.

checklist
Testen, bevor du einen Agenten anschließt

Lass die deployte URL durch den MCP Inspector laufen, um zu bestätigen, dass der Handshake klappt und die Tools so erscheinen, wie du es wolltest.

Das SDK für Python

pip install mcpmodelcontextprotocol/python-sdk (FastMCP), offiziell gepflegt.

Decorators verstecken das Schema, und das ist meist genau richtig

FastMCP leitet das Input-Schema eines Tools aus deinen Type-Hints ab und seine Beschreibung aus dem Docstring. Das ist der schnellste Weg zu einem funktionierenden Server und der Grund, warum die meisten MCP-Beispiele in Python sind — es heißt aber auch, dass das, was das Modell liest, dein Docstring ist. Ein vager Docstring ist ein Tool, das der Agent falsch auswählt, und keiner deiner Tests wird das bemerken.

Einen REST-Endpunkt kapseln

Ein MCP-Server ist eine dünne Schicht über Code, den du schon hast. Jedes Tool braucht drei Dinge: einen Namen, eine Beschreibung, die sagt, was es tut und wann man es wählt, und ein Input-Schema. Das SDK für Python kümmert sich um das Protokoll; was du schreibst, ist die Abbildung dieser Argumente auf deinen bestehenden HTTP-Aufruf.

Fang mit einem Endpunkt an statt mit deiner ganzen API. Tool-Definitionen werden bei jeder einzelnen Anfrage erneut ans Modell geschickt, jede ist also dauerhafte Kontextkosten — und die Fähigkeit des Modells, richtig zu wählen, sinkt mit wachsender Liste. Acht gut beschriebene Tools schlagen achtzig.

Der Teil, bei dem es nicht um Python geht

Egal welche Sprache du nutzt: Die Beschreibungen entscheiden, ob sich der Agent vernünftig verhält. Sie werden vom Modell gelesen, nicht von deinen Kollegen, und ein Tool, das in drei Worten beschrieben ist, wird auf Verdacht aufgerufen. Prüfen kannst du deine mit dem MCP-Schema-Linter, und was die Liste pro Anfrage kostet, zeigt dir der Token-Rechner.

Verwandte Tools und Anleitungen

Ein funktionierender Server ist die halbe Miete

Wenn er läuft, bleibt das Problem, dass niemand erkennen kann, was er tut. Ein Interessent kann deinen Python-Quellcode nicht lesen und wird keinen Client installieren, um es herauszufinden. MCP Showcase richtet sich auf dieselbe URL und erzeugt ein Live-Playground mit generierter Doku für jedes Tool — damit die Bewertung deines Servers einen Klick kostet.

Häufig gestellte Fragen

Kapsle jeden Endpunkt, den ein Agent erreichen soll, in ein Tool: ein Name, ein Satz dazu, was es tut und wann man es nutzt, und ein Input-Schema. Das SDK für Python kümmert sich um das Protokoll; was du schreibst, ist die Abbildung von Tool-Argumenten auf deinen bestehenden HTTP-Aufruf.

Nein, und das ist der häufigste Fehler. Tool-Definitionen werden bei jeder einzelnen Anfrage erneut gesendet — achtzig Endpunkte sind also achtzig Beschreibungen im Kontextfenster jeder Runde, und die Fähigkeit des Modells, das richtige zu wählen, fällt mit wachsender Liste deutlich ab. Fang mit den wenigen an, die ein Agent wirklich braucht.

Das Badge über dem Code sagt es dir. Wo es kein offizielles SDK gibt, unterscheiden sich Community-Lösungen darin, wie eng sie der Spezifikation folgen — prüfe, wann die Bibliothek zuletzt einer Protokollrevision gefolgt ist, gerade bei Transporten, bevor du darauf aufbaust.

Streamable HTTP für alles, was deployt ist. Clients versuchen es zunehmend zuerst, und manche fallen nicht mehr auf das ältere HTTP+SSE zurück — was sich nicht als Fehler zeigt, sondern als Client, der deinen Server schlicht nicht sieht.

Beim Lesen des eigenen Codes merkst du es nicht, weil du längst weißt, was die Tools tun. Lass den Server durch den Schema-Linter laufen: Er prüft Beschreibungen und Input-Schemas so, wie ein Modell sie liest, und markiert die, bei denen ein Agent raten müsste.

Weitere kostenlose MCP-Tools