Come i team di piattaforma usano GroupDocs.Parser per integrare gli strumenti di documento nei client MCP su .NET

💡 Esempio completo funzionante disponibile su GitHub: parser-mcp-document-tools-dotnet

La sfida della piattaforma: perché gli strumenti di documento si bloccano ai confini di MCP

Gli strumenti di documento basati su Docker per i client MCP sono un modello di distribuzione GroupDocs.Parser.Mcp su .NET che accoppia un’immagine container con controlli offline della libreria per get_document_info, extract_text e extract_tables. I gruppi di ingegneria della piattaforma che forniscono strumenti di documento per gli assistenti raramente hanno difficoltà con “possiamo analizzare un DOCX?”. Hanno difficoltà con un taglio più netto: il server MCP deve apparire nelle configurazioni del client come un elenco di strumenti nominati, mentre il motore di parsing è così grande che GroupDocs.Parser.Mcp viene distribuito solo come immagine container, non come pacchetto NuGet.

Quando una squadra di prodotto richiede informazioni sul documento, testo semplice e tabelle pronte per la chat all’interno di un client MCP, il team di piattaforma eredita due percorsi. Il percorso uno è operativo: docker run con un volume su /data, tag fissati come :26.9.0 e una voce stabile mcpServers. Il percorso due è di verifica: dimostrare che GroupDocs.Parser per .NET restituisce gli stessi fatti che quegli strumenti restituirebbero prima che qualcuno dipenda da una stretta di mano live. Mancato uno dei due percorsi e i fallimenti appaiono come risposte vuote del client MCP invece di un test unitario fallito.

Ciò di cui questi team hanno bisogno è esplicito: uno snippet di registrazione da incollare nei client MCP, più chiamate C# offline che scrivono artefatti JSON, testo e Markdown per la revisione. L’ho incontrato quando un partner ha chiesto extract_tables in chat prima che Docker fosse approvato sui laptop degli sviluppatori – i mirror della libreria hanno mantenuto la consegna in movimento mentre la sicurezza completava la revisione del container.

Industry snapshot: GroupDocs.Parser.Mcp è pubblicato su ghcr.io/groupdocs-parser/parser-net-mcp e documenta una distribuzione solo Docker perché il motore supera i limiti di dimensione di NuGet. Le demo locali verificano quindi le API equivalenti agli strumenti senza richiedere una sessione MCP live (MCP docs).


Perché gli approcci generici non bastano qui

I team solitamente provano uno di questi percorsi prima di adottare un server documento MCP dedicato:

  • Script shell ad‑hoc intorno ai convertitori desktop: fragili su DOCX e XLSX e non presentano strumenti MCP nominati.
  • Chiamare Parser solo in un’API privata: funziona in‑processo, ma i client MCP non vedono mai get_document_info o extract_text come strumenti di prima classe.
  • Aspettare un pacchetto NuGet MCP: non disponibile per questo server; il percorso pubblicato è l’immagine container.

GroupDocs.Parser chiude il divario accoppiando il server Docker MCP con le stesse API Parser che i tuoi servizi .NET già usano.


La soluzione: GroupDocs.Parser in un flusso di lavoro MCP di piattaforma

GroupDocs.Parser per .NET diventa la metà di verifica della storia MCP. Parser.GetDocumentInfo, Parser.GetText, GetFormattedText(Markdown) e GetTables rispecchiano gli strumenti che GroupDocs.Parser.Mcp espone ai client MCP. Il repository di esempio scrive Result/mcp-server.example.json per la registrazione, poi esercita i tre strumenti più usati su file DOCX e XLSX inclusi così gli operatori possono ispezionare gli output sotto Result/.

Per seguire l’implementazione qui sotto, avrai bisogno di:

  • SDK .NET 8
  • GroupDocs.Parser 26.10.0 (temporary license)
  • Documenti di esempio (il repo include sample.docx, sample.xlsx, sample.pdf)
  • Docker Engine solo quando si avvia il server MCP live
dotnet add package GroupDocs.Parser --version 26.10.0

Implementazione degli strumenti documento MCP passo dopo passo

Ecco come registrare GroupDocs.Parser.Mcp e verificare le API equivalenti agli strumenti. Lo scenario corrisponde a una squadra di piattaforma che integra strumenti documento per assistenti su .NET 8.

Step 1 - Emissione della registrazione Docker MCP

Scrivi una voce mcpServers che esegue il container in modalità interattiva e monta la cartella dei documenti host su /data. Fissa i tag nelle configurazioni condivise.

// 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
            }
        }
    },

Continua con l’elenco degli strumenti e scrivi JSON UTF‑8 per l’importazione del client:

    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);

Step 2 - Rispecchiare get_document_info per controlli preliminari

I client MCP spesso chiamano get_document_info prima degli strumenti più pesanti. Rispecchia quel contratto con Parser.GetDocumentInfo così gli schemi rimangono stabili.

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);

Perché questi campi sono importanti per le operazioni di piattaforma:

  • fileType: conferma che il parser ha riconosciuto il formato prima che gli strumenti di testo vengano eseguiti
  • pageCount: segnale economico per dimensionare i budget di contesto dei client MCP
  • sizeBytes: supporta quote e controlli di anomalia sugli upload in ingresso

Sul sample.docx incluso, l’esecuzione registrata riporta un tipo Microsoft Word Open XML, 2 pagine e 15214 byte.

Step 3 - Rispecchiare extract_text per output leggibile dall’assistente

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;

Restituire il conteggio dei caratteri fornisce a CI e console un segnale di successo misurabile che corrisponde a quanto gli operatori si aspettano dallo strumento MCP extract_text.

Step 4 - Rispecchiare extract_tables come Markdown per UI di chat

Preferisci Markdown formattato, poi ricadi su tabelle pipe da GetTables così i client di chat mantengono un percorso di rendering coerente.

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);
    }
}

Quando il Markdown formattato non è disponibile, controlla le funzionalità e le tabelle strutturali:

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;
}

I sistemi a valle possono archiviare il Markdown accanto al file XLSX di origine, o alimentare le tabelle pipe direttamente nei pannelli di chat del client MCP senza un secondo convertitore.

Perché i team di piattaforma dovrebbero mantenere sia Docker MCP sia i mirror della libreria?

Mantieni Docker MCP quando i client MCP devono chiamare strumenti nominati su file sotto /data via ghcr.io/groupdocs-parser/parser-net-mcp. Mantieni i mirror della libreria quando le PR devono dimostrare get_document_info, extract_text e extract_tables senza una stretta di mano live. Questo percorso duale separa la politica dei container dalle regressioni di parsing. Fissa un tag di produzione e esegui i mirror .NET in CI ad ogni aggiornamento del pacchetto Parser, come mostra il repository di esempio.

Flusso di lavoro reale: integrazione degli strumenti documento per una flotta condivisa di client MCP

Un team di piattaforma che supporta tre squadre di prodotto mantiene un baseline di client MCP. Ogni squadra rilascia politiche DOCX e fogli tariffari XLSX in un volume di documenti condiviso. Prima di promuovere un nuovo tag parser-net-mcp, il team esegue l’host console .NET: il JSON di registrazione viene rigenerato, document-info.json è confrontato con valori di riferimento (2 pagine / 15214 byte per il DOCX di prova), i conteggi dei caratteri del testo sono registrati, e il Markdown di Sheet1/Sheet2 dal campione XLSX è rivisto per la struttura della tabella pipe.

Quel flusso di lavoro mappa direttamente ai passaggi sopra. Il passo 1 è la configurazione della flotta. I passi 2‑4 sono i gate offline. Solo dopo il superamento di questi gate l’immagine container fissata viene distribuita agli host dei client MCP. Per i fallimenti specifici di Docker, gli operatori usano la MCP troubleshooting guide.

Impatto business: cosa cambia

Metrica Prima (ad‑hoc) Dopo (GroupDocs.Parser + MCP)
Registrazione client Note manuali, deriva per laptop JSON mcpServers versionato
Controlli del contratto degli strumenti Solo dopo che le chiamate MCP live falliscono Fixture offline JSON/testo/Markdown
Consegna delle tabelle in chat Convertitori CSV personalizzati Markdown allineato con extract_tables
Distribuzione del pacchetto Aspettativa di NuGet MCP Chiaro server solo Docker + libreria NuGet
Deriva dell’immagine :latest fluttuante Tag fissati come :26.9.0
Traccia di audit Solo log di chat Artefatti Result/ per esecuzione

L’effetto combinato è un onboarding più veloce per i client MCP e meno sorprese in produzione quando la politica dei container e il comportamento di parsing si muovono su orologi diversi.

Altri scenari di piattaforma in cui questo si adatta

Una volta che registrazione e mirror sono in atto, le stesse API supportano:

  • Gate pre‑ingest: rifiuta upload quando pageCount o sizeBytes esulano dalla policy prima che i client MCP vengano eseguiti
  • Briefing di fogli di calcolo: invia tabelle Markdown da XLSX ai bot di stand‑up
  • Pacchetti di prova multi‑formato: conserva campioni DOCX, XLSX e PDF accanto alla configurazione MCP per regressioni settimanali
  • Rollout sidecar: esegui GroupDocs.Parser.Mcp accanto a un’API .NET che usa ancora Parser in‑processo per job interni

Iniziare nel tuo ambiente di piattaforma

Hai visto come GroupDocs.Parser gestisce gli strumenti documento MCP per i team di piattaforma su .NET. Prossimi passi:

Risorse