Dela via

MCP-servrar i NuGet-paket

NuGet är ett bekvämt sätt att paketera och distribuera MCP-servrar skrivna i .NET. C# MCP SDK och .NET erbjuder en robust plattform för att skapa MCP-servrar, och NuGet är perfekt för att leverera din MCP-server till slutanvändare som ett lokalt verktyg. Fristående, plattformsspecifika paket minskar körningskompatibilitetsproblem och AOT-kompilering kan ytterligare förbättra slutanvändarupplevelsen.

Mer information om Model Context Protocol (MCP) i allmänhet finns i introduktionen på MCP-webbplatsen. Information om hur du skapar en egen MCP-server och paketera den med NuGet finns i snabbstartsguiden.

Tillämpliga scenarier

Att skicka MCP-servern via NuGet gäller inte för alla situationer. Termen "MCP-klient" används i det här dokumentet och refererar till ett program som samordnar interaktionen mellan en AI-agent eller LLM och anrop som görs till en MCP-server. Några exempel på MCP-klienter är Visual Studio Code, Visual Studio, GitHub Copilot-kodningsagent, Claude Code eller markör.

Överväg följande kriterier för att avgöra om det är meningsfullt att skicka MCP-servern som ett NuGet-paket:

  • ✅ Du vill att MCP-servern ska köras lokalt på användarens system (dvs. i samma kontext som MCP-klienten).
    • Lokala MCP-servrar, till exempel de som levereras i NuGet-paket, körs i samma kontext som MCP-klienten och kommunicerar med MCP-klienten via standard-I/O-transport (stdio). MCP-klienten ansvarar för att starta den lokala MCP-serverprocessen.
  • ✅ .NET SDK är tillgängligt för MCP-klienten.
    • NuGet MCP-servrar är .NET-verktygspaket som installeras och körs med hjälp av dnx .NET SDK.
  • ✅ Du har ett NuGet-paketflöde som värd för MCP-serverpaketet.
    • NuGet.org kan användas för att publicera MCP-serverpaket och ger en skräddarsydd MCP-surfning och förbrukningsupplevelse. Men alla NuGet-paketflöden, till exempel Azure Artifacts, kan användas för att vara värd för MCP-servrar om du vill hålla MCP-serverpaketet privat.

Fördelar med att använda .NET och NuGet för MCP-servrar

Det finns flera fördelar med att använda NuGet för att vara värd för din MCP-server:

  • Officiell SDK – MCP C# SDK tillhandahåller ett välbekant gränssnitt för implementering av MCP-servern i C# och gör det enkelt att exponera verktyg för MCP-klienter.
  • Flexibla körningsalternativ – .NET SDK innehåller flera alternativ för hur MCP-servern kompileras och paketeras. Mer information finns i avsnittet om körningskrav .
  • Identifiering och distribution – NuGet.org är ett sätt att visa upp mcp-servern så att potentiella användare kan hitta mcp-servern och enkelt använda den inifrån VS Code eller Visual Studio. NuGet.org uppmuntrar till användning av en inbäddad .mcp/server.json för att deklarera indata och en McpServer pakettyp så att MCP-servrar kan särskiljas från andra verktyg eller beroendepaket.
  • Välbekanta redigeringsarbetsflöden – om du redan använder NuGet för att skapa beroendepaket blir det en mycket liknande upplevelse att skapa och publicera en MCP-server.

Ladda ned och köra paket

För att hämta en lokal MCP-server måste koden för servern finnas och laddas ned med hjälp av en mekanism (protokoll) som är specifik för paketekosystemet. Detta görs vanligtvis med ett "single-shot"-kommando som tar paketnamnet och argumenten för att ladda ned och sedan köra paketet som ett kommandoradsprogram.

För NuGet-baserade MCP-servrar rekommenderar vi att du använder dnx (ett nytt kommando som levereras i .NET 10 Preview 6) för att hämta och köra paketet. dnx levereras för närvarande med .NET SDK, men det finns en diskussion att ta med dnx i .NET-körningen.

Ett kommando för att starta en MCP-server skulle se ut ungefär så här:

dnx NuGet.Mcp.Server@0.1.2-preview --yes

Miljövariabler och kommandoradsargument kan båda användas för att konfigurera MCP-servern på anpassade sätt. Med dessa indata kan du anpassa mcp-serverns beteende efter specifika behov.

Då laddas versionspaketet NuGet.Mcp.Server ned 0.1.2-preview från dina konfigurerade paketkällor (NuGet.org som standard) och det inneslutna CLI-verktyget startas. För en MCP-server kan loggmeddelanden visas i stderr, men processen kan verka fastna. Detta är förväntat eftersom processen väntar på MCP-protokollmeddelanden via stdin från MCP-klienten.

Vanligtvis anropar MCP-klienten det här kommandot via verktygsspecifik MCP-konfiguration, till exempel filen mcp.json som används av Visual Studio Code och Visual Studio.

Alla dessa verktyg stöder installation av alternativa källor. Har till exempel dnx stöd för installation från Azure DevOps med hjälp av parametern --source, vilket möjliggör användning av privata MCP-servrar, så länge de nödvändiga autentiseringsuppgifterna eller leverantörerna av autentiseringsuppgifter har konfigurerats.

Körmiljökrav

När paketet har laddats ned krävs en körmiljö för att exekvera koden i paketet. .NET-verktygspaket (och nuGet-baserade MCP-servrar med tillägg) stöder en mängd olika alternativ för hur verktyget kompileras och paketeras. Med de här alternativen kan du, MCP-serverförfattaren, bestämma vilka körningskrav som ska ställas på användarna av MCP-servern.

Det finns tre huvudsakliga alternativ för att paketera MCP-servern:

  1. Ramverksberoende: Kräver att MCP-klienten har åtkomst till en kompatibel .NET-körning. Om dnx används för att ladda ner och köra paketet blir en körmiljö tillgänglig.
  2. Fristående: Inkluderar körningen i paketet. Om du använder trimning kan du minska storleken på paketet. Fristående .NET-verktyg använder <PublishSelfContained>true</PublishSelfContained>.
  3. AOT(Ahead-of-time): Ett fristående paket med AOT-kompilering aktiverat. Mer information finns i den interna AOT-distributionen . AOT.NET-verktyg använder <PublishAot>true</PublishAot>.

För MCP-servrar rekommenderar vi att du använder alternativ 2 (fristående paket utan AOT) eftersom det eliminerar behovet av en specifik .NET-körningsversion som finns i användarens miljö. Om du kan garantera en kompatibel körningsversion i den avsedda körningsmiljön är alternativ 1 rimligt. Alternativ 3 (med AOT) är också ett bra alternativ, men det tvingar dig eller dina beroenden att göra koden kompatibel med AOT-kompilering. C# MCP SDK är AOT-kompatibel, men andra beroenden som du tänker använda kanske ännu inte är AOT-kompatibla.

Överväg att använda mallen mcpserver i mallpaketet Microsoft.Extensions.AI.Templates för att använda de senaste rekommenderade standardvärdena.

Jämförelse med andra ekosystem

Andra ekosystem har liknande krav och arbetsflöden för paketering och körning av MCP-servrar:

  • NuGet/.NET: Använder dnx kommandot för att ladda ned och köra .NET-verktygspaket. Kräver .NET SDK för dnx. Ytterligare körberoenden kan läggas till i paketet.
  • npm: Använder npx kommandot för att ladda ned och köra npm-paket och installera beroenden transitivt. Kräver Node.js.
  • Python: Använder uvx kommandot för att ladda ned och köra Python-paket och installera beroenden transitivt. Kräver en Python-miljö.
  • Docker: Använder docker run kommandot för att ladda ned och köra avbildningar. Kräver Docker-motorn. Docker-avbildningar kan rikta in sig på flera CPU-arkitekturer och ge utmärkt isolering, men är vanligtvis större än NuGet-, npm- eller Python-paket.

I alla dessa fall måste MCP-klienten ha det nödvändiga ekosystemspecifika verktyget (t.ex. dnx, npx) för att ladda ned och köra den paketbaserade MCP-servern.