Was wirklich dazugehört, eine REST-API als MCP-Server in Ruby bereitzustellen — das SDK, ein funktionierendes Tool und der Teil, der entscheidet, ob ein Agent es richtig nutzt.
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.
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.
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.
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.
gem install mcp — community SDKs,
ein Community-Projekt: Für
Ruby gibt es kein SDK unter modelcontextprotocol.
Das wiegt schwerer, als es klingt. Das Protokoll hat sich schnell bewegt, gerade bei Transporten, und eine Portierung, die aufgehört hat, Spezifikationsrevisionen zu folgen, funktioniert mit manchen Clients und scheitert bei anderen still. Prüfe die zuletzt unterstützte Revision, bevor du darauf aufbaust.
Für Ruby gibt es kein unter modelcontextprotocol gepflegtes SDK, die Optionen sind also Community-Gems von unterschiedlicher Vollständigkeit und Aktualität. Prüfe, wann das Gem zuletzt einer Spezifikationsrevision gefolgt ist, bevor du dich darauf festlegst — das Protokoll hat sich schneller bewegt als die meisten Community-Portierungen, besonders bei Transporten.
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 Ruby 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.
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.
Wenn er läuft, bleibt das Problem, dass niemand erkennen kann, was er tut. Ein Interessent kann deinen Ruby-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.