Wie Plattform-Teams GroupDocs.Parser verwenden, um Dokumentwerkzeuge in MCP-Clients auf .NET zu integrieren

💡 Voll funktionsfähiges Beispiel auf GitHub verfügbar: parser-mcp-document-tools-dotnet

Die Plattform-Herausforderung: Warum Dokumentwerkzeuge an MCP-Grenzen stocken

Docker-gestützte Dokumentwerkzeuge für MCP-Clients sind ein GroupDocs.Parser.Mcp-Bereitstellungsmuster auf .NET, das ein Container-Image mit Offline-Bibliotheksprüfungen für get_document_info, extract_text und extract_tables kombiniert. Plattform‑Engineering‑Gruppen, die Dokumentwerkzeuge für Assistenten bereitstellen, kämpfen selten mit „können wir ein DOCX parsen?“. Sie kämpfen mit einer schärferen Grenze: Der MCP-Server muss in den Client-Konfigurationen als benannte Werkzeugliste erscheinen, während die Parsing-Engine so groß ist, dass GroupDocs.Parser.Mcp nur als Container-Image und nicht als NuGet-Paket ausgeliefert wird.

Wenn ein Produktteam Dokumentinformationen, Klartext und chat‑fertige Tabellen in einem MCP-Client anfordert, erbt das Plattform‑Team zwei Pfade. Pfad 1 ist Betrieb: docker run mit einem Volume unter /data, festgelegte Tags wie :26.9.0 und ein stabiler mcpServers‑Eintrag. Pfad 2 ist Verifikation: Nachweisen, dass GroupDocs.Parser für .NET dieselben Fakten liefert, die diese Werkzeuge zurückgeben würden, bevor jemand von einem Live‑Handshake abhängt. Verpasst man einen der Pfade, erscheinen Fehler als leere MCP‑Client‑Antworten statt als fehlgeschlagener Unit‑Test.

Was diese Teams benötigen, ist eindeutig: ein Registrierungs‑Snippet, das sie in MCP-Clients einfügen können, plus Offline‑C#‑Aufrufe, die JSON, Text und Markdown‑Artefakte zur Überprüfung schreiben. Ich stieß darauf, als ein Partner nach extract_tables im Chat fragte, bevor Docker auf Entwickler‑Laptops genehmigt war – die Bibliotheks‑Spiegel hielten die Auslieferung am Laufen, während die Sicherheit die Container‑Überprüfung abschloss.

Industry snapshot: GroupDocs.Parser.Mcp wird veröffentlicht unter ghcr.io/groupdocs-parser/parser-net-mcp und dokumentiert eine rein Docker‑Verteilung, weil die Engine die NuGet‑Größenbeschränkungen überschreitet. Lokale Demos verifizieren daher tool‑äquivalente APIs, ohne eine Live‑MCP‑Sitzung zu benötigen (MCP docs).

Warum generische Ansätze hier nicht ausreichen

Teams probieren in der Regel einen dieser Wege, bevor sie einen dedizierten MCP‑Dokumentserver einsetzen:

  • Ad‑hoc‑Shell‑Skripte um Desktop‑Konverter: Empfindlich bei DOCX und XLSX und sie präsentieren keine benannten MCP‑Werkzeuge.
  • Aufruf von Parser nur in einer privaten API: Funktioniert im Prozess, aber MCP‑Clients sehen get_document_info oder extract_text nie als eigenständige Werkzeuge.
  • Warten auf ein NuGet‑MCP‑Paket: Nicht für diesen Server verfügbar; der veröffentlichte Pfad ist das Container‑Image.

GroupDocs.Parser schließt die Lücke, indem es den Docker‑MCP‑Server mit denselben Parser‑APIs koppelt, die Ihre .NET‑Dienste bereits nutzen.

Die Lösung: GroupDocs.Parser in einem Plattform‑MCP‑Workflow

GroupDocs.Parser für .NET wird zur Verifikations‑Hälfte der MCP‑Story. Parser.GetDocumentInfo, Parser.GetText, GetFormattedText(Markdown) und GetTables spiegeln die Werkzeuge, die GroupDocs.Parser.Mcp den MCP‑Clients bereitstellt. Das Beispiel‑Repository schreibt Result/mcp-server.example.json für die Registrierung und führt dann die drei am häufigsten genutzten Werkzeuge gegen gebündelte DOCX‑ und XLSX‑Dateien aus, sodass Betreiber die Ausgaben unter Result/ inspizieren können.

Um der nachfolgenden Implementierung zu folgen, benötigen Sie:

  • .NET 8 SDK
  • GroupDocs.Parser 26.10.0 (temporäre Lizenz)
  • Beispiel‑Dokumente (das Repo enthält sample.docx, sample.xlsx, sample.pdf)
  • Docker Engine nur beim Starten des Live‑MCP‑Servers
dotnet add package GroupDocs.Parser --version 26.10.0

Implementierung von MCP‑Dokumentwerkzeugen Schritt für Schritt

Hier wird gezeigt, wie GroupDocs.Parser.Mcp registriert und die tool‑äquivalenten APIs verifiziert werden. Das Szenario passt zu einem Plattform‑Squad, das Dokumentwerkzeuge für Assistenten auf .NET 8 an Bord nimmt.

Schritt 1 – Docker‑MCP‑Registrierung erzeugen

Schreiben Sie einen mcpServers‑Eintrag, der den Container interaktiv ausführt und den Host‑Dokumenten‑Ordner unter /data einbindet. Pins Sie Tags in geteilten Konfigurationen.

// JSON for MCP clients: docker run --rm -i -v <host>:/data <image>
string normalizedHost = hostDocumentsPath.Replace('\\', '/');
var payload = new
{
    mcpServers = new
    {
        groupdocs_parser = new
        {
            command = "docker",
            args = new[]
            {
                "run", "--rm", "-i",
                "-v", $"{normalizedHost}:/data",
                McpImage
            }
        }
    },

Fahren Sie mit der Werkzeugliste fort und schreiben Sie UTF‑8‑JSON für den Client‑Import:

    tools = new[]
    {
        "extract_text",
        "extract_tables",
        "extract_metadata",
        "extract_images",
        "extract_barcodes",
        "get_document_info",
        "get_license_status"
    },
    notes = "Pin the image tag in shared configs "
        + "(for example :26.9.0) instead of :latest."
};
var json = JsonSerializer.Serialize(
    payload,
    new JsonSerializerOptions { WriteIndented = true });
File.WriteAllText(outputPath, json, Encoding.UTF8);

Schritt 2 – get_document_info für Vorab‑Checks spiegeln

MCP‑Clients rufen häufig get_document_info auf, bevor schwerere Werkzeuge verwendet werden. Spiegeln Sie diesen Vertrag mit Parser.GetDocumentInfo, damit Schemata stabil bleiben.

using var parser = new Parser(sourcePath);
var info = parser.GetDocumentInfo();

var payload = new
{
    fileName = Path.GetFileName(sourcePath),
    fileType = info?.FileType?.ToString(),
    pageCount = info?.PageCount,
    sizeBytes = info?.Size
};

File.WriteAllText(
    outputPath,
    JsonSerializer.Serialize(
        payload,
        new JsonSerializerOptions { WriteIndented = true }),
    Encoding.UTF8);

Warum diese Felder für Plattform‑Ops wichtig sind:

  • fileType: Bestätigt, dass der Parser das Format erkannt hat, bevor Textwerkzeuge ausgeführt werden
  • pageCount: Günstiges Signal zur Abschätzung des Kontextbudgets des MCP‑Clients
  • sizeBytes: Unterstützt Kontingente und Anomalie‑Checks bei eingehenden Uploads

Auf dem gebündelten sample.docx meldet der Lauf einen Microsoft Word Open XML‑Typ, 2 Seiten und 15214 Bytes.

Schritt 3 – extract_text für assistentenlesbare Ausgabe spiegeln

using var parser = new Parser(sourcePath);
using TextReader? reader = parser.GetText();
if (reader == null)
{
    File.WriteAllText(outputPath, string.Empty, Encoding.UTF8);
    return 0;
}

string text = reader.ReadToEnd();
File.WriteAllText(outputPath, text, Encoding.UTF8);
return text.Length;

Die Rückgabe der Zeichenanzahl liefert CI‑ und Konsolen‑Umgebungen ein messbares Erfolgssignal, das dem entspricht, was Betreiber vom MCP‑extract_text‑Werkzeug erwarten.

Schritt 4 – extract_tables als Markdown für Chat‑UIs spiegeln

Bevorzugen Sie formatiertes Markdown, fallen Sie dann auf Pipe‑Tabellen von GetTables zurück, damit Chat‑Clients einen konsistenten Rendering‑Pfad behalten.

using var parser = new Parser(sourcePath);

using (TextReader? formatted = parser.GetFormattedText(
           new FormattedTextOptions(FormattedTextMode.Markdown)))
{
    if (formatted != null)
    {
        string markdown = formatted.ReadToEnd();
        File.WriteAllText(outputPath, markdown, Encoding.UTF8);
        int rows = 0;
        using var sr = new StringReader(markdown);
        string? line;
        while ((line = sr.ReadLine()) != null)
        {
            if (line.Contains('|', StringComparison.Ordinal))
                rows++;
        }
        return rows > 0
            ? rows
            : (string.IsNullOrWhiteSpace(markdown) ? 0 : 1);
    }
}

Wenn formatiertes Markdown nicht verfügbar ist, prüfen Sie Funktionen und strukturelle Tabellen:

if (!parser.Features.Tables)
{
    File.WriteAllText(
        outputPath,
        "_Tables extraction is not supported for this file._\n",
        Encoding.UTF8);
    return 0;
}

IEnumerable<PageTableArea>? tables = parser.GetTables();
if (tables == null)
{
    File.WriteAllText(outputPath, "_No tables returned._\n", Encoding.UTF8);
    return 0;
}

Nachgelagerte Systeme können das Markdown neben der Quell‑XLSX archivieren oder Pipe‑Tabellen direkt in MCP‑Client‑Chat‑Fenster einspeisen, ohne einen zweiten Konverter zu benötigen.

Warum sollten Plattform-Teams sowohl Docker-MCP als auch Bibliotheks-Spiegel behalten?

Behalten Sie Docker-MCP, wenn MCP-Clients benannte Werkzeuge gegen Dateien unter /data via ghcr.io/groupdocs-parser/parser-net-mcp aufrufen müssen. Behalten Sie Bibliotheks‑Spiegel, wenn PRs beweisen müssen, dass get_document_info, extract_text und extract_tables ohne Live‑Handshake funktionieren. Dieser Dual‑Pfad trennt Container‑Richtlinien von Parsing‑Regressionen. Pinnen Sie einen Produktions‑Tag und führen Sie die .NET‑Spiegel in CI bei jedem Parser‑Paket‑Bump aus, wie das Beispiel‑Repo zeigt.

Realer Workflow: Onboarding von Dokumentwerkzeugen für einen gemeinsamen MCP-Client-Flotten

Ein Plattform‑Team, das drei Produkt‑Squads unterstützt, pflegt eine MCP‑Client‑Baseline. Jeder Squad legt DOCX‑Richtlinien und XLSX‑Preistabellen in ein gemeinsames Dokumenten‑Volume. Bevor ein neuer parser-net-mcp‑Tag ausgerollt wird, führt das Team den .NET‑Konsolen‑Host aus: Registrierungs‑JSON wird neu generiert, document-info.json wird mit Goldwerten verglichen (2 Seiten / 15214 Bytes für das Smoke‑DOCX), Text‑Zeichenanzahlen werden protokolliert und Sheet1/Sheet2‑Markdown aus dem XLSX‑Beispiel wird auf Pipe‑Tabellen‑Struktur geprüft.

Dieser Workflow entspricht exakt den obigen Schritten. Schritt 1 ist die Flotten‑Konfiguration. Schritte 2‑4 sind die Offline‑Gateways. Erst wenn diese Gates bestehen, wird das gepinnte Container‑Image zu den MCP‑Client‑Hosts ausgerollt. Bei Docker‑spezifischen Fehlern nutzen Operatoren den MCP troubleshooting guide.

Geschäftliche Auswirkungen: Was sich dadurch ändert

Metrik Vorher (ad‑hoc) Nachher (GroupDocs.Parser + MCP)
Client‑Registrierung Manuelle Notizen, Drift pro Laptop Eingcheckedes mcpServers‑JSON
Werkzeug‑Vertragsprüfungen Nur nach Fehlschlag von Live‑MCP‑Aufrufen Offline‑JSON/Text/Markdown‑Fixtures
Tabellenlieferung an Chat Benutzerdefinierte CSV‑Konverter Markdown abgestimmt auf extract_tables
Paketverteilung Erwartung eines NuGet‑MCP Klarer Docker‑nur‑Server + NuGet‑Bibliothek
Image‑Drift Schwebendes :latest Gepinnte Tags wie :26.9.0
Audit‑Protokoll Nur Chat‑Logs Result/‑Artefakte pro Lauf

Der kombinierte Effekt ist ein schnelleres Onboarding für MCP‑Clients und weniger Produktions‑Überraschungen, wenn Container‑Richtlinien und Parsing‑Verhalten auf unterschiedlichen Zeitlinien laufen.

Weitere Plattform‑Szenarien, in denen das passt

Sobald Registrierung und Spiegel eingerichtet sind, unterstützen dieselben APIs:

  • Pre‑Ingest‑Gates: Uploads ablehnen, wenn pageCount oder sizeBytes außerhalb der Richtlinie liegen, bevor MCP‑Clients ausgeführt werden
  • Spreadsheet‑Briefings: Markdown‑Tabellen aus XLSX an Stand‑up‑Bots senden
  • Multi‑Format‑Smoke‑Packs: DOCX-, XLSX‑ und PDF‑Beispiele neben der MCP‑Konfiguration für wöchentliche Regressionen behalten
  • Sidecar‑Rollouts: GroupDocs.Parser.Mcp neben einer .NET‑API ausführen, die noch den In‑Process‑Parser für interne Jobs nutzt

Einstieg in Ihrer Plattform-Umgebung

Sie haben gesehen, wie GroupDocs.Parser MCP‑Dokumentwerkzeuge für Plattform‑Teams auf .NET handhabt. Nächste Schritte:

Ressourcen