Posit hat mit Positron eine neue, kostenlose integrierte Entwicklungsumgebung (IDE) für den Data-Science-Einsatz vorgestellt, die speziell auf moderne Arbeitsabläufe in Python und R ausgelegt ist. Nach mehr als zwei Jahren Entwicklungszeit vereint Positron Exploration, Analyse und Implementierung in einem Tool: Nutzer können ohne Kontextwechsel mit den beiden wichtigsten Data-Science-Programmiersprachen arbeiten.

Kernfunktionen der neuen IDE

Ein zentrales Feature von Positron ist der Variable & Data Frame Explorer. Er erlaubt es Nutzern, Variablen und Dataframes interaktiv zu inspizieren. Sie können Daten filtern sowie sortieren und erhalten statistische Zusammenfassungen direkt im Editor. In der Multi-Session Console lassen sich Python- oder R-Codezeilen und -abschnitte parallel in mehreren Konsolen ausführen, ohne dass Quellcode verändert werden muss. Dadurch kann man verschiedene Teile eines Projekts gleichzeitig testen und weiterentwickeln.

Für das Arbeiten mit interaktiven Dokumenten bietet Positron eine umfassende Notebook-Unterstützung. Nutzer können R- und Python-Notebooks im gleichen Arbeitsbereich verwenden, parallel zu ihren Funktionen, Modulen und Skripten. Die Plot Pane ist für das einfache Verwalten und Analysieren von Grafiken gedacht. Entwickler können frühere Visualisierungen ansehen, deren Größe flexibel anpassen und sie zur weiteren Verwendung exportieren.

Positron unterstützt mit der integrierten Funktion „Run App“ das Starten und Debuggen von Data-Apps und APIs direkt in der IDE, wie Shiny, Streamlit, Dash und FastAPI. Eine nützliche Funktion für den Datenzugriff ist die Database Connection Pane, mit der Nutzer lokale oder externe SQL-Datenquellen direkt über die IDE durchsuchen und abfragen.

Mit dem Push-Button Deployment können Skripte, Berichte, Data-Apps oder APIs mit einem Klick oder über git-basierte Workflows auf Posit Connect bereitgestellt werden. Noch in einer öffentlichen Preview befindet sich die native, generative KI Positron Assistant. Der Assistent versteht den kompletten Kontext der aktuellen Sitzung, inklusive Variablen und Grafiken, und kann Fragen beantworten, Codevorschläge machen und bei der Fehlersuche unterstützen.

Kompatibilität mit VS Code

Ferner bietet Positron eine einfache Verwaltung der IDE durch das Interpreter Management, über das Nutzer schnell zwischen den Python- und R-Umgebungen wechseln, sowie eine breite Unterstützung für VS-Code-kompatible Erweiterungen über den Open-VSX-Marktplatz. Schließlich gibt es noch Projektordner-Vorlagen, mit denen neue Python- oder R-Projekte schnell mit vorbereiteten Umgebungen und notwendigen Tools gestartet werden.

Nutzer von VS Code sollten sich darüber hinaus schnell zurechtfinden: Positron basiert ebenfalls auf Code OSS, also dem freien Projekt hinter Microsofts Editor. Dessen UI-Elemente haben die Entwickler für den Data-Science-Bereich jedoch angepasst. Und wer Posit Workbench für die Zusammenarbeit im Team einsetzt: Sie soll im nächsten Update Positron als IDE-Typ unterstützen.

Positron Desktop ist für Windows, macOS und Linux kostenlos verfügbar. Posit baut mit der neuen IDE auf der langjährigen Erfahrung von RStudio auf. Letzteres ist mit Positron explizit nicht abgekündigt und wird weiterhin Updates erhalten. Zu den Unterschieden hat der Anbieter eine FAQ zusammengestellt. Alle Informationen zu Positron finden sich in der Ankündigung.

(fo)

Das KI-Unternehmen Anthropic, das 2021 von ehemaligen OpenAI-Mitarbeitern gegründet wurde, hat das Model Context Protocol (MCP) mit dem Ziel einer Standardisierung der Kommunikation zwischen Large Language Models und externen Datenquellen entwickelt. Beim sogenannten Tool Calling hat das LLM die Möglichkeit, auf vordefinierte Schnittstellen zuzugreifen. Diese lassen sich parametrisieren und erlauben so große Flexibilität. Die meisten LLM-Anbieter unterstützen dieses Feature. Jede Datenquelle braucht dabei eine Verknüpfung über eine eigene Funktion, was in der Regel eine Anpassung am Programmcode erforderlich macht.

Das Model Context Protocol soll die Verknüpfung externer Datenquellen deutlich vereinfachen und es erlauben, externe Schnittstellen, Datenbanken, Unternehmenssysteme oder Dateisysteme ohne zusätzliche Anpassung direkt anzubinden. Dieser Artikel widmet sich den technischen Details der Funktionsweise des MCP und zeigt anhand eines konkreten Beispiels mit dem MCP-TypeScript-SDK, wie eine Integration in eine Applikation gelingen kann.

Die zentrale Anlaufstelle für Ressourcen zum Thema MCP sind zum einen die offizielle Website des Projekts und zum anderen das GitHub-Repo. Dort stehen die Dokumentation, die Spezifikation und eine ganze Reihe von Software Development Kits (SDKs) für verschiedene Programmiersprachen wie Python, TypeScript, C# oder Kotlin zur Verfügung.

Die Architektur einer MCP-Applikation

Eine Applikation, die das MCP nutzt, besteht aus verschiedenen Komponenten:

• MCP-Server: Der Server ist die Stelle bei MCP, die ihre Funktionalität über das MCP zur Verfügung stellt. Das können Daten aus einer Datenbank, aber auch Suchergebnisse aus dem Internet sein. Die Schnittstellen des Servers sind exakt definiert und lassen sich von der Clientseite verwenden.
• MCP-Client: Die Gegenseite zum Server ist der Client. Er kommuniziert mit dem Server und führt die verfügbaren Operationen über die Schnittstellen aus. Dabei gibt es sowohl lesende als auch schreibende Operationen.
• MCP-Host: Die Applikation, mit der die Benutzer interagieren. Das kann eine Web-Applikation, eine klassische Desktop-Applikation (wie Claude Desktop), eine Entwicklungsumgebung (wie Cursor) oder ein eigener, auf Frameworks wie Langchain basierender Agent sein. In diese Applikation ist der Client eingebettet, sodass der Host nicht direkt über MCP mit dem Server, sondern über den Umweg des Clients kommuniziert.

MCP-Server

Ein MCP-Server kann direkt in eine Applikation integriert, aber auch, und das wird der häufigere Fall sein, ein eigenständiger Dienst sein. Die MCP-Initiative stellt eine Reihe von SDKs in unterschiedlichen Programmiersprachen bereit, die die Grundlage für die Serverimplementierung bilden. Der Server selbst ist modular aufgebaut und erlaubt verschiedene Transportmechanismen, über die er mit den Clients kommuniziert. Das TypeScript-SDK sieht aktuell die Transportmechanismen Streamable HTTP, SSE und stdio vor. Streamable HTTP und SSE basieren auf HTTP, wobei die MCP-Spezifikation vom 26.03.2025 den SSE-Transport als veraltet (deprecated) markierte und die Version vom 18.06.2025 (latest) SSE bereits nicht mehr erwähnt.

Ein MCP-Client kann die HTTP-basierten Transportmechanismen verwenden, um sich mit einem entfernten Server zu verbinden. Der stdio-Transport ist für lokale Anwendungen gedacht. Hierbei verbindet sich der Client über die Standard-Ein- und -Ausgabe mit dem Server. Dieser Weg arbeitet deutlich schneller, ist jedoch nur für die Verwendung auf einem System geeignet. Das Python-SDK definiert zusätzlich zu diesen Transporttypen noch weitere wie den ASGI-Transport (Asynchronous Server Gateway Interface), eine Schnittstelle aus der Python-Welt, die neben der Kommunikation über HTTP noch weitere Protokolle wie WebSockets oder benutzerdefinierte Protokolle unterstützt.

Die MCP-Spezifikation unterteilt die Features, die ein Server seinen Clients bietet, in drei Kategorien: Resources, Tools und Prompts.

Resources

Mit der Feature-Kategorie Resources stellt ein MCP-Server Daten zur Verfügung. Ein typisches Beispiel ist die Anbindung an eine Datenbank. Resources sollten Daten nur lesend zur Verfügung stellen, keine komplexen Berechnungen durchführen und keine Seiteneffekte wie Datenmanipulationen aufweisen. Sie sind parametrisierbar, um die Abfrage zu beeinflussen und eine höhere Flexibilität zu erreichen.

Die MCP-Spezifikation sieht vor, dass das Format [protocol]://[host]/[path] Resources spezifiziert. Ein Beispiel könnte folgendermaßen aussehen: postgres://database/users. Die Antwort auf eine Resources-Anfrage kann entweder im Textformat wie beispielsweise JSON oder als Binärdaten wie PDFs oder Bilder erfolgen.

Der MCP-Server stellt über den Endpunkt resources/list eine Liste der verfügbaren Resources zur Verfügung. Jeder Datensatz weist mindestens die URL der jeweiligen Resource und einen menschenlesbaren Namen auf. Hinzu kommen noch eine optionale Beschreibung und ein ebenfalls optionaler MIME-Type, der das Format der Rückmeldung spezifiziert.

Die Spezifikation sieht nicht nur den lesenden Zugriff auf Ressourcen vor, sondern auch einen Benachrichtigungsmechanismus, über den der Server registrierte Clients über Änderungen der verfügbaren sowie Datenänderungen einer einzelnen Resource benachrichtigen kann.

Tools

Die Features der Kategorie Tools dürfen Berechnungen durchführen und Seiteneffekte aufweisen. Clients müssen berücksichtigen, dass eine Toolausführung im Vergleich zu einer Ressourcenabfrage länger dauern kann. Diese Werkzeuge können Funktionen sein, die aufgrund einer Eingabe eine bestimmte Ausgabe produzieren, aber auch Schnittstellen zu Datenbanken und anderen Systemen, um dort gespeicherte Informationen zu manipulieren. Ähnlich wie Resources können Clients auch die verfügbaren Tools eines Servers über einen Endpunkt auslesen. Dieser lautet tools/list.

Die Beschreibung eines MCP-Tools ist etwas umfangreicher als die einer Resource. Sie enthält einen Namen und ein Input-Schema, um die Parameter des Tools zu beschreiben. Hinzu kommen noch dessen optionale Beschreibung und optionale Metadaten über die Tool-Annotations. Die Annotations liefern Clients beziehungsweise Hinweise für Entwicklerinnen und Entwicklern über das Verhalten eines Tools. Die meisten vordefinierten Annotations der MCP-Spezifikation sind Boolean-Werte. So sagt beispielsweise die readOnlyHint-Annotation aus, dass das Tool sein Umfeld nicht modifiziert. Wie auch bei den Resources kann ein Client sich beim Server registrieren, um über Änderungen benachrichtigt zu werden.

Prompts

Prompts sind Vorlagen, die dem MCP-Host die Arbeit mit dem Large Language Model (LLM) erleichtern. Damit kann eine MCP-Applikation nicht nur die Kommunikation zwischen Client und Server, sondern auch zum LLM hin standardisieren. Bei einer Applikation, die ein Code-Review-Feature anbietet, dient der Prompt beispielsweise dazu, den zu überprüfenden Code korrekt einzubetten. Laut der MCP-Spezifikation besitzen die Prompt-Templates einen eindeutigen Namen. Zusätzlich sieht die Spezifikation noch die optionalen Felder description für eine menschenlesbare Beschreibung und arguments mit einer Liste der unterstützten Argumente des Schemas vor.

Die Prompt-Endpunkte eines MCP-Servers kommen ähnlich wie Tools zum Einsatz. Der Client fragt nach dem eindeutigen Identifier und übermittelt die benötigten Werte. Der Server antwortet mit dem Prompt, in den die Werte integriert sind, sodass der Client beziehungsweise die Host-Applikation den Prompt direkt verwenden kann.Für eine Liste aller verfügbaren Prompts bietet der MCP-Server den Endpunkt prompts/list an.

Die SDKs, die die MCP-Initiative zur Verfügung stellt, implementieren die Spezifikation und dienen als Grundlage für die Implementierung von MCP-Servern und MCP-Clients. Das folgende Beispiel implementiert einen einfachen MCP-Server mit je einer Resource, einem Tool und einem Prompt mit dem TypeScript-SDK.

import {
  McpServer,
  ResourceTemplate,
} from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

const server = new McpServer({
  name: 'mcp-server',
  version: '1.0.0',
});

server.tool(
  'currency-converter',
  'Convert currency between EUR and USD',
  {
    amount: z.number(),
    from: z.enum(['EUR', 'USD']),
    to: z.enum(['EUR', 'USD']),
  },
  async ({ amount, from, to }) => {
    const exchangeRate =
      from === 'EUR' && to === 'USD'
        ? 1.1
        : from === 'USD' && to === 'EUR'
        ? 0.91
        : 1;
    const convertedAmount = amount * exchangeRate;
    return {
      content: [
        {
          type: 'text',
          text: `${amount} ${from} is ${convertedAmount.toFixed(2)} ${to}`,
        },
      ],
    };
  }
);

server.resource(
  'price-list',
  new ResourceTemplate('price-list://products/{category}', {
    list: undefined,
  }),
  async (uri, { category }) => {
    const priceList = [
      { name: 'Apple', category: 'Fruit', price: 1.2 },
      { name: 'Banana', category: 'Fruit', price: 0.8 },
      { name: 'Carrot', category: 'Vegetable', price: 0.5 },
      { name: 'Bread', category: 'Bakery', price: 2.5 },
      { name: 'Milk', category: 'Dairy', price: 1.5 },
    ];

    const filteredList =
      category !== 'all'
        ? priceList.filter(
            (item) => item.category.toLowerCase() === category.toLowerCase()
          )
        : priceList;

    return {
      contents: [
        {
          uri: uri.href,
          text: JSON.stringify(filteredList),
          json: filteredList,
        },
      ],
    };
  }
);

server.prompt(
  'get-product-description-prompt',
  {
    productName: z.string().describe('The name of the product.'),
    length: z
      .enum(['short', 'medium', 'long'])
      .optional()
      .describe('The desired length of the description.'),
  },
  async (input) => {
    const { productName, length } = input;

    let promptInstructions = `Please generate a compelling product description.`;

    let promptCore = `The product is named "${productName}". `;
    promptCore += `Focus on its general benefits and appeal. `;

    let refinements = '';

    if (length) {
      let lengthGuidance = '';
      if (length === 'short')
        lengthGuidance = 'Keep it concise, around 1-2 sentences. ';
      if (length === 'medium')
        lengthGuidance = 'Aim for a paragraph of about 3-5 sentences. ';
      if (length === 'long')
        lengthGuidance =
          'Provide a detailed description, potentially multiple paragraphs. ';
      refinements += lengthGuidance;
    }

    const fullPrompt = `${promptInstructions}\n\nProduct Details:\n${promptCore}\n\nStyle and Constraints:\n${refinements.trim()}`;

    return {
      messages: [
        {
          role: 'user',
          content: {
            type: 'text',
            text: fullPrompt,
          },
        },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Listing 1: MCP-Serverimplementierung

Die Grundlage für das Beispiel bildet das TypeScript-SDK, das mit dem Kommando npm install @modelcontextprotocol/sdk installiert wird. Das Paket stellt mit der McpServer-Klasse die Grundlage für die Serverimplementierung zur Verfügung. Auf der Server-Instanz sind die Methoden tool, resource und prompt implementiert, die die Schnittstelle zur Registrierung der verschiedenen MCP-Features darstellen. Nachdem die Applikation alle Features registriert hat, ruft sie die connect-Methode der Serverinstanz auf und übergibt ein Transport-Objekt. Das kann wie im Beispiel eine Instanz der StdioServerTransport-Klasse für den Stdio-Transport sein oder auch eine Instanz der StreamableHTTPServerTransport-Klasse für eine Remote-Schnittstelle über Streamable-HTTP. Alternativ dazu unterstützt das TypeScript-SDK auch noch die SSEServerTransport-Klasse für Server Sent Events als Transportmethode.

Für die Implementierung der einzelnen Features des MCP-Servers gelten einige Regeln, die das SDK mit einer sehr strikten Schemavalidierung absichert. Folgt die Implementierung nicht diesen Regeln, lässt sich der Serverprozess nicht starten. Die Validierung stellt auch die Konsistenz der Argumente beim Aufruf sicher und spielt damit eine wichtige Rolle bei der Sicherheit in der Applikation.

Resource im Beispiel

Zur Definition von Resources sieht das SDK die resource-Methode des Serverobjekts vor. Diese Methode akzeptiert die Bezeichnung der Resource, die zugehörige URL und eine Callback-Funktion, die das Ergebnis produziert. Die Callback-Funktion darf asynchron sein, sodass auch der Anbindung einer Datenbank nichts im Wege steht. Eine Besonderheit gibt es bei der Registrierung von Resources allerdings: Ist die URL als Zeichenkette angegeben, darf sie keine dynamischen Parameter enthalten. Für diesen Fall akzeptiert die resource-Methode eine ResourceTemplate-Instanz. Hier werden die Parameter im Pfad mit geschweiften Klammern gekennzeichnet. Die Callback-Funktion kann über ihr zweites Argument auf die Parameter der URL zugreifen und das Ergebnis entsprechend modifizieren.

Im Beispiel ist die Resource eine statische Preisliste für eine Reihe von Produkten. Sie trägt die Bezeichnung price-list und ist über die URL price-list://products/{category} erreichbar, wobei category für eine Kategorie steht, nach der die Callback-Funktion die Datensätze filtert. Das TypeScript-SDK arbeitet mit Zod als Validierungsbibliothek und nutzt diese beispielsweise für die Überprüfung des Rückgabewerts der Resource-Callback-Funktion, sodass diese verpflichtend eine gewisse Struktur zurückgeben muss. Das contents-Array im Rückgabewert kann eine Reihe von Objekten aufweisen, die mindestens über die Eigenschaften uri und text verfügen müssen. Zusätzlich akzeptiert das SDK noch weitere Eigenschaften wie json, in der die Daten als JSON-Objekt vorliegen dürfen.

Die Betreiber des Python Package Index (PyPI) gehen gegen Domain-Hijacking vor, um Lieferkettenangriffe zu erschweren. Dabei prüft das beliebte Python-Paketverzeichnis die Domains von Mail-Adressen der User-Accounts regelmäßig darauf, ob die Domänen noch einen Besitzer haben. Wenn nicht, wird dem Account die Verifizierung entzogen, was bereits über 1800 Mal der Fall war.

Mit diesem Verfahren verhindert PyPI, dass Angreifer eine aufgegebene Domain übernehmen, die E-Mail-Adresse des vorherigen Nutzers einrichten, bei PyPI das Passwort des mit der Mail-Adresse verbundenen Accounts zurücksetzen und sich einloggen. Dann haben sie Zugriff auf die dort veröffentlichten Python-Pakete und können Schadcode in diese einbauen, den andere Nutzer unbedarft installieren. Als Beispiel für einen derartigen Lieferkettenangriff nennt der Python-Blog das Hijacking des ctx-Pakets 2022, das andere User 27.000 Mal heruntergeladen haben.

Für die Prüfung nutzt PyPI die Karenzzeit von dreißig Tagen, in die Domains nach der Löschung gehen: die Redemption Grace Period (RGP). Dieser Status ist öffentlich gekennzeichnet, was PyPI nun täglich checkt und den betroffenen Mail-Adressen die Verifikation entzieht. Das bedeutet, dass Nutzer nicht einfach ein Passwort zurücksetzen können, sondern zusätzliche Belege vorlegen müssen, beispielsweise einen zweiten Faktor – wenn eingerichtet – oder eine Mitgliedschaft in anderen, nicht näher spezifizierten Diensten („via other services under the user’s control“).

In der Ankündigung schreibt PyPI, dass bei der initialen Prüfung im Juni 1500 Adressen die Verifikation verloren haben. Ausdrücklich nicht betroffen sind Domains, die regulär den Besitzer wechseln und nicht in eine Karenzzeit gehen.

PyPI empfiehlt allen Anwenderinnen und Anwendern, prinzipiell einen zweiten Faktor für den Login einzurichten und eine weitere Mail-Adresse von einer „glaubwürdigen Domain (zum Beispiel Gmail)“ anzugeben.

(who)