https://renezander.com/de/tags/mcp/Recent content in Mcp on René Zander | KI-AutomatisierungsberaterHugodeTue, 21 Apr 2026 09:00:00 +0200https://renezander.com/de/blog/build-mcp-server-typescript/Tue, 21 Apr 2026 09:00:00 +0200https://renezander.com/de/blog/build-mcp-server-typescript/<p>Die meisten Teams brauchen keinen eigenen MCP Server. Wenn Sie eine LLM-App, eine Integration und eine Codebase haben, ist der direkte Aufruf der Anbieter-API schneller fertig und leichter zu debuggen. Sobald Sie aber zwei Claude-Oberflaechen (Claude Desktop plus Claude Code, oder Claude Code plus Cursor) haben, die auf dasselbe interne System zugreifen, hoeren Sie auf, Tool-Code zu duplizieren. Ab diesem Punkt lohnt es sich, einen MCP Server in TypeScript zu bauen.</p>https://renezander.com/de/guides/mcp-vs-custom-api-integration/Mon, 20 Apr 2026 09:00:00 +0200https://renezander.com/de/guides/mcp-vs-custom-api-integration/<p>Jedes Team, mit dem ich spreche und das eine Claude-Integration ausgeliefert hat, stellt innerhalb eines Monats dieselbe Frage: Sollte dieses Tool ein MCP-Server sein, oder sollte es als Tool-Definition in unserer App bleiben? Die Antwort wird als Technologie-Debatte gerahmt, ist aber in Wahrheit eine Frage danach, an wie vielen Stellen Sie dieselbe Faehigkeit einsetzen wollen.</p> <p>Hier die Kurzfassung. Fuer rund 90 % der Teams ist eine Custom-API-Integration, die direkt in Ihren Claude-Code geschrieben wird, die richtige Wahl. Das Model Context Protocol ist die richtige Wahl, wenn Sie dieselbe Tool-Oberflaeche ueber mehrere LLM-Clients hinweg benoetigen, wenn Sie eine wiederverwendbare interne Plattform bauen oder wenn Sie Tools ausliefern, die andere aus ihren eigenen Assistenten heraus aufrufen sollen. Der Rest dieser Anleitung erklaert das Warum, mit Kostenmodell und einem Entscheidungsbaum am Ende.</p>