lm-studio mcp local-llm research-agent tool-calling

Erstellung eines lokalen Forschungs-Agenten in LM Studio mit vier MCP-Servern

Ein lokaler Forschungsagent in LM Studio mit vier MCP-Servern: Dateisystem, GitHub, SearXNG und Camofox, einem reduzierten Tool-Schema, einem Plan-Prompt sowie einer Grounding-Demo.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202614 Min. Lesezeit3208 Wörter

Quellen: How to Turn LM Studio Into a Local Research Agent With MCP Servers

Ein lokales Modell, das suchen, eine Datei lesen oder einen Pull Request öffnen kann, ist nützlich. Ein lokales Modell, das all diese Funktionen in einer einzigen Denksequenz miteinander verknüpfen kann, um eine einzige Frage zu beantworten, fungiert als Forschungsassistent. Um im LM Studio vom ersten zum zweiten Stadium zu gelangen, sind vier MCP-Server erforderlich, die nebeneinander arbeiten, ein Konzept, um zu verhindern, dass ihre kombinierten Tool-Schemata das Kontextfenster überlasten, sowie eine Anregung, die ein 9B-Modell dazu bringt, mehrstufige Aufgaben durchzuführen, anstatt nur ein Tool aufzurufen und dann aufzuhören.

Die vier Server sind ein Dateisystemserver, ein GitHub-Server, eine selbst gehostete SearXNG-Instanz für Suchfunktionen sowie ein auf Camoufox basierender Browser (Camofox) zum Lesen der von der Suche angezeigten Seiten. Der Dateisystemserver ist @modelcontextprotocol/server-filesystem und auf einen bestimmten Verzeichnisbereich beschränkt. Auf GitHub wird über OAuth unter api.githubcopilot.com/mcp/ zugegriffen. SearXNG und Camofox laufen in Docker und verbinden sich über mcp-searxng sowie camofox-mcp. Jeder Server arbeitet unabhängig. Interessant ist, was passiert, wenn ein einziger Chat alle diese Komponenten beinhaltet.

Eine Warnung bezüglich der Vorbereitung vor der Verkabelung: Alles hier dient der gewöhnlichen Online-Forschung, wie beispielsweise Wettbewerbsanalyse, Due-Diligence bei Lieferanten oder Überprüfung von Aussagen in Artikeln. Der Agent hat keine Ahnung, was erforscht wird, und es ist ihm auch egal. Er sucht, lädt und liest einfach alles, worauf er gerichtet wird.

Die Einrichtung gliedert sich in vier Schritte: Kombination der Server, Reduzierung der Tool-Liste, Bereitstellung eines Plans für das Modell sowie Durchführung einer Demonstration zur Grundierung.

Schritt 1: Alle vier Server in einem Chat

LM Studio beschränkt nicht, wie viele MCP-Server ein Chat verwenden kann. Es lädt alle herunter und übermittelt dem Modell das jeweilige Tool-Schema von jedem Server. Das ist der Reiz dieser Einrichtung – und wie der nächste Schritt zeigt, auch das Erste, was zu Problemen führt.

Die Dateisysteme sowie die GitHub-Einträge sind so konfiguriert, wie es für eine eigenständige Einrichtung der Fall wäre, genauso wie die Einträge für SearXNG und Camofox. Die zugrunde liegenden Container müssen bereits laufen, wobei ihre docker-compose.yml- und searxng/settings.yml-Dateien vorhanden sein müssen, da diese hier nicht erneut angelegt werden. Was sich ändert, ist, dass alle vier Einträge nun in einer einzigen mcp.json gespeichert sind:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/jes/research-workspace"
      ]
    },
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "auth": {
        "CLIENT_ID": "<your Client ID>",
        "CLIENT_SECRET": "<your client secret>"
      }
    },
    "searxng": {
      "command": "npx",
      "args": ["-y", "mcp-searxng"],
      "env": {
        "SEARXNG_URL": "http://localhost:8080"
      }
    },
    "camofox": {
      "command": "npx",
      "args": ["-y", "camofox-mcp"],
      "env": {
        "CAMOFOX_URL": "http://localhost:8765",
        "CAMOFOX_API_KEY": "your-camofox-api-key",
        "CAMOFOX_AUTH_MODE": "api_key"
      }
    }
  }
}

Drei Details verdienen Aufmerksamkeit.

Der github-Eintrag löst seinen eigenen OAuth-Schritt aus. LM Studio fordert diesen zum ersten Mal an, wenn der Server versucht, etwas zu laden. Da GitHubs Endpunkt keine dynamische Client-Registrierung unterstützt, wird ein vorher manuell zu registrierendes GitHub OAuth-App verwendet. Es gibt keinen Umweg darum herum.
Der zulässige Verzeichnisort für den Dateisystemserver ist eine willkürliche Wahl. Ein spezielles research-workspace-Verzeichnis funktioniert besser als das Heimverzeichnis, vor allem weil dadurch klar wird, worauf das Modell Zugriff hat.
CAMOFOX_URL und SEARXNG_URL müssen auf die Docker-Container verweisen. Wenn diese nicht laufen, laden sich die Server dennoch in LM Studio, doch jeder Aufruf der Tools gegen sie fehlschlägt, was beim ersten Mal zu verwirrenden zwanzig Minuten führt.

Sobald alle vier Funktionen aktiviert sind und die kleinen grünen Punkte neben jedem Servernamen im MCP-Panel vollständig sichtbar werden, verfügt der Chat über vier Dateisystem-Tools, Dutzende GitHub-Tools, vier SearXNG-Tools sowie etwa vierundvierzig Camofox-Tools. Das bedeutet eine enorme Menge an Informationen, über die ein 9B-Modell nachdenken muss – und genau dieses Problem soll in der nächsten Phase gelöst werden.

Phase 2: Aufrechterhaltung des Kontextbudgets

Bereits die Anzahl der GitHub-Tools allein stellt ein Risiko dar, genauso wie die von Camofox. In Kombination mit SearXNG-Tools und Dateisystem-Tools wird die Belastung noch erheblich.

Der Name, die Beschreibung sowie das Parameterschema jedes Tools werden bereits vor dem Lesen des eigentlichen Fragentextes in Tokens aufgeteilt und in den Kontext des Modells eingefügt. Bei einem kleinen Modell mit begrenztem Kontextvolumen kann dieser Aufwand einen erheblichen Teil der verfügbaren Ressourcen in Anspruch nehmen.

Die direkteste Lösung besteht einfach darin, nicht jede Funktion von jedem Server zu aktivieren. Für GitHub gibt es eine bessere Methode als das manuelle Ein- und Ausschalten von Funktionen im MCP-Panel. Der Remote-Server akzeptiert ein X-MCP-Readonly-Header, der die gesamte Verbindung auf nur lesbare Funktionen beschränkt, bevor LM Studio den Rest des Schemas sieht. Dadurch wird der github-Eintrag aus dem vorherigen Schritt wie folgt:

{
  "github": {
    "url": "https://api.githubcopilot.com/mcp/",
    "auth": {
        "CLIENT_ID": "<your Client ID>",
        "CLIENT_SECRET": "<your client secret>"
     },
    "headers": {
      "X-MCP-Readonly": "true"
    }
  }
}

Wenn der Header aktiviert ist, listet der Server nur Lesewerkzeuge auf: pull_request_read, issue_read, list_commits, get_file_contents, search_repositories und search_code. Alle Funktionen, die löschen, zusammenführen, hochladen oder erstellen können, fehlen einfach. Die Beschränkung wird auf der Seite von GitHub durchgesetzt, nicht dadurch, dass LM Studio einen Button versteckt, sodass es sich um eine echte Einschränkung handelt. Dadurch werden auch die Schemata für die deaktivierten Schreibwerkzeuge niemals in den Kontext eingebunden, was genau der Zweck dieser Phase ist.

Wer etwas Engeres wünscht, kann X-MCP-Tools verwenden, das eine explizite, mit Kommas getrennte Erlaubungsliste akzeptiert, beispielsweise search_code,search_repositories,get_file_contents,list_commits. Das eignet sich für Fälle, in denen die Werkzeuge für Issues und Pull Requests offensichtlich niemals benötigt werden.

Ein Screenshot des GitHub MCP in diesem Zustand würde nur die Tools „get“, „read“, „list“, „scan“ und „search“ anzeigen, da die „read-only“-Flagge auf „true“ gesetzt war, wobei die Möglichkeit besteht, weitere nicht benötigte Tools auszuschalten, um die Tokenkosten zu senken.

Camofox verfügt über keine entsprechende Server-seitige Flagge, weshalb seine Tools nacheinander im MCP-Panel deaktiviert werden. Für ein rein für Forschungszwecke genutztes Chat-Interface sind die zu deaktivierenden Optionen delete_download, import_cookies sowie alles, was Profile verarbeitet, darunter save_profile und load_profile, da eine Forschungssitzung keinen Grund hat, gespeicherte Browserprofile zu bearbeiten.

Das Prinzip besteht darin, nur das zu beibehalten, was für den jeweiligen Anwendungsfall erforderlich ist, und den Rest zu deaktivieren. Bei den meisten Servern handelt es sich dabei um eine Entscheidung hinsichtlich des Kontextbudgets und nicht um eine Sicherheitsmaßnahme. Der GitHub-Header ist die Ausnahme, da GitHubs eigener Server diese Regel durchsetzt.

Die Demo in Phase 4 benötigt niemals Schreibzugriff auf GitHub, da die einzige GitHub-Aktion darin besteht, ein Manifest zu lesen – dadurch kann die nur-Lese-Beschränkung weiterhin in Kraft bleiben. Falls eine spätere Aufgabe tatsächlich Schreibzugriff erfordert, beispielsweise um ein Issue zu erstellen, in dem aufgezeichnet wird, was der Agent gefunden hat, sollte der Header für dieses Chat-Fenster entfernt werden. Die Kombination von nur-Lese- und schreibfähigen GitHub-Verbindungen in einer Sitzung ist nicht die richtige Vorgehensweise.

Auch das Kontextfenster selbst erfordert Aufmerksamkeit. Eine Mindestgröße von 4096 Token war sinnvoll, als das verfügbare Schema von einem einzigen Server stammte. Mit vier Servern sowie einer reduzierten, aber dennoch umfangreichen Liste an Werkzeugen ist 4096 zu klein. Verschieben Sie den Regler deutlich nach oben, möglicherweise über 32k hinaus, je nachdem, was das Modell und die Hardware bewältigen können und wie lange der Austausch andauern soll. Es gibt keine einzige richtige Zahl – es handelt sich um ein Abwägen zwischen Rechenkapazität und verfügbarer VRAM. Achten Sie daher auf den Prozentsatz der Kontextfüllung, den LM Studio unter dem Chat-Eingabefeld anzeigt, und passen Sie entsprechend an.

Phase 3: Ein Plan, dem das Modell folgen kann

Ein handgeschriebener Agent hat einen Vorteil, den die Chat-Oberfläche von LM Studio nicht automatisch bietet. In einem Skript steht der Systemprompt als Python-String voll unter Kontrolle, und man kann den Ablauf explizit beschreiben: Suchen, eine Quelle auswählen, sie abrufen und anschließend entscheiden, ob dies die Frage beantwortet oder ob eine weitere Suche erforderlich ist.

Es ist besser, klarzustellen, was LM Studio tatsächlich anbietet, anstatt anzudeuten, es gäbe eine versteckte Planungsoption. Solche gibt es nicht – es existiert keine separate Planungseinstellung.

Es gibt lediglich ein Feld für den Systemprompt in der Chat-Seitenleiste unter „Modellparameter“. Diesen Prompt kann man zusammen mit den Einstellungen für Temperatur und Kontext als benannten Voreinstellung speichern, sodass er bei jeder Sitzung nicht neu eingegeben werden muss. Das ist derselbe Mechanismus, den ein handgeschriebener Agent verwendet – nur als Textfeld und nicht als String im Code.

Ein Systemprompt in dieser Form eignet sich für einen Forschungszweck im Chat:

You are a research assistant with tools for web search, page fetching,
file storage, and GitHub. When asked a factual question you cannot
answer with confidence from memory, follow this plan:

1. Search for the topic using searxng_web_search. Look at more than one
result before deciding a source is good.

2. Fetch the most promising source with camofox's navigate and
 snapshot or extract_structured tools, not just the search snippet.
When using camofox always open a new tab before trying to navigate
to a page.

3. If the question needs more than one source to answer confidently,
search again and fetch again before answering.

4. If asked to save findings, write them to a markdown file in the
 workspace using the filesystem tools, don't just describe them in chat.

5. State which sources you actually fetched, not just which ones you
found in search results.

Einige Hinweise zu seinem Verhalten:

Es handelt sich um reine Prosa, ohne dass eine Zustandsmaschine sie durchsetzt. Die Anweisungen sind das, was das Modell sieht, und es folgt im Allgemeinen ihrem Aufbau – ohne Garantie, genauso wie bei einem Systemprompt innerhalb eines Skripts.
Schritt 5 ist wichtiger, als es scheint. Ohne ihn neigt das Modell dazu, allein auf den Suchauszug zu antworten und den Abrufschritt zu überspringen, was den Sinn dahinter verfehlt, Camofox in den Ablauf einzubeziehen.
Das Speichern des Ergebnisses als Vorlage ermöglicht es, es über verschiedene Chats hinweg zu verwenden, ohne es erneut einfügen zu müssen.

Auf dem Screenshot befindet sich der Prompt unter „Model Parameters“ und die Vorlage ist als „Research Chat“ gespeichert. Mit dem Prompt sowie der angepassten Liste der Tools verfügt das Modell über die notwendigen Möglichkeiten sowie eine Art Plan, wie es diese nutzen kann. Die letzte Frage ist, ob es dies tatsächlich tut.

Phase 4: Eine Demonstration, die nachweist, dass die Tools verwendet wurden

Ein guter Grundlagen-Test muss die tatsächliche Nutzung eines Tools erzwingen. Ein selbstbewusstes Auswendiglernen kann keine richtige Antwort liefern, weshalb das Modell entweder eine echte Quelle abruft oder ratet. Die Aufgabe sollte etwas sein, was es nicht auswendig gelernt haben kann, unabhängig überprüfbar sein und weitgehend allgemein genug, um nicht auf eine bestimmte Person bezogen zu sein.

Ein passender Fall: Weisen Sie den Agenten auf ein Repository hin, das gepflegt oder genutzt wird, und lassen Sie ihn die festgelegte Version einer Abhängigkeit bis zu allen gegen genau diese Version eingereichten Sicherheitshinweisen verfolgen. Den untenstehenden Prompt kann man nach dem Ausfüllen von drei Platzhaltern in das Chat-Fenster kopieren:

I want you to check one dependency in a GitHub repository for known
security advisories. Do this:

1. In the repository <owner>/<repo>, read <manifest-file> using
   get_file_contents.
2. From that file, find the exact pinned version of the dependency
   "<dependency-name>".
3. Search the web for known security advisories filed against that
   specific version of "<dependency-name>".
4. Fetch the actual advisory page(s) you find rather than relying on
   the search snippet alone.
5. Write a short summary to dependency-risk.md in the workspace: the
   dependency name, the pinned version, any advisories found (with
   severity and a link), and a one-line recommendation.

Die Platzhalter funktionieren wie folgt:

<owner>/<repo> bezeichnet jedes Repository mit Lesezugriff. Ein persönliches Projekt eignet sich genauso gut wie ein öffentliches, das zufällig als Abhängigkeit verwendet wird.
<manifest-file> gibt den Namen der Abhängigkeitsdatei an, auf die sich das Projekt stützt – beispielsweise go.mod, pyproject.toml, requirements.txt oder package.json.
<dependency-name> ist eine einzelne Abhängigkeit aus diesem Manifest, idealerweise eine, die tatsächlich von Interesse ist.

Falls kein geeigneter Repository wie juice-shop/juice-shop zur Verfügung steht, kann die absichtlich unsichere Schulungsanwendung von OWASP als Ersatz dienen. Sein package.json enthält bereits genügend zuvor als problematisch markierte Abhängigkeiten, sodass die Suche in der Regel zu einem relevanten Ergebnis führt. express-jwt und sanitize-html sind beide sinnvolle Ausgangspunkte. Eine vollständige Version sieht so aus:

I want you to check one dependency in a GitHub repository for known
security advisories. Do this:

1. In the repository juice-shop/juice-shop, read package.json using
get_file_contents.
2. From that file, find the exact pinned version of the dependency
"express-jwt".
3. Search the web for known security advisories filed against that
specific version of "express-jwt".
4. Fetch the actual advisory page(s) you find rather than relying
on the search snippet alone.
5. Write a short summary to dependency-risk.md in the workspace:
the dependency name, the pinned version,
any advisories found (with severity and a link),
and a one-line recommendation.

Durch den Versand sollte der Agent die fünf Schritte in der richtigen Reihenfolge durchlaufen: ein Lesen von GitHub, eine externe Suche, ein externer Abruf und schließlich eine Dateienschreibung – in dem von der Hardware ermöglichten Tempo.

Ein vollständiger Ausführungsversuch dieses Prompts nutzte alle vier MCP-Server und verbrauchte insgesamt 37803 Tokens.

Dieser Prompt wurde absichtlich ausgewählt. Die Antwort hängt vom Repository sowie davon ab, was darin als „pinned“ markiert ist, und die von den Suchen abgerufenen CVE-Datenbanken werden ständig aktualisiert, sodass kein festes Ergebnis im Voraus angegeben werden kann.

Die Überprüfung der Funktionsfähigkeit des Modells umfasst zwei Schritte. Öffnen Sie das Manifest und lesen Sie die darin angegebene Version persönlich, um zu überprüfen, was von GitHub zurückgegeben wurde. Anschließend prüfen Sie die Angaben zum Sicherheitshinweis entweder in GitHubs eigenen Suchfunktion für Sicherheitshinweise oder im NVD. Wenn beide Quellen mit dem Bericht des Agents übereinstimmen, handelt es sich um echten Nachweis: Das Modell hat tatsächlich das Manifest gelesen und eine entsprechende Sicherheitshinweise-Seite abgerufen, anstatt aufgrund vager Erinnerungen zu antworten, dass eine bestimmte Bibliothek einmal einen CVE hatte.

Die Demo zeigt außerdem, dass der nur zum Lesen bestimmte Header der Stufe 2 ausreicht. Der gesamte Ablauf beinhaltet lediglich Lesevorgänge bei GitHub, eine Suche außerhalb von GitHub, ein Abrufen von Inhalten sowie eine lokale Dateispeicherung – daher ist kein Schreibzugriff auf GitHub erforderlich, und der Header kann beibehalten werden. Eine einzige Anfrage nutzt alle vier Server in einem Durchgang: GitHub liest das Manifest, SearXNG sucht nach Warnhinweisen, Camofox holt die entsprechenden Seiten herunter und das Dateisystem speichert die Zusammenfassung. Dadurch lässt sich schnell überprüfen, ob die gesamte Einrichtung korrekt konfiguriert ist, bevor mit echten Forschungsarbeiten begonnen wird.

Wo es versagt

Es ist besser, die Schwachstellen zu benennen, anstatt so zu tun, als wäre die Kette von Anfang bis Ende zuverlässig.

Manchmal antwortet das Modell auf Grundlage des Suchausschnitts und überspringt das Abrufen der Seite, selbst wenn die Systemanweisung etwas anderes vorschreibt. Dies tritt häufiger bei kurzen, einfach aussehenden Fragen auf, bei denen das Modell den Ausschnitt für gut genug hält. Eine nachfolgende Nachricht, die es anweist, die Seite abzurufen, behebt in der Regel das Problem. Es liegt nicht daran, dass das Modell es nicht kann, sondern daran, dass ein 9B-Modell bei einigen dieser Beurteilungen falsch liegt.

Gelegentlich wählt das Modell angesichts von Dutzenden von GitHub-Tools, die es noch nie verwendet hat, ein plausibles, aber falsches Tool aus – beispielsweise list_pull_requests, obwohl eigentlich list_issues gemeint war. Die in Phase 2 durchgeführte Filterung ist der beste Schutz. Ein kürzeres Menü mit ähnlichen Optionen verringert die Chancen, das falsche Tool auszuwählen.

Keines davon macht den Agenten zu einem deterministischen Pipeline-System. Wo Determinismus erforderlich ist, ist ein Skript das richtige Werkzeug, und eine manuell kodierte Schleife kommt diesem am nächsten. Der Vorteil dabei, die Komponenten in LM Studio zu integrieren, besteht darin, dass das Modell sich an jede gestellte Frage anpasst – der Preis dafür ist jedoch, dass es manchmal schlecht anpasst. Zu beobachten, wie es mit einigen Forschungsfragen umgeht, ist der schnellste Weg, herauszufinden, wem man vertrauen kann und wo es Unterstützung benötigt.

Die fertige Einrichtung

Die vier Phasen führen dazu, dass ein einzelnes LM Studio-Chat-Interface vier MCP-Server betreibt. Die Liste der verfügbaren Tools wurde reduziert, damit im Kontext noch Platz für das Nachdenken bleibt. Ein Systemprompt gibt dem 9B-Modell eine zu befolgende Struktur, wo zuvor nur eine leere Seite vorhanden war, und eine Demonstration zeigt, dass tatsächliche Seiten abgerufen werden und nicht Antworten aus dem Gedächtnis geholt werden. Konkret ausgedrückt:

Filesystem, GitHub, SearXNG und Camofox sind alle in einem einzigen Chat verfügbar.
Ein reduziertes Set an Tools sowie ein Kontextfenster, das groß genug für das kombinierte Schema ist, anstatt der Einschränkung durch einen einzigen Server.
Ein Systemprompt, der als Vorlage gespeichert wird; dadurch plant das Modell selbstständig einen Such-, Abruf- und Speicherzyklus, wobei tatsächlich nur die von LM Studio’s UI bereitgestellten Funktionen genutzt werden und keine nicht existierenden Konfigurationsoptionen.
Eine wiederholbare Demonstration zur Grundlegung, bei der jeder Teil unabhängig überprüft werden kann und bei der alle vier Server in einem einzigen Prompt angesprochen werden.

Es gibt Raum, es zu erweitern. Ein zweiter Such-Backend neben SearXNG würde es ermöglichen, die Ergebnisse gegeneinander zu überprüfen. Eine Zusammenfassung nach jeder Abfrage würde verhindern, dass lange Seiten zu viel Kontext beim Laden verbrauchen. Für diejenigen, die dies regelmäßig tun, würde das Scripten der Vorlagen die Erstellung jedes neuen Forschungs-Chats mit der richtigen Konfiguration ermöglichen, ohne manuelles Umstellen.

Eine Schlussfolgerung kommt immer wieder zum Vorschein: Nachdem man die Rohkomponenten – also Dateisystem, Suchfunktion, Browsen und Code-Host – manuell miteinander verbunden hat und beobachtet hat, wo jeweils Probleme auftreten, zeigt sich, dass ein komplexeres Agentenframework im Grunde genommen aus denselben Bestandteilen besteht, nur hinter zusätzlicher Abstraktion versteckt. Diesen Kompromiss zu akzeptieren, macht nur Sinn für jemanden, der bereits versteht, was darunterliegt.